CI/CD Overview
Continuous integration (CI) and continuous delivery (CD) are essential terms that are used in DevOps and encompass a set of practices that enable modern development teams to deliver code changes more frequently and quickly.
This is done by introducing automation when it comes to building, deploying, and releasing applications.
CI ensures that code changes are regularly tested and released after merging them into a shared repository (version control system) to ensure their stability while CD allows the quick and smooth delivery of these changes, where they can then be deployed into a live production environment.
Both CI and CD facilitate the efficient release of software to get new, high-quality products out into the market faster than ever before.
Table of contents
- Continuous Integration and Delivery (CI/CD) Explained
- CI/CD Overview
- Continuous Integration
- First step: Continuous Integration.
- Next step: Continuous Delivery
- Continuous Testing
- What is a CI/CD pipeline?
- Example of a typical CI/CD Pipeline
- CI/CD best practices
- CI/CD tools to design an efficient pipeline
- CI/CD + feature flags: The magic formula for even faster deployments
- Conclusion
First step: Continuous Integration.
Continuous integration (CI) allows developers to merge their code changes into a shared trunk. This is known as trunk-based development, which is a key enabler of continuous integration. With this method, developers can integrate their changes, or commit code in small increments, much more frequently, perhaps even several times a day. Each commit will trigger an automated build and test.
In other words, once these changes are merged, a series of automated tests will verify the build to detect any errors so that any bugs can be quickly fixed without disruption to the software.
Benefits of continuous integration
Because developers are integrating small changes frequently, this allows for faster deployment. It also allows for faster feedback so that developers can fix bugs almost immediately.
In trunk-based development, the master branch is the only long-lived branch while all other branches have a limited life span. This is unlike feature branching where developers make a copy of the codebase and then developers can work on their features separately. This usually leads to merge conflict, and in extreme cases merge hell, as developers are simultaneously merging numerous branches.
In this case, since developers are not integrating their changes frequently, they will not get quick feedback. Instead, they will not be able to see any new changes or release their own features until all the other developers’ changes are ready. Afterward, they will attempt to merge several long-lived branches that may contain significant rather than small changes (and hence major bugs) which could have been avoided had they merged to the trunk more often.
Continuous integration, then, results in higher quality releases as bugs can be detected and fixed quickly leading to increased efficiency and productivity since developers no longer have to wait for everyone else to be finished with their own changes.
Next step: Continuous Delivery
Continuous delivery is a software release approach where teams release quality products frequently through a series of automated tests. For an efficient continuous delivery process, continuous deployment will also need to be built into your pipeline. More on that in a bit.
Therefore, the goal behind continuous delivery is to have software that is always ready for deployment to a production environment from the source repository. In other words, it makes sure that the code is always in a deployable state even as multiple developers are making daily changes through continuous integration. Though this is usually an automated process, the actual release into the production environment may be done manually by teams.
The benefits of continuous delivery are clear
Quicker time to market: Perhaps the most obvious benefit is the quicker time to market, as code is always ready to be deployed to users.
Constant feedback loop: A constant feedback loop allows teams to receive constant feedback on products from their end-users and then incorporate this feedback into the next release.
Enhances productivity: Teams no longer have to deal with tedious tasks, which can be performed by pipelines instead, allowing these teams to focus on building better products resulting in increased customer satisfaction.
Reduces risk: When changes are released more frequently in small increments, errors can be easily and quickly spotted and fixed, thereby reducing the typical risks associated with releases.
Continuous Integration vs Continuous Delivery vs Continuous Deployment
In software development, the process starts with continuous integration then continuous delivery builds on this process to release the changes that have been merged into the shared trunk during continuous integration. This means that continuous delivery enables the automated deployment of the code from development to the production stage.
Consequently, CI/CD represents the process of continuous development, testing, and delivery of new releases.
Often confused with continuous delivery, continuous deployment, in fact, goes one step further than continuous delivery.
During this stage, all changes are automatically released without any human intervention, whereas in continuous delivery, the changes are prepared for delivery but when they are released is determined by the team manually.
In other words, continuous delivery is a partly manual process while continuous deployment is all about automating the entire release process. If an automated test fails at this stage then the change will not be released but if the changes pass the test then they are automatically deployed.
Therefore, continuous deployment is an efficient means to accelerate the feedback loop with your end users. However, all these processes must follow each other, with continuous integration representing the foundation for the other two to take place.
Let’s sum up these three concepts:
Continuous Integration
Short-lived branches that are merged into a shared trunk several times a day where a series of automated tests give feedback about the changes introduced.
Continuous Delivery
After continuous integration, continuous delivery prepares the software for delivery; deployment to production is usually manual.
Continuous Deployment
After CI and CD, changes are automatically deployed into production; fully automated process.
What is a CI/CD pipeline?
A CI/CD pipeline is a series of automated tests that follows a software through its delivery lifecycle by taking the source code through to production.
Thus, a typical pipeline builds the code, runs tests and then deploys the new software into production in a true replica of the software development lifecycle.
Incorporating a CI/CD pipeline is an essential factor to maintaining a DevOps culture as it ensures the fast and efficient release of software with minimal risk. Building an CI/CD pipeline, thus, puts DevOps ideals into practice as it allows developers to commit their changes frequently to gain fast feedback leading to the emergence of a culture of collaboration, increased productivity and transparency among teams. These fast feedback loops help fulfill the main goal behind building an efficient CI/CD pipeline, which is reducing the risk usually associated with new releases.
Thus, such a pipeline will include the following elements:
- Building, merging then testing the code-continuous integration
- Preparing the code for delivery- continuous delivery
- Deploying the code automatically- continuous deployment
CI/CD + feature flags: The magic formula for even faster deployments
As we’ve seen, continuous integration and continuous delivery are two essential practices to help you deliver quality software faster.
Implementing feature flags onto these processes provides further value and reduced risk when it comes to integrating new changes and then deploying them.
What are feature flags?
Feature flags are a software development tool whose purpose is to turn certain functionalities on or off to safely test in production by decoupling code deployment from feature release.
Let’s imagine this scenario: there are multiple developers working on several changes over various timelines. What happens when there are developers who have finished their changes while others have not yet finished? Before, this meant that developers would need to wait till everyone on the team was done with their changes before they could finally integrate and deploy the changes.
This may result in dissatisfied customers who would need to wait longer for new releases and in a disruption in the feedback loop as changes are not being merged frequently enough. With feature flags, developers can push their changes without waiting for other developers by simply turning off the portions of the code that are incomplete.
In other words, these incomplete changes can be hidden behind a feature flag while the finished changes can be released. Once they are finished, they can be turned on to become visible to end-users.
This is important as the whole aim of continuous integration is to integrate changes at least once a day and so feature flags help maintain the momentum of continuous integration.
Much in the same way, feature flags help to deliver on the promise of continuous delivery as developers can still proceed with a release while keeping the unfinished changes hidden behind a flag so they don’t affect the user experience.
This means faster time to market as well as the ability to gather continuous feedback to keep improving your products resulting in increased customer satisfaction.
Feature flags are also helpful as kill switches, which means if any bug made it past automated testing, it can be easily turned off or rolled back using feature flags. This way, you disable the feature with the bug and not the entire feature release.
The main takeaway here is that with feature flags, you can deliver releases faster and more safely to end-users.
Conclusion
To sum up, continuous integration and continuous delivery are essential staples in modern software development but with feature flags, they become even better and more powerful by offering significant value to your CI/CD pipeline and eventually your customers.