We help IT Professionals succeed at work.

Best Practices Dev->QA->Production

Medium Priority
Last Modified: 2013-12-13
The company I work for is filled with micro-managers who all think they speak the gospel. Everyone has their own input as to best practices of moving (software development) from Dev, to QA, to Production. I've been given a task to research the industry standard best practices on this very subject.

I've been on google for some time and I just cant find exactly what I'm looking for. In your experience, what is the procedure in moving from QA to Production (we're more interested in this move, than from Dev to QA; however any comments on that as well are much appreciated).

Some people say they want physical form signatures from department heads, some say the developers should do it, some say the developers should NOT do it... it's just a mess of "it should be done this way" input.

The more detail the better (less left open for mis-interpretation by the others).
Watch Question

Suveer PatilQA Analyst

In our company we are following like,
once we get the approval from TEST we are requesting for PP(Pre Production) release in a application..
when we get the approval from our PM in onsite..
we will deploy that in PP then again the clients will test the application in PP if they fell its working fine then they will send their feedback.
then again we are requesting to release the same in Production.once we got the approval we are deploying the same in Production.

Well there is the ITIL way, and that would definitely not be the developers ever, ever touching a production infrastructure!

Also, if your company is public, or will ever soon be public, developers mucking around in production environments will never pass a SOX audit.

ITIL has three layers of control.  The highest is Change Management.  Your LAN support shouldn't be able to even pass gas in the server room without Change Management knowing about it.  They are the gate keepers for production - to ensure that there is appropriate timing and pacing for changes, and that the lower-level control processes have been properly completed.  This team usually manages a change calendar and receives Change Requests from those people wanting to make changes.  This level typically has a formal approval from the CM board.

The next level is Release Management.  In a nutshell, this role is responsible for packaging (if needed) and deploying the change.  If you are familiar with RACI, CM is Accountable for changes, while RM is responsible for them.  RM will need to define a "release" - which is basically a document of the standard "w"s+"h": what, when, who, where, and how.  This level typically has a formal approval from release stakeholders during a "go / no-go" meeting - sort of like a NASA launch control session where a checklist is consulted and either it is a "green" light or "red" light.

The lowest level is Configuration Management.  This role keeps track of what actually needs to change.   If you are doing software, this is your source control and build team.  So when you want to move something from the test environment to production, Configuration Management has had all the tools and tracking in place to know what patches and other fixes were applied to the build since testing started.  This role is critical to successful deployments because if you can't have confidence that what was tested is what ultimately gets installed - it severely reduces the value-add of testing before release because you still end up disrupting the users.  This level does not have a formal approval, but the testers will typically do a "shake out" or "smoke" test on the system to ensure all is good for the test cycle to begin.

The way I like things to physically move is that there is a test environment separate from development, and a staging environment separate from test.  If the test environment can be guaranteed to have strong controls on the configuration, perhaps it could be combined with the staging environment - but it is best to have a pristine location to prepare the release prior to implementation.

This is because, often to simplify and expedite defect analysis, developers may have greater access to modify the test environment.  This is fine, but that is why a staging environment can be important because only those authorized to release to production would be granted change access to the staging environment.

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts

Oh, let me qualify my SOX comment slightly - developers with unfettered access to production will never pass.

At our company we have what's termed a "fire call" ID, and a development support person can request one to address a specific, emergency situation in production - but then that ID expires and that person no longer has access.

The key is that it has to be an emergency failure requiring an immediate response.
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.