Continuous Integration and Continuous Delivery/Deployment (CI/CD) are a set of practices aiming to streamline the processes of developing, testing, and releasing/deploying a software product.
CI/CD enables companies to move away from a waterfall way of releasing software once in an established period of time to introducing changes in a more agile way, thus helping the developers to roll out new functionality in incremental steps and receive feedback from the users faster.
But what exactly are CI and CD? What kind of processes are they built upon? Do you really need CI/CD at your company? How do you build a reliable CI/CD pipeline? Find the answers in this article!
Table of Contents
What is Continuous Integration?
Continuous Integration (CI) is aimed at providing users with new functionality as soon as possible and get instant feedback. It implies that developers commit code changes frequently, which are then merged with the main development branch and delivered to production.
For instance, you want to add a new feature to your product, whose development will take several weeks or even months. You can spend all that time developing the feature only to find out after rolling it out that the users don’t like it! Alternatively, you can roll out the changes incrementally, see how users react, study their feedback, and apply changes promptly. This way, you will save money on developing functionality users don’t want and at the same time, will be able to provide users with reliable and high-quality software answering their needs.
CI implies frequent code commits: usually, once a day, but it can be several times a day. Why is it important to commit code continuously? Introduction of small changes helps to notice bugs at early development changes, saving developers time on debugging.
After developers have committed their changes, the project build is triggered. If successful, the build is run through numerous unit and integration tests to verify that the change hasn’t broken anything. If any of the tests fail, the committed code is rejected. Otherwise, the change is merged into the main branch, and the artifact is built (it can be a Docker image, for instance).
To sum up, continuous integration includes the following stages: code committing, project building, testing, and artifact building.
What is Continuous Delivery?
Continuous Delivery (CD) implies that the code is staged for production as soon as the changes are integrated into the main project branch. CD further automates processes of software releases.
To illustrate: building a Docker image is part of continuous integration, deploying the image to container registry is continuous delivery provided that it happens automatically. To send code to production, the operations engineers only need to push the button.
CD is a good fit for canary deployments and blue-green deployments.
Canary deployments mean that you roll out product updates to a small portion of users; for instance, you deploy the changes to 1% of your nodes. In case of positive feedback from the users and no crashes, you roll out the update to 10% of nodes, then 50%, and so on, with the goal of providing the update to all users. But in case something goes wrong on the first stages, you can quickly roll back the update, redirecting the traffic to healthy nodes.
Blue-green deployments are a strategy of introducing changes to the application with potentially zero downtime. In this scenario, you divide your runtime environment in halves: one of them (blue) serves traffic, the other one doesn’t handle any requests and can be accessed through a private network only. When you need to update the application, you deploy changes to the green environment, where they are thoroughly tested. If everything works fine, the traffic is directed to the green environment.
Whichever strategy you choose, established CD processes will help you achieve deployment consistency and reliability.
What is Continuous Deployment?
The term Continuous Deployment is sometimes used interchangeably with Continuous Delivery. It would even be safe to assume that in most cases when CI/CD is implemented at a company, CD already includes delivery and deployment. But sometimes, these processes need to be divided.
Continuous Deployment means that the code is automatically pushed to production. Therefore, it implies full automation of the processes between committing the code and making the update available to the end users.
On the one hand, this practice takes the burden of manual deployment off the operation team. On the other hand, it can be integrated only when you have robust testing processes minimizing the risks of mayhem on production.
CI/CD pipeline architecture
Summarizing the key points from sections above, the CI/CD pipeline can be depicted as follows:
CI/CD pipeline
CI can exist without CD. In very rare situations, CD can also exist without CI. Furthermore, the simplest CI pipeline can be based on bash solely. For instance, you can set up specific server hooks that trigger custom logic every time developers do git push. Then, you can add additional tools, most common of which are summarized below.
Why is CI/CD important?
You don’t have to implement CI/CD, but you will most certainly benefit from it. Here’s why:
- CI/CD helps to glue together the processes of development, testing, and deployment into one smooth pipeline to reduce software release cycles without losing quality of software.
- It is possible to detect bugs breaking the project and performance regression earlier, meaning that it is easier for developers to find and fix the issues.
- New features are available to users faster. In the case of websites, the changes may go live in a few minutes after committing the code.
- In the absence of a “big deployment day,” when all changes accumulated during an extended period of time go to production, there are no stressed out, overworking developers trying to fix the unexpected bug the night before the release.
- CI/CD enables you to automate repetitive processes such as testing and free the time of developers, testers, and operations engineers.
CI/CD and DevOps
CI/CD is part of the DevOps methodology that aims to build a bridge between development and operations teams. By automating the processes of building, testing, and deploying code, CI/CD facilitates the work of developers that can commit code faster and operations engineers that want to have a stable and standardized delivery process.
DevOps, in turn, originates from Agile software development methodology whose Manifesto places priority on collaboration between teams and customers and rapid responsiveness to changes. CI/CD helps to put these priorities to life by enabling the developers to deliver code changes faster.
Common CI/CD tools
As mentioned above, you can build a Continuous Integration pipeline with bash only. However, if you want to have a convenient user interface and introduce more complex processes such as monitoring, security checks, and so on, you might want to use the solutions developed specifically for implementing CI/CD. Some common solutions include:
- Jenkins is an open-source framework for automating all sorts of processes related to building, testing, and deploying software. It is a Java-based application with a user interface that offers hundreds of plugins enabling you to perform any task or connect to a wide variety of tools.
- GitHub Actions enables you to automate build, test, and deploy processes right from the Github repository. It is possible to write your own actions by describing required workflows in separate YAML files or load existing Actions from the Marketplace. For instance, you can install Java such as Liberica JDK by using the setup-java action or generate native images using the GitHub Action for GraalVM. A tutorial on creating native images with a Github action can be found here.
- GitLab CI/CD helps you to set up a CI/CD pipeline within GitLab. Pipeline stages and jobs to be performed at these stages are defined in the .gitlab-ci.yml file. In addition, GitLab CI/CD offers Auto DevOps, which is a set of pre-configured integrations similar to GitHub Actions.
But these platforms are only a drop in the ocean. You can find a more detailed overview of these and a variety of other popular technologies in the Overview of CI/CD tools.
If you deploy your application to the cloud, container registries such as Docker and container orchestrators such as Kubernetes also become part of your CI/CD pipeline. In this regard, using smaller container images will enable you to accelerate push / pull time. Consider using base images with Alpaquita Linux, 100% compatible with Alpine, but with two flavors based on musl and glibc and increased security including LTS releases and enterprise support.
Speaking of security: ensuring the security of your code becomes even more vital when implementing CI/CD because software supply chains are increasingly becoming targets of hacker attacks. In this case, reducing the CI/CD security risks defined by OWASP is strongly recommended. In addition, you should make sure that your project is free of known vulnerabilities, and that developers don’t introduce vulnerabilities with their changs. For that purpose, you can integrate vulnerability scanners into your pipeline. And if you have a Java project, using Liberica JDK and Alpaquita Linux provided with a Software Bill of Materials will enable you to set up SBOM validation within the pipeline.
Conclusion
Adopting CI/CD will help you shorten software release cycles and provide value to users faster. In turn, your teams will have more time working on adding value to the product thanks to automation of many processes.
