Code promotion: Enforcing the rules

Question

So here is our problem:

We have a small team of developers with their own ways of doing things-- I am trying to formalize a process in which we are required to promote our code in the following order:

Local sandbox > Dev > UAT > Staging > Live

Developers develop/test as they go on their own sandbox, Dev is its own box that we would use for continuous integration, UAT is another site in IIS on the dev box, which uses our dev database. We then promote to staging, which is a site in IIS on the Live box and using live data (just like the live, hence staging). Then, finally, we promote to live.

Here are a few of my questions:

1.) Does this seem to be best practice? If not, what needs to be done differently?

2.) How do I enforce the rules to the developers? Often developers skip steps in order to save time... this should not be tolerated and would be great if it could be physically enforced.

3.) How do I enforce these rules to the business group? The business group just wants to get features out FAST. Do we promote only on certain days?

Thanks!

Josh

Answer 1

sounds like a good setup to me ... we don't have as may areas where I work. We have DEV > QA > Production.

1) I'm not exactly sure what "best practice" is, but your setup seems like a very good practice to me. My only concern would be in the Sandbox environment. Are there assurances that the developer's code is backed up daily? just in case their machine crashes hard? I'd hate to lose good dev code.

2) We have a "release coordinator" here who enforces access to Sourcesafe and TFS and also controls access to the QA environment so there are only certain times when they are available.

3) The same goes for the business testers except their authority comes through the Project Managers. The PM's have a document that gets filled out per project and testing teams are specified.

We do only promote on certain days (every other Thursday). However we do understand that there can be emergencies and we have done production releases on off days when the need calls for it, but those emergencies are documented after the fact and analyzed to see what went wrong and where we can make improvements.

I'd say as long as your environment is controlled and documented you should be fine. It would be good to make sure everything is backed up in the sandbox area and that a small group of people control the access to the other environments. I would also recommend you keep good documentation on the comings and goings of the "secured" environments, just in case something goes wrong you can backtrack through the logs and see what might have happened or who might have done it, not necessarily to point fingers but to go back and say "what exactly did you upload/change?" so we can see what might have caused the issue.

Best of luck to you,

Answer 2

We have a similar setup at my shop. We enforce this by using different physical machines and who has access via passwords, etc. I develop locally on my own VPC, then check the code in. That is the end of it as far as I am concerned. Another person has access to the dev box where he runs builds as needed, he does not have access to the "live" box, another person does. This person has access to both the "dev" box and the "live" boxes--this way he can do an emercency deploy etc. if needed. Once a build has gone to dev and been tested, then, and only then, is a "live" build done.

Answer 3

Scott already answered pretty well, so i won't repeat his logic. The one he seems to have missed was:

How do I enforce these rules to the business group?

The problem is, you can not enforce anything on the business group. Only their managers can.

What you (as IT) can do is meet with the business side managers, and lay out the cost/benefit analysis.

• Worst case bug
• Likelyhood of that bug without proper process
• Cost to the company of such bug.

Ideally, the bug would be something which actually happened in the past instead of a theoretical thing :)

Then compare that with the relatively insignificant (just make some estimates, hopefully with business user's input) cost of having proper process and associated slowdowns.

Basically, you need their buy-in, to convince them it's in their interest to not cut corners.