CI/CD PLAN>CODE > BUILD > PACKAGE > TEST > RELEASE

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 represent 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.

To sum up these three main concepts:

• Continuous integration (CI)– 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 (CD)– 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.

However, all these processes must follow each other, with continuous integration representing the foundation for the other two to take place.

Continuous testing

We’ve already mentioned that during CI/CD, software goes through a series of automated tests. A CI/CD process, thus, may include the following types of tests:

• Unit tests– to verify single parts of the application. This isolated part of the code base is referred to as a unit.
• Integration tests– since unit tests focus on an individual component and thus may be insufficient by itself, integration tests ensure that multiple components work together correctly and to test how parts of the application work together as a whole.
• Functional tests– these tests make sure that the feature is working as it should.
• End-to-end tests– these tests simulate a user experience to ensure that real users have a smooth, bug-free experience.
• Acceptance tests– these verify the behavior of the software under significant load to ensure its stability and reliability

The testing pyramid below depicts the different types of tests you can run. In some cases, you may not need to run all these tests, especially if you’re just getting started.

Since unit tests are the easiest to implement, requiring fewer resources, then they generally make a good foundation for a fast build and to get feedback much more quickly to developers. Meanwhile, UI tests, which ensure that an application works correctly from a user perspective, are much slower and more complex to run. To sum up, not every CI/CD process will have all these tests but it’s worth remembering that continuous testing through automation is a key component of continuous integration and continuous delivery. 

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

The following image gives an example of the stages of a typical CI/CD pipeline:

Thus, we can deduce that the stages of the CI/CD pipeline include:

1. Source: the CI/CD pipeline is triggered when a new code is committed to the repository.
2. Build: this is where developers put their new code changes and compile them so they may pass through the initial testing phase
3. Test: this is when the new code is tested through automated tests (for example, running unit tests through continuous integration). Depending on the size and complexity of the software, this step could last from seconds to hours. This stage will provide the feedback necessary for developers to fix any issues.
4. Deploy: this is when the code is deployed to a testing or staging environment to prepare it for final release i.e continuous delivery. Usually, the build will automatically deploy once it passes through a series of automated tests.
5. Deploy to production: here the code is released into a live production environment to reach end-users, either manually or automatically

It is important to have such a pipeline within modern software development teams as such processes allow teams to direct their energy and time to writing code and improving products while more tedious tasks become automated.

This ties into the idea behind a true DevOps culture, which is reducing manual processes by introducing automation. Without CI/CD, integrating changes then testing and deploying them would require separate processes which require significant time and effort.

Such automated processes, thus, ensure fewer errors and increased collaboration and efficiency through the software development life cycle.

Indeed, implementing a CI/CD pipeline promotes an environment of collaboration as development, IT, and operations teams work together to deliver higher quality software more frequently.

CI/CD best practices

Among the best practices for an efficient CI/CD pipeline include the following:

1. Commit early and often

2. Make it the only way to deploy to production

3. Continuously review your automation processes

4. Speed up your pipeline

5. Monitor your pipeline

CI/CD tools to design an efficient pipeline

CI/CD can help teams automate the processes of development, testing and deployment. Some tools will focus on handling the continuous integration side of things while other tools will be more focused on continuous delivery.

In this section, we will highlight some of the common tools used to automate these processes as choosing the right tools is key in implementing an efficient CI/CD pipeline that is most suitable for your organization.

Some popular tools include:

• Jenkins: this is one of the most well-known open-source tools for CI/CD. As an extensible automation server, it can be used as a CI server and can be turned into a continuous delivery hub.
• CircleCI: a tool that offers flexible environments and thousands of pre-built integrations; CI/CD orchestration in the cloud or option to use self-hosted runners for added flexibility and control.
• GitLab CI/CD: this tool allows you to streamline and automate your release process offering safe and flexible deployment options. GitLab also acts as the single source of truth for CI/CD and so you can build, test, deploy and monitor your code from a single application.
• Travis CI: this is an open-source CI/CD platform to help developers quickly and easily develop, test and deploy code. This tool is quick to set up and supports over 30 languages offering great flexibility.
• Semaphore: this tool supports a number of languages and platforms including iOS apps. Thus, it can be used to accelerate your releases and deploy across web, desktop and mobile apps.
• Spinnaker: this is an open-source continuous delivery platform that works with a variety of cloud providers with the aim of offering fast, safe and repeatable deployments.

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 provide 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 is done with their changes before they can 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.