Understanding the CI/CD Pipeline
Tags: Continuous Delivery, Continuous Integration, DevOps, Software Development

It used to be that software development was simply about, well, software development. As software continues to eat the world, many adjacent aspects of the development process have become ripe for code to take over. Infrastructure topics such as integration and deployment are prime examples. This explains the rise of DevOps. And within DevOps, the CI/CD pipeline is now mainstream among software companies.

If you’re in IT leadership, understanding the CI/CD pipeline is critical to keeping your organization on par with other software companies. That’s why, in this article, I’m going to dive into what you need to know: the concepts of CI/CD, what the CI/CD pipeline is, and why it matters.

Let’s get into it!

Proof That CI/CD Is Important

Before we talk about what CI/CD is, let’s talk about why you should care.

Both CI and CD form the backbone of the modern DevOps environment. You can think of CI/CD processes as similar to a software development lifecycle. Nowadays, the concept of CI/CD is everywhere. Just take a look at the February 2019 trends report by InfoQ on DevOps topics. In it, I count no less than four topics on CI/CD in the early and late majority. There’s even a fifth topic regarding the use of code vs. config in the CD pipeline.

In other words, the importance of CI/CD is no longer in question. When the community talks about CI/CD and the cutting edge in the same sentence, usually it’s about the implementation details of the CI/CD pipeline.

Continuous Integration (CI)

The term continuous integration (CI) came from the people at ThoughtWorks. I will cite their official definition first. According to them,

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

The key details to note are that you need to run code integration multiple times a day, every day, and you need to run the automated verification of the integration. What’s the motivation for this? Well, in the development process, the earlier we surface errors, the better. And one source of frequently occurring errors is the code integration step.

When you have a team of developers, each of whom is responsible for a separate feature, you need to integrate the different features before you’re ready for a release. By integrating so frequently, your team can surface errors earlier. And when those are caught, the amount of backtracking needed to find the cause is also much reduced. Therefore, your team can resolve the integration errors much faster.

Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove. — Martin Fowler, Chief Scientist, ThoughtWorks

How to Practice Continuous Integration

If you want to practice CI, the steps roughly go like this:

Developers check out code from the repository to work on it locally. Ideally, they create a new branch for the feature they want to implement. When their feature branch is ready, they run tests locally in their development environments. Once all tests pass, they push the commits to the single source repository. Whenever there are changes on the repository, a CI server checks out the changes and performs a “build and test.” A build and test is when the CI server builds the entire system on the developer’s feature branch and runs all the unit and integration tests. The CI server notifies the team of the integration result. There should generally be four outcomes: failed build, successful build, failed tests, successful tests. If there’s a failure, the team fixes the issue ASAP. When the feature branch is merged to the main branch, they repeat steps 2–6. They continue to develop and repeat the steps 2–6 whenever there’s new code to be checked in to the repository.

There are minor variations of the steps, depending on the tools you chose and the processes you agree upon within the team. The main principles of CI are that you:

Check in code in frequently. Automate the build and test portion. Always test the code locally before checking it in. Never merge any failed branches to the main branch. Return its status back to successful if you’re the developer who causes the failed build or test. Make it your top priority to do so once the fail happens.

Continuous Deployment (CD)

Jez Humble and David Farley of ThoughtWorks wrote the foundational text on continuous deployment. The official definition stated at the ThoughtWorks website is

Continuous Deployment is closely related to Continuous Integration and refers to the release into production of software that passes the automated tests.

So why do you need to care about continuous deployment as part of your development process? Well, when there are releases, there will be deployment steps. These deployment steps tend to repeat for each release. Instead of performing the deployment manually for each release, why not have the deployment steps be executed automatically? Of course, ideally, this code has been built and tested successfully by the CI server too.

Essentially, it is the practice of releasing every good build to users — Jez Humble, author of Continuous Delivery

What’s the Difference Between Continuous Deployment and Continuous Delivery?

