Continuous Integration and Deployment

Continuous Integration and Continuous Deployment, often abbreviated as CI/CD, are two closely related techniques that are central to a good DevOps story. They both involve the automation of some activity with your code based on some predefined triggers. Due to this similarity, they are often implemented with the same set of tooling. CI/CD is usually the first step on the road to adopting DevOps. Let’s step through what they are and how to approach them.

Continuous Integration

Continuous Integration, or CI, is about automatically building, testing, and optionally creating a runnable archive of your project. It typically runs on every commit pushed to your version control system (VCS), such as Git. Sometimes more expensive integration tests only run on stable branches like master or staging, depending on your VCS workflows. There are some semi-obvious benefits to adopting CI:

• You get immediate feedback on flaws in a pull request
• You find out quickly if a bad commit landed, before it disrupts your entire team’s workflow But the biggest advantage of CI is an implicit one: standardizing how to build your project. All too often, without CI, the dev, ops, and quality teams will end up building software differently, resulting in different runtime behavior (or failed builds!). By having one official source of truth, we can avoid such problems. You can also read about how containerization helps out with this.

  Continuous Deployment

  Deploying software to production is one of the most gut wrenching experiences many engineers face. What if I screw up one of the steps? What if I missed a bug? What if something works differently than it’s supposed to? Continuous Deployment, or CD, minimizes the input of the engineer in the deployment process. Just like CI automates the process of building and testing software, CD automates the deployment. This involves an upfront cost of defining a scriptable method of updating your servers. (Fortunately, as we’ll see below, modern tooling makes this really easy.) Once you’ve paid that upfront cost, your life becomes much better. This is a great way of achieving immutable infrastructure. One misconception about CD is that it means automatically deploying your software on every commit to the stable branch of your VCS. While that’s an option, it’s not necessary. The important bit is that there’s a well defined trigger for deployment, which could be:

• Every push to the master branch
• Every push to a special production branch
• When the project lead explicitly clicks a “deploy” button

  Tooling

  There are many different CI tools available today. Jenkins, Travis, Azure, Gitlab, CircleCI, etc. At FP Complete, we’re fans of Gitlab’s approach to CI, but most tools will work just fine. Our main criteria is that your CI build process should be in your code repository. On the deployment side, we recommend sticking to container-based deployment systems. Check out our article on containerization for more information.

Subscribe to our blog via email

Email subscriptions come from our Atom feed and are handled by Blogtrottr. You will only receive notifications of blog posts, and can unsubscribe any time.