The thought of software releases conjures up dreadful memories for me — responding to late-night calls and waiting painfully long hours only for the production code to be rolled back. Continuous integration and continuous delivery, often known as CICD, help IT teams and organizations make the release process less painful and more automated. But, more importantly, when you practice CICD, you might be able to discover software bugs much closer to when they were introduced rather than after the product is put into production. Production bugs can be costly, whereas deploying CICD practices can be a cheaper alternative.
The meaning of CICD
The continuous integration
and continuous delivery
terms are often confusing, misquoted, and little understood. Continuous integration is prerequisite for continuous delivery (CD). CD is a practice wherein you can put the code in production or a production-like environment with a single push of a button. It doesn’t mean that you put every build into production; it means only that you can
put it in production regardless of whether it is a business decision. For this to happen, the code should be well integrated and bug-free, and the development team should be confident that it will work as it was intended. This is where continuous integration of the developed code and resolving bugs helps.
Jez Humble, coauthor of Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation
and one of the original engineers of the principle, often does this exercise in his classes. He takes a poll: "Raise your hand if you do continuous integration." A sea of hands always rises. Then he says, "Put them down if all of the developers on your team don't check into the main codeline at least once a day." A large number of hands usually fall. Then he probes further, "Put your hands down unless every check-in triggers a build plus a unit test run." More hands go down. And finally, "Put your hands down if the build isn't fixed within ten minutes of it going red." Humble reports that more often than not, only a few hands remain raised. This short exercise illustrates CICD very well.
Image courtesy: http://www.mindtheproduct.com
CI is a process whereby developers and testers validate the newly written code frequently. The developers check in their code to the mainline branch at least once a day, or multiple times a day. Every check-in triggers a build, and all the unit tests are run. If the build fails, notification is sent to all the developers and the new code is rolled back automatically. Here, the tests help as a safety net to capture any bugs that were inadvertently introduced. All tests should run to confirm that the application behaves as the developers expect it to behave. A huge advantage to this process is that bugs are caught as soon as they are introduced, and the compatibility of everyone’s code is tested. You always have the latest working version of the code.
CD takes CI one step further. After a build and automated unit tests run successfully, you automatically or manually deploy the application to a test, stage, or production environment. Doing this automatically pushes the envelope one step further and is called continuous deployment. CI and CD are the basic recipes for implementing successful DevOps (yes, you have heard and read that term too many times in the recent past) practices in an organization. Often CICD is the toughest portion to implement in DevOps.
Integrating with DevOps
DevOps and CICD are not about buying expensive flashy tools; they are about building the right culture. While tools can help us, the rigorous discipline of checking in the code daily, or more often, building a safety net of tests to make sure that bugs are captured, and fostering a collaborative software development environment will be key to the success of CICD and DevOps implementation. It may be difficult, but it is promising, positive, and rewarding. It is a journey, not a destination.