Fundamentals of the CD/CI Pipeline

Providing your users with the best possible software is always the number one priority. But doing so in the fast-paced, ever-changing technology landscape we live in isn’t a simple task. As soon as an update is deployed, it seems like the need for the next is already here. This has been a constant battle of development teams for decades. The introduction of DevOps was a great start, the need to become even more efficient still remains.

Enter: continuous delivery (CD), which is the process of ensuring your software is always ready for deployment. It goes hand-in-hand with the DevOps and agile movement. Deployments are available with the push of a button, and rollbacks (when necessary) are seamless.

Achieving continuous delivery bliss is the dream, but how do we get there? Just follow these commandments:

• Establish continuous integration
• Test
• Test some more
• Deploy when ready
• Monitor

Before embarking on the CD journey, it’s important to reflect on the state of your team. Make sure all the pieces are in place and you feel confident that you’re ready for continuous delivery. Rome wasn’t built in a day, and neither was the CD dream team.

Setting the continuous integration foundation

Behind every great CD pipeline is a well-oiled continuous integration (CI) pipeline. CI is the process of developers pushing code early and often into a code repository for automated integration testing. The idea is that every piece of code sent to the repository will be tested within minutes and flagged if any errors occur. If an error does occur, that now becomes the main priority of the developer.

Without continuous integration, back-tracking errors can be a tedious and time-consuming process, and it’s easy to get lost in the maze of code changes. Integrating as early and often as possible makes it easier to identify where the error occurs. CI also reduces the risk of having errors flare up further down the CD pipeline.

While the specific CI process can vary slightly based on a team’s preference, the essential steps are:

1. Build code
2. Send code to repository
3. Test code
4. Send back errors
5. Fix code
6. Repeat step 2 and 3

The key to an effective CI process is the automation of steps 1-4.Having a reliable CI tool (or tools) makes this possible. If the CI process is running correctly, there shouldn’t be enough time in the day for a team member to test each piece of code sent to the repository.

For more in-depth look into continuous integration specifically, take a look at this ThoughtWorks article or this Atlassian article.

Test, test, and test again

Once cleared through the code repository tests, the next step is to send your code to more expansive staging and production tests. Once again, the key here is automation. For an effective CD pipeline, little to no effort should be going into these tests, allowing your team to focus on development in the CI stage. The tests performed through the stage typically include regression tests (making sure the application works) and performance tests (making sure the application works efficiently).

These tests should confirm that your application works as it should and integrates properly with your existing platform. In many cases, teams will have small user groups test deployments in production-like environments. This gives your team explicit feedback from customers.

To deploy, or not to deploy

This is where continuous delivery and continuous deployment fundamentally disagree. In a standard continuous delivery pipeline, once your application is cleared through testing and declared ready for deployment, it sits in a deployment queue. It is not deployed until manually done so. On the contrary, in a continuous deployment pipeline, as soon as an application passes through testing, it is automatically deployed to end-users.

As ThoughtWorks puts it, “The decision to deploy is a business decision, not a technical restraint”. Deployment frequency varies business to business. What makes sense for a social network probably isn’t going to be the same for downloadable software, such as Adobe Creative Suite or Jenkins. Imagine having to download new software every day… the horror.

Monitor, monitor, and monitor again

Just as DevOps doesn’t end for developers after the code is written, continuous delivery doesn’t end once an application is deployed. Inevitably some applications will have errors, despite all of the testing you worked so hard to automate. This is completely normal. Catching the errors early is critical to the well-being of your application and to the user experience.

Yes, automation is still king. Incorporating tools to monitor deployments and trigger errors can help your team focus on the earlier stages of the CD pipeline. Retrace is one monitoring tool, among many, to keep track of deployments and how they impact your application.

Continuous delivery pipeline is not set in stone

Every DevOps team is different and every CD pipeline will be different. Some teams choose to test heavily to ensure quick and responsive log times, while others may choose to focus more of their efforts on security and reliability. Whatever is most important to your team and your application should be your number one priority throughout CD.

Committing to continuous delivery is daunting, and we get it. But once you’ve got the ball rolling and keep up with deployment best practices, the possibilities are endless. Your team– and most importantly, your users– will thank you.

Author

Ben

More articles by Ben