Continuous delivery

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.[1] It aims at building, testing, and releasing software faster and more frequently. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.

Relationship to DevOps

Continuous delivery and DevOps are similar in their meanings and are often conflated, but they are two different concepts.[2] DevOps has a broader scope,[3] and centers around the cultural change, specifically the collaboration of the various teams involved in software delivery (developers, operations, quality assurance, management, etc.), as well as automating the processes in software delivery.[3] Continuous delivery, on the other hand, is an approach to automate the delivery aspect, and focuses on bringing together different processes and executing them more quickly and more frequently.[4] Thus, DevOps can be a product of continuous delivery, and CD flows directly into DevOps.

Relationship to continuous deployment

Continuous delivery is sometimes confused with continuous deployment. Continuous deployment means that every change is automatically deployed to production. Continuous delivery means that the team ensures every change can be deployed to production but may choose not to do it, usually due to business reasons. In order to do continuous deployment one must be doing continuous delivery.[5]

Principles

Continuous delivery treats the commonplace notion of a deployment pipeline[6] as a lean Poka-Yoke:[7] a set of validations through which a piece of software must pass on its way to release. Code is compiled if necessary and then packaged by a build server every time a change is committed to a source control repository, then tested by a number of different techniques (possibly including manual testing) before it can be marked as releasable.

Developers used to a long cycle time may need to change their mindset when working in a CD environment. It is important to understand that any code commit may be released to customers at any point. Patterns such as feature toggles can be very useful for committing code early which is not yet ready for use by end users. Using NoSQL can eliminate the step of data migrations and schema changes, often manual steps or exceptions to a continuous delivery workflow.[8] Other useful techniques for developing code in isolation such as code branching are not obsolete in a CD world, but must be adapted to fit the principles of CD - for example, running multiple long-lived code branches can prove impractical, as a releasable artifact must be built early in the CD process from a single code branch if it is to pass through all phases of the pipeline.

Deployment pipeline

Continuous delivery is enabled through the deployment pipeline. The purpose of the deployment pipeline has three components: visibility, feedback, and continually deploy.[9]

Tools/tool types

Continuous delivery takes automation from source control all the way through production. There are various tools that help accomplish all or part of this process.[10] These tools are part of the deployment pipeline which includes continuous delivery. The types of tools that execute various parts of the process include: continuous integration, application release automation, build automation, application lifecycle management.[11]

Architecting for continuous delivery

To practice continuous delivery effectively, software applications have to meet a set of Architecturally Significant Requirements (ASRs) such as deployability, modifiability, and testability.[12] These ASRs require a high priority and cannot be traded off lightly anymore.

Implementation and usage

The CD book written by Jez Humble and David Farley popularized the term, however since its creation the definition has continued to advance and now has a more developed meaning. Companies today are implementing these continuous delivery principles and best practices. Difference in domains, e.g. medical vs. web, are still significant and affect the implementation and usage.[13] Well-known companies that have this approach include Yahoo.com,[14] Amazon.com, Facebook, Google,[15] Paddy Power[1] and Wells Fargo.[16]

Benefits and obstacles

Several benefits of continuous delivery have been reported.[1][13]

Obstacles have also been investigated.[13]

Strategies to overcome adoption challenges

Several strategies to overcome continuous delivery adoption challenges have been reported.[17]

