Steve Jones

23 October 2015

DLM S4 – Release Management

Deploying database changes to new environments is a very stressful activity. Many organizations and their employees dread migrating changes to a production database because of the potential for problems or downtime.

There are ways to minimize the potential issues and build more reliable deployment processes. In fact, many organizations do this, but they do so with a manual process, counting on a few, specific employees to maintain a solution and store that knowledge. If those employees are not available, deployments are either unreliably attempted or rescheduled for a future date.

The next level in the DLM maturity model attempts to bring some reliability and repeatability to the deployment process by using the same process for all environments, not just production. We call this stage S4, or Release Management.

S4 – Release Management

An organization that has reached the S4 stage knows deployments are necessary. They also realize practice and preparation is required to ensure a deployment to production is performed as smoothly as possible. The way this is achieved is by deploying to all environments with the same process.

If we deploy our software to a QA or test environment, we have the chance to discover issues with our process. By repeating this deployment to a user acceptance, beta, staging, or other intermediate database server, we gain additional confidence that we can deploy those same changes to the production database.

A mature database development organization understands that each time a human makes decisions about which settings to change, code to execute, or steps to complete, they may make a mistake. They may type something incorrectly, skip steps, or execute something out of order, any of which can be avoided by introducing automation into the deployment process.

An organization at this stage is blending the development and operational elements of software deployment to ensure all of the environments that host databases are configured alike and the steps completed to deploy software are performed consistently. Each automated deployment to a new environment increases the confidence and likelihood of success in production.

It is essential that some release management tool be used to control this process. Whether this is a custom tool or a commercial/open source one, the software should ensure that the packages produced by the CI process are tracked. Whichever package is then chosen to deploy to a test environment is the same package that is deployed to user acceptance, beta, staging, production, and any other environment.

Any issues with the deployment process should be logged and captured, available for both development and operations staff to review and correct.

This article is the fifth in my series about Redgate’s Database Lifecycle Management maturity model. If you’d like to find out more, dip into my other posts:

An Overview of Database Lifecycle Management

Stage 1 – The Manual Stage

Stage 2 – Automated Version Control

Stage 3 – Continuous Integration