With each passing day, CI and CD practices are becoming a crucial part of modern software development. If implemented accurately and promptly, they can help a software development team speed up deliveries and snuff out potential breaking issues. We don’t like being up for urgent outage calls at 1 AM, right?

Even though they are used together (as CI/CD) under a broader DevOps umbrella, CI and CD are different. Understanding this difference plays a decent chunk in unlocking the full potential of CI/CD pipelines.

CI: Continuous Integration

In the world of software development, change is a constant. Staying flexible and adaptable to keep up with the ever-evolving needs of projects is needed. When things change often, they need to be shipped often. When people continuously push their changes to a big shared codebase, they might break often.

The process of ensuring their integrity and that they integrate well into our software is called – big reveal – Continuous Integration. CI processes facilitate building and testing new integrations (or… code changes). Stuff like unit testing, code coverage, SAST, etc., is a part of this process.

CD: Continuous Delivery

Continuous Delivery expands upon CI and generally comes after the CI process of a change set finishes. CD deals with the delivery part of shipping changes that occur continuously. CD pipelines can help developers automate the deployments of their artifacts after they pass standardized quality/sanity checks. Depending upon your organizational setup, acceptance testing can also be a part of your CD pipelines.

Since each team has its own process of testing and shipping stuff, this article should not be treated as a de-facto standard for anything. Instead, it can be treated as a good starting point to get your feet wet..

Assurances of CI

1. “Test Early, Test Often, Test Effectively”

Having working unit tests early on during the development lifecycle goes a long way. This not only acts as a check for the accuracy of your initial few commits, but it also establishes a groundwork for ensuring that every modification is reviewed and meets your criteria.

Usually, a CI pipeline has at least one test stage to ensure that codebases are tested often and that things are exactly how you want them to be.

Even though the CI pipelines make testing very convenient, you might not want to test every single commit that goes. With time, the number of checks to be performed in your testing stage can increase, and with them, the time it takes to run them. Placing these tests on appropriate branches can help ensure the execution of your desired checks are executed without clogging up your CI servers.

2. Facilitates implementation of “fitness functions”

Architects use fitness functions to evaluate the overall health of software projects. Proper execution of unit tests, ensuring that the code doesn’t break organizational conventions, and meeting your coverage criteria, can serve as good starting fitness functions.

CI makes a perfect platform that can be used to automate the execution of these fitness functions with a desirable frequency. Many modern tools encourage using CI by neatly showing the results of these functions on your project’s home page! An easy-to-govern envrionment also…

3. Invites collaboration

Teams having stricter than usual review policies are often the ones that are harder to collaborate with. In rigid systems where manual checks are involved, it naturally becomes harder to accept external collaborations.

Efficient CI configurations can significantly decrease the necessity for manual checks while streamlining the process for internal and external collaborators. Good configurations also guarantee that all new integrations meet expectations with ease.

4. Consistent and available builds

Now that we have code that meets our standards, we can focus on building it. Having dedicated CI servers can guarantee that every build of your software is produced using a consistent toolchain. A consistent build environment can also help avoid some “it works on my machine” situations.

More often than not, the VCS tool you use at your enterprise has a mechanism to store your build artifacts, and your CI pipelines are already uploading your build artifacts there. These build artifacts can come in handy during rollbacks or if you need to spin up your application at a fixed version in a fresh environment.

A word about deployments

Admittedly, “automated deployment” sounds fancy and hi-tech enough, but it might not be a practical horse to ride for small-scale projects with infrequent deployments. In cases when the benefits of having dedicated CD tools outweigh their maintenance costs, it’s absolutely OK to consider putting deployment instructions in your CI pipelines.

In any case, you should consider putting manual checks before any production deployments. Finally, there is no “one-size-fits-all” solution to automate deployments. One should always analyze the current “system situation” before committing to a CD tool.

Thanks for reading. Iron Maiden!