No one likes waiting. With Continuous Delivery, now you don’t have to!
Blog: Capgemini CTO Blog
There’s a long – almost continuous – list of reasons why organizations should move to continuous delivery (CD). In this blog, I’ll discuss the benefits of doing so – for both for developers and users. I’ll also look at the best way to get started with CD.
These days, businesses expect IT to deliver new features or fix defects faster and more consistently using Agile and DevSecOps methods. In order to accomplish this in 2-3-week sprints, it’s crucial to automate CD tasks. In DevSecOps workflows, end-to-end functional testing and user acceptance testing in QA to pre-prod environments are conducted in the CD phase. These types of testing take time, so focusing on the CD phase and automating CD tasks is critical for successful DevSecOps. Moreover, unit testing is done in the development environment by a developer during continuous integration (CI) and after the code merges to the main branch, independent validation is done in the CD phase. Therefore, implementing CD is critical for the quality of deliverables.
Out of patience and on to Continuous Delivery
Continuous delivery offers developers three main benefits. First of all, there is “no waiting for environments.” As part of a CD environment, provisioning is automated, and environments are created on demand using Infrastructure-as-a-Code (IaaC). Developers don’t have to wait for the creation of new environments or reworks due to manual provisioning. The second benefit is that there is “no waiting for testing feedback.” During the CD phase, testing teams write automated test cases for functional testing to UAT. Developers can fail early, but make the necessary fixes, as they are receiving faster feedback from testers. Finally, the third benefit is “code quality and security scans.” These are integrated into CD workflows – and any critical or major vulnerabilities can be detected and fixed early.
No waiting, no defects, no problem
CD offers even more benefits to users. Since it recommends testing in lower environments and adopting a culture of failing fast, code is promoted with fewer (or no) defects to higher environments, resulting in better quality of deliverables. CD also leads to reduced technical debt since it recommends a test coverage of over 95%, meaning that no newer debt is added. As part of sprint planning and automation, teams attain the bandwidth to fix technical debt. As part of CD development, testing, release, and environment provisioning are automated. This reduces process and wait times for resources and feedback – and in turn – lowers development and testing costs.
CD requires designing, implementing, and enforcing stringent quality gates for code promotion through to production. This improves the stability of production environments and reduces tickets and incidents, while lowering operational costs. Finally, with improved deliverable quality, production environments are stable, highly available, and newer features are released more frequently. This leads to substantially improved customer satisfaction and loyalty.
There are many reasons to adopt CD – both for users and developers – and the best way to get started is to choose a CD orchestration tool for building the workflow. Next, it is important to create production-like environments and implement continuous testing. Then, you have to design and implement promotion-quality gates from quality assurance and production environments. Finally, it’s time to automate workflows. Throughout the process, it’s important to avoid certain common mistakes. The first is not having the required environments or production-like environments. Many newcomers also do not conduct enough automated testing. We’ve also seen a lack of CD skills such as release automation, the ability to set up code quality gates, security testing (static, dynamic, etc.), which can decrease the chances of a successful transformation.