CI/CD as a driver of software delivery performance
July 3, 2022
2332 words
11 minutes to read
Deployment speed and frequency are paramount to the success of modern businesses. As technology develops and the ties between customers and businesses deepen, businesses need to become more reactive to changes in their industries to survive and stay competitive. This applies to software firms and any company that uses software to connect with its customers.
That’s where continuous integration (CI), continuous delivery (CDE), and continuous deployment (CD) – collectively called CI/CDE/CD (Bobrovskis and Jurenoks, 2018) – come into play. Although CI/CDE/CD promotes cultural changes just like Agile or DevOps, it encompasses actual code and tools that streamline the deployment of software to production. CI/CDE/CD can support DevOps and Agile and bring them to life in an organization.
In this post, we will outline the CI/CDE/CD process and explain how CI/CDE/CD can deliver value for businesses. Let’s start by better understanding what each of the phases in CI/CDE/CD means.
What is continuous integration?
Continuous integration, or CI, is a practice where developers merge (integrate) their code into their main development branch as frequently as they can (Amazon Web Services, 2022a); Ståhl and Bosch, 2014). After the code is integrated into a centralized repository like Git, a CI service builds the project and runs automated unit tests to ensure that the code is working and meets internal quality standards.
The primary purpose of continuous integration is to allow teams to fix bugs quicker and improve code quality. Without continuous integration, developers may go on to work on their code for extended periods – days or even weeks – before committing their changes to the main branch. Throughout those days or weeks, the code may accumulate bugs that might not be evident in isolation but can show up instantly when combined with the work of others.
If developers commit code frequently – up to several times per day – and in small chunks, they can quickly catch issues. Not only that, but if their commits are small, developers will be able to quickly fix bugs or make changes in their code so that it is more compatible with the work of others.
What is continuous delivery?
Continuous delivery, or CDE, directly follows continuous integration in a software delivery pipeline. CDE automates the transition of code changes from CI into a testing or staging environment (Amazon Web Services, 2022b). CDE is “a software development discipline in which the software is kept in such a state that in principle, it could be released to its users at any time” (Laukkanen, et a., 2017, p. 55). A CDE service performs additional tests in the staging environment and prepares the code for production deployment.
The tests at the CDE stage can be much more rigorous than in CI and can incorporate integration testing, UI testing, load testing, API reliability testing, and security testing. CDE essentially performs end-to-end tests to ensure that the updated code is fully functional and meets quality standards.
After the code passes the test process of CDE, developers can approve its deployment to production. Deployment can be done at any time, though CDE encourages deployment as soon as the code has been tested and validated.
CDE additionally encourages developers to standardize the testing procedures of their code. Standardization enables developers to develop automated testing routines for their products quickly. As a result, CDE can significantly accelerate the deployment of code to production.
What is continuous deployment?
Continuous deployment (CD) is an extension of CDE in that it automates the deployment of code to a production environment. CD “refers to the practice of deploying the software to some environment, but not automatically delivering to customers” (Fitzgerald and Stol, 2014, June, p. 3). On top of the automated testing routines that continuous delivery has, continuous deployment makes code available to customers automatically without manual approval from developers.
Continuous deployment requires no developers’ intervention except when the code fails to pass the automated tests. When this happens, developers can investigate what went wrong and make changes to the code. Like continuous delivery, continuous deployment is often abbreviated as CD. This often causes confusion, which is amplified by the similarities between the two processes.
The key thing to remember is that CDE and CD nearly are the exact same thing, with the only difference being that continuous deployment deploys code to production automatically, without an extra layer of approval from developers.
The purpose of continuous deployment is the same as with continuous delivery, but it adds an extra bit of automation to the software delivery process. While manual approval arguably introduces trivial delays to software delivery, continuous deployment is a good practice to follow if there’s no need for code to be manually approved. Continuous deployment can be especially beneficial if code is deployed to production several times per day because it can help developers save a lot of time in the long run.
The improvements that CI/CDE/CD can bring to businesses
Continuous integration, delivery, and deployment can dramatically change software delivery speed. At a high level, here’s how CI/CDE/CD workflows compare with software delivery pipelines that don’t use CI/CDE/CD.
| With CI/CDE/CD | Without CI/CDE/CD | |
|---|---|---|
| INTEGRATION | ||
| Integration frequency | Code is integrated frequently, up to several times per day. | Code is integrated infrequently, possibly on a weekly or monthly basis. |
| Code compatibility | Commits are more incremental, meaning that small code changes from different developers are more likely to work with each other without issues. | The chance of compatibility issues is higher because big pieces of code might have many dependencies or logic that is incompatible with the work of others. |
| Debugging speed | Bugs are detected more frequently and are solved more quickly. | Bugs tend to pile up over the long term, which can delay and complicate their fixing. |
| TESTING | ||
| Automation | Testing is standardized and easily automated. | Testing is unstandardized, fully, or partially manual, and cannot be easily automated. |
| Involvement of engineers and developers | Minimal involvement of QA engineers and developers is required. | QA engineers and developers are tightly involved in testing. |
| Duration | The whole testing phase can be performed in just minutes thanks to automation. | Testing can last for days or perhaps even weeks, depending on how much manual work needs to be done. |
| Logging and error reporting | CI/CDE/CD software often has advanced logging and error reporting tools that provide detailed information about failures and bugs. | Manual debugging and code exploration may be necessary to detect the root cause of test failures. |
| DEPLOYMENT | ||
| Automation | Deployment is performed automatically (with continuous deployment) or only requires approval after testing (with continuous delivery). | Deployment is done manually. Developers may need to manually configure, package, and release new code. |
| Time to deploy | Code may be deployed just minutes after integration, assuming that all the tests were successful. | New code may take hours, days, or weeks to deploy, depending on its priority and the existing commitments of developers. |
| Frequency | New code can be deployed very frequently, up to multiple times per day. | New code may be deployed extremely infrequently, as infrequently as once every six months. |
When implemented properly and with the maximum possible degree of automation, CI/CDE/CD can reduce the time from code integration to deployment to just minutes. In a continuous deployment pipeline with automatic deploys, integrated code can be deployed to production immediately with no staff intervention.
With all this in mind, we can identify the following 4 benefits of CI/CDE/CD for businesses:
- Software can be updated and adapted to changing customer needs very quickly. With a strong CI/CDE/CD workflow, bugs and issues can be fixed in just a few hours after their discovery in production. Developers can also add new features or fixes to meet the needs of end users in a minimum time (Virmani, 2015, May).
- Quality and security of code significantly improve. This point has two aspects. First, frequent integration allows developers to quickly catch and fix issues in their work. Secondly, developers can add more thorough automated test procedures to their CI/CDE/CD workflows with minimal effect on the time to market. More stringent testing can raise internal code quality and security standards, prompting developers to be more conscious of their work (Arachchi and Perera, 2018, May).
- Teams can focus more on developing new features. By potentially saving hours and weeks of development time, CI/CDE/CD can allow teams to focus better on developing new features. After integrating their code, developers can instantly start working on the next planned feature (Laukkanen, et al., 2017).
- Teams and businesses are forced to adopt a more collaborative and flexible working culture. Without collaboration, the desire to grow, and the willingness to fail fast, businesses cannot effectively implement CI/CDE/CD. The mindset and culture requirements of CI/CDE/CD may force organizations to completely rethink how they do business and optimize all their internal processes, not just those related to software delivery. With that in mind, the transition to CI/CDE/CD could bring much more than just the acceleration of software delivery (Humble and Farley, 2010).
The benefits of CI/CD in the real world
The benefits of CI/CDE/CD on paper are clear, but what actual results can CI/CDE/CD bring in the real world? CI/CDE/CD service providers like GitLab or Semaphore share numerous success stories and case studies of their clients adopting CI/CDE/CD. While the actual benefits of adopting CI/CDE/CD will vary from business to business and from industry to industry, these case studies can still give a good idea of what to expect.
Below are some of the success stories shared by GitLab and Semaphore.
- Airbus. Using GitLab CI, the aerospace company Airbus reduced the deployment time of feature releases from 24 hours to 10 minutes. The company’s projects grew from 50 to 850 in five years, while merge requests reached 10,000 per year on average. Airbus released 98% of its projects on time, while the remaining 2% were released with a delay of only a few hours. CI also drastically improved visibility into the company’s projects, removing guesswork from deployments.
- Goldman Sachs. The investment and financial services company Goldman Sachs chose GitLab to simplify and strengthen its workflows. Goldman Sachs managed to reduce the release cycle of one of its important projects from once every 1-2 weeks to once every few minutes. Feature deployment times dropped below 24 hours across many teams. Some teams started creating over 1,000 CI feature branch builds per day.
- Indeed. By switching from CircleCI and Jenkins to Semaphore 2.0, the online employment company, Indeed, decreased build times from 30 minutes to 10 minutes. Indeed has also decreased its failure rate from 25% to 2.5%, while increasing daily deploys from 3 to 10.
- Siemens. The technology company Siemens transformed its collaboration and organizational workflows by using GitLab SCM (Source Code Management), CI/CDE/CD, and DevOps. Siemens began with a main goal and challenge of building a unified DevOps culture that would work across its multiple subsidiaries with over 20,000 developers in total. To achieve its overall goals, Siemens moved its IT infrastructure to AWS to streamline collaboration across its teams. And with CI/CDE/CD, the company started producing over 6.4 million builds per month and deploying to production over 4 times a month.
- Zoopla. The British real estate company Zoopla adopted GitLab Self-Managed Premium for CI/CDE/CD, including version control, and to improve developer collaboration. As a result, Zoopla managed to reduce its change failure rates from 40% to 0%. Similarly, lead times dropped from 5 days to 2 hours, while feature deploys switched from weekly to daily frequency.
Next steps
As usual with digital transformation initiatives, CI/CDE/CD requires a careful approach. Businesses should probably start by deploying CI/CDE/CD to a few localized teams. Based on the results of initial deployment, CI/CDE/CD could then be expanded to other units in an organization.
A key thing to remember with CI/CDE/CD is that it’s not just about the tools – it’s also about the mindset and culture. Without a growth mindset and a collaborative culture, businesses may be unable to maximize the benefits of CI/CDE/CD. With that in mind, businesses can use DevOps and agile development to build the cultural foundations for change. After that, CI/CDE/CD would allow them to materialize the new culture in the real world.
To better understand how CI/CDE/CD can benefit software delivery and how it can be implemented, businesses can try software delivery simulation. Simulation can help businesses recreate their current software delivery processes and build the target CI/CDE/CD pipeline for easy side-to-side comparison. They can further make tweaks to the target system to observe how small configuration changes can affect software delivery timelines.
Consider adopting one or more inexpensive seminars to acquaint the team with the topics:
- DevOps , CI/CD (Continuous Integration/Delivery) for Beginners
- Continuous Delivery & DevOps
- Continuous Delivery and Automation on AWS for DevOps Engineers.
References:
Amazon Web Services. (2022a). What is Continuous Integration? AWS. https://aws.amazon.com/devops/continuous-integration/
Amazon Web Services. (2022b). What is Continuous Delivery? AWS. https://aws.amazon.com/devops/continuous-delivery/
Arachchi, S. A. I. B. S., & Perera, I. (2018, May). Continuous integration and continuous delivery pipeline automation for agile software project management. In 2018 Moratuwa Engineering Research Conference (MERCon) (pp. 156-161). IEEE.
Bobrovskis, S., & Jurenoks, A. (2018). A Survey of Continuous Integration, Continuous Delivery and Continuous Deployment. In BIR 2018 Short Papers, Workshops and Doctoral Consortium co-located with 17th International Conference Perspectives in Business Informatics Research (pp. 314-322).
Fitzgerald, B., & Stol, K. J. (2014, June). Continuous software engineering and beyond: trends and challenges. In Proceedings of the 1st International Workshop on Rapid Continuous Software Engineering (pp. 1-9).
Humble, J., & Farley, D. (2010). Continuous delivery: reliable software releases through build, test, and deployment automation. Pearson Education.
Laukkanen, E., Itkonen, J., & Lassenius, C. (2017). Problems, causes and solutions when adopting continuous delivery—A systematic literature review. Information and Software Technology, 82, 55-79.
Ståhl, D., & Bosch, J. (2014). Modeling continuous integration practice differences in industry software development. Journal of Systems and Software, 87, 48-59.
Virmani, M. (2015, May). Understanding DevOps & bridging the gap from continuous integration to continuous delivery. In Fifth International Conference On The Innovative Computing Technology (INTECH 2015) (pp. 78-82). IEEE.
