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:
Also in DevOps
Working in dedicated development environments for the database is the ideal for many. This is the message we frequently hear throughout the industry from thought leaders, at conferences, and in many w...
Also in Blog
These are tough times for businesses in the EU. Is the UK going to be in or out? Will it be a managed deal or no deal? Will it happen next week, next month, or never? What’s the latest twist in the ...
Also about DLM
Most people involved in database development would agree Database Lifecycle Management (DLM) is a good idea. When implemented correctly, you get a reliable, repeatable and predictable way of deliverin...
Also about automated deployment
If you’re struggling to set up a reliable, repeatable release process you’re not alone. The good news is that most of the problems you’ll encounter have been solved before.
There are many smart...