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, 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
staging, depending on your VCS workflows.
There are some semi-obvious benefits to adopting CI:
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:
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.