You may be confused by the fact that there’s another term CD can stand for: continuous delivery. So what’s the difference between the two? According to Jez Humble, continuous deployment is about automating the release of a good build to the production environment. In fact, Humble thinks it might be more accurate to call it “continuous release.” On the other hand, continuous delivery is about ensuring that every good build is potentially ready for production release. At the very least, it’s sent to the user acceptance test (UAT) environment. Your business team can then decide when a successful build in UAT can be deployed to production — and they can do so at the push of a button.

Sometimes it’s unwise to have every build be an actual release. Such is the case with embedded software. So we need a slightly different definition for builds that potentially can be releases but need not be automatically deployed — hence the existence of “continuous delivery.”

To keep it simple, here’s a diagram.

When you’ve successfully implemented continuous deployment, it implies that continuous delivery is achieved as well. But the converse isn’t true.

The term “continuous deployment” came before the term “continuous delivery.” However, do note that in most enterprise setups, the business side of the company prefers to manually trigger the deployment. So, chances are your organization will actually be implementing continuous delivery, which is a good enough solution.

What Is the CI/CD Pipeline?

Now that you understand the concepts of CI and CD, it’s time we get more into the weeds of what a CI/CD pipeline is.

A CI/CD pipeline can be easily understood as the process pathway through which we can deliver a single unit of production-ready software. Your team will choose which services they’ll use to build this; there’s no single canonical implementation of a CI/CD pipeline.

The simplest version of the pipeline can best be described by this activity chain:

Each of these steps in the activity chain can be handled by a single service or piece of software. Alternatively, you can split the tasks into several different tools.

Example of a CI/CD Pipeline Toolchain

To better illustrate a pipeline, I’ll conjure up a fictional example involving an enterprise web software written in Java. Suppose I want to start from scratch and I want to keep things easy. I’d make the following choices:

Source code control: I’ll host the code on GitHub (hosted service) as a private repository. This way, I can use its integrations with major software and services to establish triggers whenever code commits are checked in.

Continuous integration: I’ll get CircleCI and connect it with GitHub integrations. This allows every code commit to notify CircleCI via webhooks. When code changes notify CircleCI, it will then pull the code from the GitHub repository and proceed to build and run the tests. Any failures or successes can be sent by email or Slack notification.

Deploy to UAT: Suppose my UAT is running on a server in AWS ECS. I’ll configure CircleCI to deploy automatically to the AWS UAT server when the build and tests are successful.

Deploy to Production: For deployment to production, I’ll reuse the integration steps for deploying to UAT.

With sufficient configuration at the start and by employing three major services, I’ve designed a good enough CI/CD pipeline.

Why Does the CI/CD Pipeline Matter for IT Leaders?

As an individual in IT leadership, you might be wondering why the CI/CD pipeline is so important for you. If that’s the case, I’d encourage you to consider three key benefits.

The CI/CD Pipeline Focuses Resources on Things That Matter

You always need to juggle resources (developers, budget, time) within the constraints of the business (time to market, deadline, runway). As such, you need to put more wood behind fewer arrows for areas that give you the best bang for your buck. Reducing costs and complexity is a crucial benefit of employing a CI/CD pipeline.

Recall I mentioned that many of the CI and CD steps are highly repetitive. But they’re also not easy to do. And they’re error-prone. By automating the process and delegating that to a CI/CD pipeline, you not only free up precious developer resources for actual product development tasks but you also reduce the chances of error. Plus, you’ll improve the responsiveness of the team.

That brings us to the next point: why this matters for you.

The CI/CD Pipeline Improves Reliability

Jez Humble created a test that can help you know if your team is CI/CD-ready. The last part of that test requires your team to be able to recover from a failed build or test within ten minutes.

If your team can accomplish all three parts of the test (daily commits to main branch, automated triggering of build and test, and repair within 10 minutes of failure), then Jez Humble would say your team has accomplished CI/CD. In his own words, he admits that integrating software that’s built by different people is hard. In fact, he says

