Table of Contents
A few months ago we published a post about DevOps , a software development methodology that combines software development (Dev) with information technology operations (Ops) in the entire service lifecycle: from the initial product design, through the whole development process, and to production support.
Among the most important and innovative aspects of DevOps are Continuous Integration (CI) and Continuous Delivery (CD), often referred with the CI/CD acronym: these are two fundamental software development practices aiming to automate some recurring processes and cutting the deployment/feedback time. In this article, we'll further expand this concept by explaining what a CI/CD pipeline actually is, and how we can set it up and optimize it using best practices, industry standards, and automation software services to greatly increase the productivity, reliability, and innovation capabilities of our organization.
Definitions
Let's start with defining what Continuous Integration and Continuous Delivery actually mean.
Continuous Integration (CI)
According to Wikipedia, Continuous Integration (CI) is the practice of merging all developers' working copies to a shared repository every time a change is made (typically, several times a day) The term has been firstly proposed by Grady Booch in his 1991 method, then it was adopted by Extreme programming (XP), eventually becoming a de-facto standard DevOps methodology.
To summarize the concepts, we could say that Continuous Integration is the practice of automating the build and testing of code every time a change is made — and committing that code back to a central repository (such as GitHub). By understanding that, we can immediately see the two key requirements of Continuous Integration:
- Mindset requirements, because developers must always ensure that their code is working (otherwise they would cripple other colleagues' work); this can be enforced by other development best practices such as adopting a testing platform, working using Test-Driven Development (TDD) techniques, and so on.
- Automation requirements, because the merging and publishing activities can't be performed manually. This automation typically relies upon the use of dedicated software, services and/or platforms, such as Travis, SonarCode, and the like.
Continuous Delivery (CD)
Continuous delivery (CD), is a software development approach occurring when the team aims to release the software in short cycles. To put it in other words, CD is the practice of automating the publishing, release, and deployment of our apps every time a change is committed to the code base.
Again, enforcing such a process requires mindset requirements by developers and automation requirements, since the publish, release, and deployment activities must be handled by a fully automated service.
As we can see, there is an immediate dependency link with Continuous Integration: every time the CI process updates the shared code base, the CD process will deploy the app. That's precisely what the CI/CD pipeline is about.
Here's a useful diagram (courtesy of GitHub) that can help understand how the two processes are connected together as part of the same pipeline:
Continuous Deployment
It's worth noting that the CD acronym, other than Continuous Delivery, is sometimes used to refer to Continuous Deployment. As a matter of fact, the two terms have more than something in common - at least to some extent.
- Continuous Delivery is used when referring to processes where the release and deployment phase is handled by a separate actor (typically a third-party or a manual process): in other words, it's the process of automatically delivering the software's new version to production-ready environments for approval.
- Continuous Deployment is used when the software is deployed to customers directly, also integrating (and thus automatizing) even the publishing, release, and deployment phases: as we can easily understand, this is a step further than Continuous Delivery, since it requires a more rigorous testing approach (mindset), as well as stronger and proven automation capabilities.
To summarize the differences between these two concepts, we could say that Continuous Deployment is the ultimate example of DevOps automation: that said, when we hear someone talk about "CI/CD" or refers to a "CI/CD pipeline", it's almost always Continuous Delivery, which is far a more common (and easy to implement) approach.
Benefits of CI/CD
Now that we know the terms, let's try to explain the reasons why we should consider implementing a CI/CD pipeline based on task automation tools. Unsurprisingly, the main reason is performance: or, to put in other terms, speed.
To better understand why automating these tasks can improve the overall performance of a development lifecycle, let's take a look at the 2019 Accelerate State of DevOps Report, a comprehensive view of the DevOps industry built upon the results of six years of research and data from more than 31,000 professionals worldwide. The report says that companies and organizations that have successfully adopted a CI/CD pipeline deploy > 200 times more often and have a lead time 106 times faster than their competitors.
Other than speed, other notable advantages include:
- Productivity. Faster releases also mean faster feedbacks, which will greatly optimize the developer's work; a faster feedback response will often translate into more specific (and precise) feedback reports, thus building a virtuous circle between developers and testers (or end users).
- Reliability. Automated, continuous testing will minimize or prevent most bugs and issues, thus greatly helping developers to keep the code base stable and release-ready at any time.
- Innovation. Getting rid of manual task in favor of automated processes will help developers - and the whole organization - to focus on other tasks, such as: R&D, customer satisfaction, marketing strategies, partnerships, new tool/framework testing, experiments, and so on.
A typical CI/CD example
Let's now try to apply the basic knowledge that we have gained so far to analyze the following simple CI/CD pipeline:
- Software Developers use a Version Control System platform (such as GitHub) to open pull requests
- Pull requests trigger the first automated build and unit testing processes
- Automated build and unit testing processes, depending on their result, mark the commit approved or not.
- Approved commits are automatically published, released, and deployed to a preview environment (Continuous Delivery)
- Preview deployments trigger the automated end-to-end unit testing processes
- Automated end-to-end testing processes, depending on their result, mark the new version as production-ready or not.
- Production-ready versions are either merged to the main code branch for manual deployment (Continuous Delivery) or directly deployed to production (Continuous Deployment).
As we can see, Continuous Delivery can either stop at step #4 or go all the way up to step #7, depending on the organization's overall confidence, maturity, and know-how.
Conclusions
That's it, at least for now: we hope that this post will help software developers, IT administrators, and DevOps enthusiasts to better understand the importance of building an automated CI/CD pipeline and to fully understand the benefits of doing that.
