Introduction to CI/CD

CI/CD

CI/CD stands for Continuous Integration and Continuous Deployment. Let’s quickly review the two terms individually.

Continuous integration

“Integrate what?”, you may ask yourself. The answer is source code, and making sure code written by various team members is merged into a single default branch as frequently as possible. This is important to avoid feature development in isolation. The longer each team member works in isolation, the bigger the eventual merge is going to be. Big merges are painful to review and come with great uncertainty as to whether everything still works.

To reduce that Big Bang surprise when multiple features are eventually merged into the default branch, automation and in particular automated tests are of the utmost importance. The sooner you merge your code with the rest of the team’s code, the better.

Uncertainty, surprises and trouble are all nouns we want to avoid in software engineering!

Continuous deployment (or delivery)

CD takes CI a step further. On top of merging code into the default branch as frequently as possible, why don’t we deploy to production as frequently as possible, too? What if we deploy to production for every merge to the default branch? If that sounds scary, don’t worry. It is perfectly normal for it to be a bit scary the first time you think about it!

A question that everyone asks their mentor on this topic is “How can I deploy to production before my feature is complete?” The answer is complex, but boils down to something along the lines of “As long as your code is not used, you can deploy as much of it as you would like.” A common pattern to hide unfinished code is called feature toggles (also known as feature switch, feature flag, feature flipper, conditional feature, etc.). In essence, we can think of it as an if...else... statement along the lines of this:

if (isFeatureOn("myFeature")) {
    // Execute the myFeature code here
}

As a team’s CI/CD pipelines mature and feature toggles become more sophisticated, you will end up with feature toggles based on a lot more than a boolean value. For example, imagine a feature that is only enabled for Canadian users who visit your web application at least once per week and have previously provided feedback on beta releases. You can get as granular as you need to, and there are services and techniques you can use to make the management of these feature toggles simpler.

Chapter activity overview

In the previous chapter, we developed the necessary scripts to manually deploy the web application. Now, it’s time to automate this process so that each change to the master branch is automatically deployed.

Referring to the project overview diagram, we will focus on the following area of the architecture diagram in this chapter: the “Deploy” task of the GitHub Actions pipeline.