Continuous Delivery

Continuous delivery DevOps process. Source: ATC Team 2019.
Continuous delivery DevOps process. Source: ATC Team 2019.

Continuous Delivery (CD) goes one step further from Continuous Integration (CI). It ensures that every code change is tested and ready for the production environment, after a successful build. CI ensures every code is committed to the main code repository whereas CD ensures the system is in an executable state at all times, after changes to code.

The primary goal of Continuous Delivery is to make software deployments painless, low-risk events that can be performed at any time, on demand. However, the actual process of automatic deployment in the target customer environment comes under Continuous Deployment (CD).

Continuous Delivery can work only if Continuous Integration is in place. It involves running extensive regression, UI, and performance tests to ensure that the code is production-ready. It's applicable to both bug fixes and new feature releases.

Discussion

  • What's the need for Continuous Delivery?
    Comparing waterfall and continuous delivery approaches. Source: Hailey 2015, slide 13.
    Comparing waterfall and continuous delivery approaches. Source: Hailey 2015, slide 13.

    In a typical waterfall lifecycle, a customer release (minor or major) is a huge milestone requiring months of effort. The entire team is geared towards this milestone. Features going into the release are managed as a batch – developed, tested and integrated into the main branch. There's a high price to pay for failed releases, high pressure to meet deadlines. Customers also wait for long periods without getting fixes for their issues. There's a significant downtime when the release patch is being applied.

    Contrast this with the short release lifecycle of Agile model. Here the features can be checked into the main repository as often as every day (Continuous Integration). Automated unit/regression/system test suites ensure the newly committed code is immediately sanctified. Impact on related features is verified. If this code can then be immediately released to customers, then the whole pressure around a customer release is removed. Release becomes a frequent, low risk, automated event. Manual errors in the release process are eliminated. Urgent fixes and patches can be released even during holidays, with minimal staff. This is why Continuous Delivery evolved.

  • What are the benefits of Continuous Delivery?

    CD is impossible without automation of build and test processes. Automation is therefore the first benefit. The entire process gets automated: code commit → system integration build → unit test → regression test → system test. This results in several direct and indirect benefits:

    • Smaller maintenance and support teams: Apart from developers, product teams generally maintain several parallel maintenance teams. In the traditional model, each team consisting of build/integration/test members is dedicated to a release version. However, in the automated CD process, these tasks happen without human intervention without compromising product quality.
    • Reducing risk of failure for customer releases: CD aims to make production changes safe and routine. Deploying to production becomes a boring non-event that can be performed as often as needed. Since the magnitude of code change in each release is very small, risk of failure is also minimised.
    • Enforces process discipline in the team: Since code is always meant to be production ready, team members are constantly tuning their code, refactoring, reviewing, automating repetitive build tasks, reworking test scripts and getting feature-related documentation done without any delays.
  • Can you explain with an example case study?
    Elements of Continuous Delivery at AWS. Source: Dissanayake 2018.
    Elements of Continuous Delivery at AWS. Source: Dissanayake 2018.

    Continuous Delivery is used to enable online controlled experiments (A/B Testing) at Amazon.

    Amazon (Microsoft, Booking.com, Facebook and Google too) conducts more than 10,000 online controlled experiments annually, engaging millions of users. Developing these experimental features doesn't require much effort. They're deployed to gauge customer reaction and measure their effectiveness.

    One such experiment at Amazon revealed that moving credit card offers from its home page to the shopping cart page boosted profits by tens of millions of dollars annually. In fact, Amazon makes changes to production code every 11.6 seconds on average (May 2011).

    Ken Exner, Director of AWS, Amazon explains the transformational impact of CD, "One of the main uses of Continuous Delivery is to ensure we are building functionality that really delivers the expected customer value. This approach created hundreds of millions of dollars of value for Amazon, and saved similar amounts through reducing the opportunity cost of building features that were not in fact valuable (even if delivered on time, on budget, and at high quality). This approach depends on the ability to perform extremely frequent releases."
  • How does Continuous Delivery work?
    The CI/CD pipeline. Source: RedHat 2021.
    The CI/CD pipeline. Source: RedHat 2021.

    By the end of Continuous Integration, production code has been committed to version control such as Git, build has been completed and automated unit testing has been performed.

    Taking things further in CD, unit tested code is automatically transferred to a test environment and/or a production environment after the build stage. Test driven development is followed - implementing a short test/code cycle, ideally coding a single requirement to pass a single test case.

    Next, we execute relevant regression test cases. Validated executables are uploaded to a repository (like GitHub or container registry), ready for deployment to a live production environment by operations team. CI/CD tools like Jenkins are used to perform these pipeline steps.

    In the case of failure at any step, code rollbacks are also automated into this pipeline. This preserves the sanctity of production code.

    Approval for deployment is the last step in the task pipeline. To decide whether a feature is ready for deployment, a designated person may approve through a workflow or ticketing system. In the next paradigm of Continuous Deployment, this step is also part of the automated pipeline.

  • What are the challenging scenarios for implementing Continuous Delivery?

    Continuous Delivery is difficult to implement in particular types of projects and scenarios (though benefits are realized once implemented):

    • Open-ended research projects: Since such projects generally deal with new, experimental technologies that may not have a customer identified yet, production code is not meant for customer deployment. Team might still implement Continuous Integration, but may not have a system testing environment yet. CD can be done later in such cases.
    • Large legacy projects with low test automation: Projects with high level of manual interventions (approval hierarchies, security checklists) built into their system and processes will find it difficult to migrate to the CD paradigm.
    • System architecture limitations: Large monolithic architectures are difficult to automate, scale or debug. In contrast, products with modular and scalable architecture are conducive to CD. Impacted functions are easy to localise and manage every time there's a code update. Microservices, SOA, web applications are good examples of CD success stories.
    • Open-source collaborative development: With several peer developers working in parallel, open-source platforms require an equally robust build configuration and test automation team. Otherwise, it becomes difficult to synchronise their work, making implementation of CD difficult.
  • What are some best practices for implementing Continuous Delivery?

    Here are some CD best practices:

    • Version Control: Your repository be the single source of truth for code, configuration, documentation, and even the database. Avoid local or one-off changes.
    • Automation: Automate processes and tasks for consistency across all environments. Avoid manual intervention.
    • Build Once: Commit build artefacts and reuse them across environments. This saves time and improves consistency.
    • Bite-Sized: Keep commits small since problems are easier to track down and fix.
    • Speed: The CD pipeline must be fast so that it provides quick feedback to developers. Where possible, parallelize tasks.
    • Smoke Test: This isn't full testing but it can be run frequently and quickly. It's designed to quickly detect basic problems.
    • Staging: Deploy and test in an environment that mirrors the production environment.
    • Metrics: Measure and monitor in terms of code coverage, test success rate, support tickets, deployment failures, performance, percentage of code changed, etc.

