Many release management processes can be error-prone and slow when handled by people. However, by introducing automation, step-by-step, you will be able to build out a fully automated release cycle from code check-in to deployment. It doesn’t happen overnight though. In this tip, one of a continuing series by SSQ contributor Howard Deiner, you will learn the steps necessary to automate your processes from code check-in to deployment, allowing your team to focus on the critical thinking tasks they were hired for.
Release management can be a tedious and error prone part of the development lifecycle. In Continuous integration: Automating your release management processes, I talked about the benefits that can be gained by automating the processes needed from the point a developer checks in his code, to the point it is deployed to production. But we can’t get there overnight. Each automation task must be tested itself until there is confidence that the automation, is indeed, catching critical bugs and releasing the code with highest quality into the different environments.
We don’t just start deploying to production by copying some files willy-nilly after every successful build. There are steps to gain confidence with. You need to make sure that everyone is comfortable that, as you proceed down the path to continuous integration nirvana, no one is uncomfortable that a person could do better. Remember, your job is to make the process perfect, so we don’t have to rely on overworked and error prone humans!
Let’s take a look at the logical tasks that can be implemented as you build out your continuous deployment framework.
Step by step
- It all starts with the use of a version control system that everyone uses for everything (including items such as database schema, release notes, and so on).
- Create uniform build scripts, configurable for building on any given machine (so that when we build on QA, we go through the same steps as when we built for integration).
- Configure the continuous integration server to build the code whenever a code repository check-in trigger is detected.
- Enforce the rule that once a small amount of code is built (such as when a unit test is written, the code that implements it is written, all of the unit tests pass, and the code is satisfactorily refactored) that developers will check-in the code. This makes sure that our Work in Progress for integration is as small as is consistent with good practice, and that we never break the build.
- Extend the build script to run all of the fast running unit tests each time the code builds successfully.
- Start adding more extensive end-to-end tests, and perhaps tests on non-functional requirements (capacity, throughput, etc.). Since these types of tests are normally longer running, you may want to configure the continuous integration server to schedule these tests to run in the middle of the night.
- Start to tackle the issue of automatic deployments to the QA environment. Issues that I spoke about before, such as automatic database upgrades, care and feeding of application and Web servers and so on need to be tackled. Don’t forget to create some quick and easy smoke tests to automate to check that the deployment to QA went as planned!
- People will normally want to monitor the QA deployments carefully at first. Configure the continuous integration server to use “push button” (manual) activation of these scripts.
- When people are comfortable with the manual QA deployments handled by the continuous integration server, it’s time to consider doing automated continuous delivery to QA after successful nightly tests have run.
- And, then, it’s time to go all the way and think about continuous delivery to production, using the same two-step of first using manual triggered operation, followed by automated operation.
Once we get here, one may ask, “Do we need our QA and deployment staff anymore? To answer that, think about whether we hired QA people to just push buttons and enter values on forms? Of course not! We hired them to make sure that we did the right things, rather than just that we did the things right. Once we can verify that everything that we did was done correctly, and stayed done correctly, we can now have our QA folk look further up the food chain and use critical thinking to make sure that the solutions actually make sense. Having them as part of our Agile team and working shoulder to shoulder with the rest of the delivery team throughout development, rather than as mere quality controllers at the end adds true value to the entire process. So, the answer is that once we have continuous integration working across the board, we can actually use QA for the jobs that we really hired them to do, rather than the boring and repetitive stuff that they are normally forced to do. Similarly for deployment staff – we need to engage them to handle the true risks that affect production, and not waste all their time on things that we can better manage before it becomes a race against time at the end. We can use automation by a machine to do the boring and repetitive stuff, and we get it done better, faster, and cheaper.
For a comprehensive resource on continuous integration, see Continuous integration: Achieving speed and quality in release management.