The Principles of Release Management

As with most processes in application development, release management is a subjective discipline. There are many effective ways to promote new revisions of code into the production environment. The goal is to create a process that is defined, repeatable, and does not adversely affect the production environment when new code is released.

So that is the best-practice theory. With three tiers of testing, an automated build environment, and pre-programmed automated test scripts with great code coverage – going to production will be risk-free. Many organizations need this level of risk-mitigation – therefore the associated expense and timeline is warranted. On the other hand – many organizations need to trade the risk of a less tested build for budget savings and quicker release cycles.

Pragmatism

One of Volano’s primary tenets is pragmatism – in this case pragmatism is also known as practicality. We collaborate with stakeholders to determine what level of release management is needed; typically this is ‘finding the happy medium.’ The minimum requirement is two-fold: cross-developer code testing and a full-fledged test system.

Volano’s standard release cycle is very traditional among project based consulting firms (DEV, TEST, LIVE):

New functions and modules are allocated to plan and timelines are set. This becomes the build.

Development (DEV) – development always takes place within a virtual machine. We use VMWare because it works well for both Windows and Mac. Source code is kept in a controlled repository (link).

Quality Assurance (TEST) – as functions and modules become code complete, developer test, and ready for cross-testing – they are promoted to the TEST environment. As the build comes together – someone other than the developer, but usually within our shop – tests the code.

Production (LIVE) – once the build passes TEST it is promoted to LIVE.

Observations

Over the years we’ve developed a number of observations about the software release cycle. I’ll share a few:

Regression bugs are the hallmark of poor revision control practices. True regression issues should be infrequent when developers are using source control appropriately.

Releasing to production should be scheduled when possible. Patch releases introduce risk and frequent production releases cause unstable software. Ideally – builds should be released about every three weeks.

An automated deploy process is more reliable than manually built deploy packages.

The Volano Assessment

We’re building a product around custom application assessments. The assessment is a discovery process that will result in an evaluation of best practices along with important application development documentation in the form of a system master document. This will encompass the current application state and we will offer recommendations regarding how best to move forward. These recommendations will be structured as an actionable plan and will include an estimated effort, costs and proposed timeline.

For the release management component of this assessment, we identify the following:

Assessment

• Can the current software version be obtained, compiled, and released
• Can the project be ‘rolled back’ to a previous version
• Are all custom software applications and libraries in one structured repository
• Is there a test environment

Information

• How to slow the release cycle to produce stable software
• Reach the right level of testing without disrupting a dynamic organization

Getting a grip on release management is very important principle of application development. I would say it is second only to source control in terms of IT management.