Milestones

2010

Jez Humble and David Farley, employees of Google and ThoughtWorks respectively, release the book titled Continuous Delivery. This popularizes the term for the first time.

2014

Several traditional companies talk about their DevOps journey and experiences with Continuous Delivery at the DevOps Enterprise Summit 2014 and 2015.

2015

Jez Humble and David Farley start their own company named Continuous Delivery Ltd. It's founded to help organisations achieve their software ambitions, to release world-class software that will delight their users.

References

  1. ATC Team. 2019. "What Is Continuous Delivery? The Benefits and Best Practices." DZone, May 29. Accessed 2021-06-13.
  2. Allspaw, John and Paul Hammond. 2009. "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr." Presentation at Velocity 2009, via O'Reilly on YouTube, June 25. Accessed 2021-06-13.
  3. Copado. 2021. "Moving Forward with These CI/CD Best Practices." Blog, Copado, June 15. Accessed 2021-07-25.
  4. Dissanayake, Madura. 2018. "AWS CodePipeline for Continuous Delivery and Continuous Integration." disamTECHbench Blog, January 03. Accessed 2021-06-13.
  5. Farley, Dave. 2021. "About." Dave Farley's Weblog. Accessed 2021-06-13.
  6. Flexagon. 2021. "How Does Continuous Delivery Work?" Accessed 2021-06-13.
  7. Hailey, Kyle. 2015. "What is DevOps?!" Delphix, via SlideShare, April 23. Accessed 2021-07.25.
  8. Heller, Martin. 2015. "Continuous integration: The answer to life, the universe, and everything?" TeachBeacon, July 20. Accessed 2021-07-25.
  9. Hodgson, Pete. 2020. "You Might Not Need Continuous Deployment." Blog, Split Software, Inc., April 02. Accessed 2021-06-13.
  10. Humble, Jez. 2014. "The Case for Continuous Delivery." Blog, ThoughtWorks, February 13. Accessed 2021-06-13.
  11. Humble, Jez. 2017. "What is Continuous Delivery?" Accessed 2021-06-13.
  12. Humble, Jez. 2017b. "Evidence and case studies." Accessed 2021-06-13.
  13. Humble, Jez. 2017c. "Continuous Delivery Sounds Great, but Will It Work Here?" Queue, ACM, vol. 15, no. 6, November-December. Accessed 2021-07-25.
  14. Kohavi, Ron and Stefan Thomke. 2017. "The Surprising Power of Online Experiments." Harvard Business Review, September-October. Accessed 2021-07-25.
  15. Lamm, Dan. 2021. "Continuous Delivery Tools to Consider." Blog, Harness, March 10. Accessed 2021-06-13.
  16. Rawat, Satendra. 2020. "Continuous integration and deployment for open source project." Blog, Chintu Gudiya Foundation, June 05. Accessed 2021-06-13.
  17. RedHat. 2021. "What is CI/CD?" RedHat, Inc. Accessed 2021-06-13.
  18. Skelton, Matthew. 2018. "9 ways organizations screw up continuous delivery." TechBeacon, May 8. Accessed 2021-07-25.
  19. Sumo Logic. 2015. "What is Continuous Delivery?" Sumo Logic, May 31. Accessed 2021-06-13.
  20. Synopsys. 2021. "Continuous Delivery." Glossary, Synosys, Inc. Accessed 2021-06-13.
  21. Wikipedia. 2021. "Continuous Delivery." Wikipedia, May 26. Accessed 2021-06-13.
  22. Yehuda, Yaniv. 2016. "7 Best Practices for Continuous Delivery Success." DevOps.com, November 9. Accessed 2021-07-25.
  23. Zend. 2020. "What Are Some of the Advantages of Continuous Delivery? What Are the Common Barriers?" Blog, Perforce Software, Inc., February 24. Accessed 2021-06-13.

