Continuous integration (CI) and continuous delivery can also be expanded to include continuous deployment, but to avoid confusion in this article, we’ll be using CD to refer to continuous delivery. It’s an extremely useful agile process for DevOps teams: an effective CI/CD pipeline makes bug fixes easier, eliminates merge hell, and speeds up the development process. Using feature flags, it can even increase the safety of deployments and improve user experience. Today, we’ll explain what each component of CI/CD is, and how to implement them.
Continuous Integration
For most organizations, the standard of continuous integration is that every member of the development team contributes to trunk at least every 24 hours. This process makes it easier to find and fix bugs, because doing so in a small code change is easier than in a large one. It also eliminates the merge hell that’s often caused by long-lived feature branches: when each commit is a single day’s work or less, the likelihood of one programmer changing code that another’s code is dependent on shrinks massively.
Continuous integration needs specialized tools in order to integrate code changes from the myriad of different platforms that developers work on. It also needs a set methodology for validating changes.
The most common methodology is Trunk-Based Development, which involves committing every new code change to trunk. This makes satisfying the requirements of CI easy and creates a generally fast-paced development environment. However, it isn’t the only process for CI: it’s also possible to use a process like Gitflow, so long as the pull request process is quick.
Continuous Delivery
Continuous delivery is the process of automating delivery of an application to any infrastructure environment. (If that happens to be the production environment, it’s termed “continuous deployment”.) Typically, continuous delivery processes push code to development, staging, or testing environments.
Not every CD tool works the same way, but commonly, they will automate the process of creating the infrastructure that the new feature requires, moving code from the version control system to the target environment, defining relevant environmental variables and otherwise setting up the target environment, executing automated testing, and rolling back if those tests fail.
Many softwares can be used to automate a CI/CD pipeline; the some of most common are Jenkins, CircleCI, Travis CI, and Bamboo.
Using Feature Flags in CI/CD
A feature flag is a piece of conditional code that allows you to turn features on and off without re-deploying. In a CI/CD workflow, it’s possible to keep unfinished features behind feature flags, only turning those flags on once the feature is complete. If the feature is turned on and still has a bug, the rollback is as easy as flipping a switch. In this way, using feature flags improves both the speed and safety of your feature releases.
There are a variety of ways to implement feature flags, but for teams implementing CI/CD, a comprehensive feature flag management system is typically the best option. This prevents accumulation of technical debt when a flag is used to turn off an incomplete feature and then left in the code, because the management system will let you know the flag hasn’t been flipped on or off in a while.
