TechOpsGuys.com Diggin' technology every day

The Release Management Process

Reliable, Repeatable, Results Over Time. One of my mentors over the years, David Gedye, pounded in my head early in my career that my goal as an Ops/IT expert was to achieve "Reliable, Repeatable, Results Over Time." In everything I did, he would hammer this phrase home.

Every company who has a website or web application should have a disciplined Release Management Process. There are so many benefits from getting this right and I'm sure everyone is familiar with not getting this one right. The results of a poor process usually entail, Development throwing code over the fence to Test and subsequently throwing it over to the Technical Operations team. The end result usually ends in configuration, integration issues or last minute bug fixes that do not get thoroughly tested for regressions. One of my strengths is being able to walk into an organization and either establish or help improve the current Release Management Process. To do this successfully I first examine the following things:

• What environments are involved in the development, testing and production of your application?
• How are these environments configured and who owns them?
• How are the virtual teams communicating when a release is ready to move from one environment to the next?
• Is there a tracking system for these releases?
• What technologies are used to store and secure the source code?
• What technologies are used to deploy the code from one environment to another?

Environments

If I could start from scratch and had the headcount and funds to do so, I would deploy the following 5 environments:

Development, Test, Sandbox, Staging & Production

While most organizations likely already take advantage of a Development and Production environment; the other 3 environments can provide great value. Let me explain.

Release Management

Types of Fixes & Proper Lead Time

One of the most difficult problems a team needs to resolve is setting appropriate expectations to internal customers, external customers and application users regarding the amount of time it takes to properly release items from Development to Production. Often times these
expectations are not documented and this can only lead to disappointment in customer response to critical issues, lack of proper time to ensure quality
testing and little or no practice in deployment of these fixes/feature sets. So the main question is how do we classify releases and how much lead time does
each classification require to ensure a high level of quality while still be very responsive to customer issues. Below I've outlined a strategy that helps
tackle some of these difficult issues.

* Lead time descriptions can always be a little fuzzy. Let's just state that the lead time stated above encourages a rapid
response to customer issues while still maintaining enough time for Quality Assurance Testing...not just Black Box testing

Hardware Selection

Hardware selection is driven completely by the budget you have to spend. If you're web farm for your application is 10 web servers you likely will not need more than 2 web servers to fully simulate the Production environment in Sandbox and Staging. Also, if you are not
performance/load testing in Sandbox and/or Staging then you can get away with cheaper desktop or inexpensive rack mounted servers rather than the beefier hardware you are likely running in Production.

Comments About Configuration

I'm not a big fan of consolidating multiple services on 1 server in Sandbox, unless it is similarly configured in
Production. Whether it's football, baseball or Operations; you need to practice like you're gonna play which is the motivation for this.

Tracking a Release

It seems obvious that a release should be documented and recorded to review over time. The obvious solution is to create a database where you can store information on releases. The following represents what I would consider the ideal information you should capture in your database.

Upon each Release Tracker Deployment Request Form completed the following individuals are notified: Requester, Development Lead for the application, QA Lead for the application, anyone else selected under Notify Groups and the entire Technical Operations team.

Source Code Repositories

Visual Source Safe, Subversion, CVS, Source Depot, etc...your source code needs to be stored in a system that allows for labels, branching and versioning. The key to any Release Tracking process is to make sure you are able to roll back to a previous version of the source code should the need arise. All of the above source code repositories support a labeling or versioning system within the software. To make the Release Tracker process work, you must have a Label or Version correctly identified in your source code repository. It is this version that will be tracked from Deployment Request to Deploying Notification to Deployed and Ready for QA, to Passed/Fail QA; should the process fail anywhere along the way there should be a clear version that the Technical Operations team can roll back to.