Making Continuous Integration Work for You

Everyone’s goal is to deliver features better, faster, and cheaper. As part of this push, many developers learn about using continuous integration to improve their deliverability speed and decrease the amount of effort needed to launch new features. Actually practicing continuous integration, however, is nowhere near as straightforward as it sounds.

Six years ago, I was helping deploy changes to an application to a production environment. The process explained to me was, “Go through the Git commits for the tickets you want to deploy and make a note of them; then, manually make each of those changes to the production environment.” While the alarm bells were going off in my head, I watched as the two small changes were written down on a legal pad and then made to the production environment.

A week later, I found myself in the same seat watching the same developer try to deploy a new checkout workflow to the production environment. Four pages of legal pad notes later (and a site that was offline in the process), the changes were deployed—mostly. It was at that point that I knew continuous integration had to become a reality.

Since then, the continuous integration tooling space has undergone a rapid evolution of tools and process. But even with all these options, the path to making continuous integration work for you is still the same.

When I decided to make continuous integration work for me, I started by writing scripts that I could run for the tasks I needed to do. Taking the time to convert one task I was doing to a single script positioned me to have a robot automatically run that script for me in a continuous integration system.

Once I had accumulated these scripts, I sat down (with a legal pad!) and wrote down all of the things I had to do as part of a deployment: take a backup of the system, put the site in maintenance mode, deploy the latest code, run the database schema updates (if any), take the site out of maintenance mode, and then run a smoke test to ensure pages were still returning successful response codes. With my scripts for each of these in hand and a list of what actually had to be run, turning them into a script to be run by a continuous integration system became a trivial task of picking my favorite provider.

As the anniversary of the new checkout workflow again comes around, I continue to reflect on the automated processes I have in place for continuous integration. Are they perfect? Definitely not. But they do save me more times than not—and they allow me to focus on things other than production deployment every now and then!

Brian Thompson is presenting the session Embrace Our Robot Overlords: Make CI Work for You at Agile + DevOps East 2018, November 4–9 in Orlando, Florida.

• Login or Join to add your comment