Combining the work of multiple developers is hard. Software systems are complex, and an apparently simple, self-contained change to a single file can easily have unintended consequences which compromise the correctness of the system. As a result, some teams have developers work isolated from each other on their own branches, both to keep trunk / master stable, and to prevent them treading on each other’s toes. — Jez Humble

It’s precisely this complexity that’s posed by integrating software. That’s why it’s the norm that teams spend days trying to wrangle the branches and commits properly for releases. That’s time spent separated from the actual code development. Imagine if we eliminate this time spend through proper CI/CD pipeline and practices. Your team will be addressing bugs and adding features significantly faster than you would if you didn’t have a pipeline.

And you already know that speed to market matters!

The CI/CD Pipeline Makes Your Team More Attractive to Developers

Joel Spolsky once wrote a 12-step checklist to help job-searching developers evaluate the quality of a software team. That was back in 2008. However, many of the items on that list still apply. Having a proper CI/CD pipeline instantly takes care of two items on that checklist: you make a build in one step and you make daily builds. And typically if you have a CI/CD pipeline, it means you have proper source code control processes, which is another item on that list.

In other words, when you enforce standard CI/CD practices with a proper CI/CD pipeline, you meet 25% of the items on the Joel Test. A company like Microsoft has all 12 requirements met.

Given that developers are hard to hire, it’s imperative that you do your best to make your team attractive to potential hires. Show your potential recruits that they are joining a high-functioning team by having a proper CI/CD pipeline in place.

Pitfalls to Watch Out For When Implementing the CI/CD Pipeline

Sometimes, developers can get carried away with development. If your team suggests rolling out its own CI/CD software, I’d advise gently rejecting it.

Generally, you should avoid building your own CI/CD software in house unless it’s the product you’re selling to your customers. Do you build your own email infrastructure in-house? No. Do you build internal communications tools, like Slack or Skype, in-house? No. You shouldn’t build your own CI/CD software in-house either. CI/CD is just pure infrastructure.

There are plenty of existing services and open-source software that your team can glue together to create your own CI/CD pipeline. Recall that one key motivation for having a CI/CD pipeline is to make integration and deployment work boring and reliable, thus freeing up developer resources for more important work. The same reasoning applies to not building your own CI/CD software. It doesn’t give you a competitive edge when it comes to your business. Thus, the fewer the developer resources you spend on it, the more you can devote those resources to your actual product development.

What Are Your Next Steps?

I’ve dove into the conceptual definitions of continuous integration, continuous deployment, and continuous delivery. Remembering the basics of those concepts will leave you with a good foundation for understanding the other connected concepts, like a CI/CD pipeline.

More importantly, knowing how having a proper pipeline and its associated practices can bring your IT team in line with the most successful companies in the software industry. That will make your team attractive to potential hires and more responsive to the fast-changing business environment.

If your team hasn’t implemented a proper CI/CD pipeline yet, your next step is to plan for it. Talk with your architect and project manager and establish a code-freeze week to set up this pipeline. Remember to keep it simple. Should your team feel unsure about implementing the entire CI/CD pipeline in one shot, phase it in with two stages. My advice is to implement CI first, as that sets the foundation for CD. Then you can set up CD on another occasion. You’ll also want to measure your team’s velocity in delivering software requirements before and after these changes go live. That’s because, as an IT leader, you need to ensure that your changes are demonstrably beneficial for the team and company.

If your team already has a CI/CD pipeline, you’re probably wondering how you can speed it up and improve the quality. Well, it’s hard to do that if you don’t have metrics in place that act a baseline. After all, how can you improve if you can’t measure? My suggestion would be to take a look at Plutora’s solutions, where the metrics and analytics can help guide your digital transformation.

Speed is the name of the game, regardless of whether your team has CI/CD in place or not. When your team can see and feel the difference in their development speed, your executives will be thankful that you bit the bullet to bring about hard but necessary changes for the company. With all this to gain, if your team hasn’t started implementing CI/CD yet, what are you waiting for?

Want to learn more about CI/CD? Check out this great blog article,

Continuous Improvement in a CI/CD Pipeline