Further Reading

  1. ThoughtWorks. 2017. "Continuous Delivery 101." Playlist on YouTube, ThoughtWorks Products, March-April. Accessed 2021-07-25.
  2. Humble, Jez. 2017b. "Evidence and case studies." Accessed 2021-06-13.
  3. Humble, Jez. 2014. "The Case for Continuous Delivery." Blog, ThoughtWorks, February 13. Accessed 2021-06-13.
  4. Allspaw, John and Paul Hammond. 2009. "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr." Presentation at Velocity 2009, via O'Reilly on YouTube, June 25. Accessed 2021-06-13.

Article Stats

Author-wise Stats for Article Edits

Author
No. of Edits
No. of Chats
DevCoins
User avatar anuradhac
4
1
1127
Avatar of user arvindpdmn arvindpdmn
3
8
498
DevCoins due to articles, chats, their likes and article hits are included.
1353
Words
2
Authors
7
Edits
9
Chats
3
Likes
7062
Hits

Cite As

Devopedia. 2021. "Continuous Delivery." Version 7, July 25. Accessed 2023-11-12. https://devopedia.org/continuous-delivery
Contributed by
2 authors

Last updated on
2021-07-25 12:54:31

Improve this article

Article Warnings

  • Readability score of this article is below 50 (45.3). Use shorter sentences. Use simpler words.