Continuous delivery

Continuous Delivery (CD) is a software engineering approach in which teams keep producing valuable software in short cycles and ensure that the software can be reliably released at any time.[1] It is used in software development to automate and improve the process of software delivery. Techniques such as automated testing and continuous integration (CI) allow software to be developed to a high standard and easily packaged and deployed to test environments, resulting in the ability to rapidly, reliably and repeatedly push out enhancements and bug fixes to customers at low risk and with minimal manual overhead. CD builds on CI by adding the regular deployments to production as part of the process, however CD is not a requirement of CI. The technique (CD) was one of the assumptions of extreme programming but at an enterprise level has developed into a discipline of its own, with job descriptions for roles such as "buildmaster" calling for CD skills as mandatory.

Principles

Continuous delivery treats the commonplace notion of a deployment pipeline[2] as a lean Poka-Yoke:[3] 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.[4] 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.

Implementation and usage

Continuous Delivery has been implemented in many different places, e.g. Amazon.com, Facebook, Google,[5] Paddy Power [1] and Wells Fargo.[6]

Benefits

Several benefits of Continuous Delivery have been reported.[1]

See also

Further reading

References

  1. ↑ 1.0 1.1 1.2 Chen, Lianping (2015). "Continuous Delivery: Huge Benefits, but Challenges Too". IEEE Software 32 (2): 50. doi:10.1109/MS.2015.27.
  2. ↑ Jez Humble, Chris Read, Dan North (2006). "The Deployment Production Line". IEEE Computer Society. Proceedings of Agile 2006.
  3. ↑ Fitzgerald, Brian (2014-06-03). Continuous Software Engineering and Beyond: Trends and Challenges. 1st International Workshop on Rapid Continuous Software Engineering. New York, NY: Association for Computing Machinery. pp. 1–9. doi:10.1145/2593812.2593813. ISBN 978-1-4503-2856-2. Retrieved 2014-10-24.
  4. ↑ Kluge, Lars (12 September 2013). "Continuous Deployment with MongoDB at Kitchensurfing". slideshare.net. Retrieved 3 January 2014.
  5. ↑ Humble, Jez (13 February 2014). "The Case for Continuous Delivery". thoughtworks.com. Retrieved 16 July 2014.
  6. ↑ jFrog (December 2014). "2014-year-continuous-integration-revolution".

External links