Strategies to Overcome CD Adoption Challenges
Strategy Description
Selling CD as a painkiller Identify each stakeholder's pain points that CD can solve, and sell CD as a painkiller to that stakeholder. This strategy helps to achieve buy-in from the wide range of stakeholders that a CD implementation requires.
Dedicated team with multi-disciplinary members Without a dedicated team, it can be hard to progress because employees are often assigned to work on other value streams. A multi-disciplinary team not only provides the wide range of skills required for CD implementation but also smooths the communication with related teams.
Continuous delivery of continuous delivery Organize the implementation of CD in a way that delivers value to the company as early as possible, onboarding more projects gradually, in small increments and eventually rolling out CD across the whole organization. This strategy helps justify the investment required by making concrete benefits visible along the way. Visible benefits, in turn, help to achieve the sustained company support and investment required to survive the long and tough journey to CD.
Starting with easy but important applications When selecting the first few applications to migrate to CD, choose the ones that are easy to migrate but that are important to the business. Being easy to migrate helps to demonstrate the benefits of CD quickly, which can prevent the implementation initiative from being killed. Being important to the business helps to secure the required resources, demonstrates clear and unarguable value, and raises the visibility of CD in the organization.
Visual CD pipeline skeleton Give a team a visual CD pipeline skeleton that has the full CD pipeline view but with empty stages for those they cannot implement yet. This helps to build up a CD mindset and maintain the momentum for CD adoption. The pipeline skeleton is especially useful when the team's migration to CD requires a large effort and mindset changes over a long period of time.
Expert drop Assign a CD expert to join tough projects as a senior member of the development team. Having the expert on the team helps to build the motivation and momentum to move to CD from inside the team. It also helps to maintain momentum when the migration requires a large effort and a long period of time.

See also

Further reading

References

  1. 1 2 3 Chen, Lianping (2015). "Continuous Delivery: Huge Benefits, but Challenges Too". IEEE Software. 32 (2): 50–54. doi:10.1109/MS.2015.27.
  2. ↑ Hammond, Jeffrey (9 September 2011). "The Relationship between DevOps and Continuous Delivery". Forrester Research. Forester.
  3. 1 2 Humble, Jez; Farley, David (2011). Continuous Delivery: reliable software releases through build, test, and deployment automation. Pearson Education Inc. ISBN 978-0-321-60191-9.
  4. ↑ Swartout, Paul (2012). Continuous Delivery and DevOps: A Quickstart guide. Packt Publishing. ISBN 978-1849693684.
  5. ↑ "bliki: ContinuousDelivery". martinfowler.com. Retrieved 2015-10-29.
  6. ↑ Jez Humble; Chris Read; Dan North (2006). "The Deployment Production Line". IEEE Computer Society. Proceedings of Agile 2006.
  7. ↑ Fitzgerald, Brian (2014-06-03). Continuous Software Engineering and Beyond: Trends and Challenges (PDF). 1st International Workshop on Rapid Continuous Software Engineering. New York, NY: Association for Computing Machinery. pp. 1–9. ISBN 978-1-4503-2856-2. doi:10.1145/2593812.2593813. Retrieved 2014-10-24.
  8. ↑ Kluge, Lars (12 September 2013). "Continuous Deployment with MongoDB at Kitchensurfing". slideshare.net. Retrieved 3 January 2014.
  9. ↑ Duvall, Paul (2012). "Continuous Delivery: Patterns and Anti-Patterns in Software Lifecycle" (PDF). Refcardz. Retrieved October 9, 2015.
  10. ↑ Phillips, Andrew (29 July 2014). "The Continuous Delivery Pipeline – What it is and Why it's so important in Developing Software". DevOps.com. Retrieved October 9, 2015.
  11. ↑ Binstock, Andrew (16 September 2014). "Continuous Delivery: The Agile SUccessor". Dr. Dobb's The world of software Development. San Francisco: UBM.
  12. ↑ Chen, Lianping (2015). Towards Architecting for Continuous Delivery. The 12th Working IEEE/IFIP Conference on Software Architecture(WICSA 2015). Montréal, Canada: IEEE.
  13. 1 2 3 Leppänen, M.; Mäkinen, S.; Pagels, M.; Eloranta, V. P.; Itkonen, J.; Mäntylä, M. V.; Männistö, T. (2015-03-01). "The Highways and Country Roads to Continuous Deployment". IEEE Software. 32 (2): 64–72. ISSN 0740-7459. doi:10.1109/MS.2015.50.
  14. ↑ "Implementing Continuous Delivery at Yahoo!". confreaks.tv. 23 October 2013.
  15. ↑ Humble, Jez (13 February 2014). "The Case for Continuous Delivery". thoughtworks.com. Retrieved 16 July 2014.
  16. ↑ jFrog (December 2014). "2014-year-continuous-integration-revolution".
  17. ↑ Chen, Lianping (2017). "Continuous Delivery: Overcoming adoption challenges". Journal of Systems and Software. 128: 72–86. doi:10.1016/j.jss.2017.02.013.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.