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?
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,