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 and, when releasing the software, without doing so manually. It aims at building, testing, and releasing software with greater speed and frequency. 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. CD contrasts with continuous deployment, a similar approach in which software is also produced in short  cycles but through automated deployments rather than manual ones. Relationship to DevOps. Continuous delivery and DevOps are similar in their meanings and are often conflated, but they are two different concepts. DevOps has a broader scope, and centers around 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. 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. Thus, DevOps can be  a product of continuous delivery, and CD flows directly into DevOps. Relationship to continuous deployment. Continuous delivery is the ability to deliver software that can be deployed at any time through manual releases; this is in contrast to continuous deployment which uses automated deployments. According to Martin Fowler, continuous deployment requires continuous delivery. Academic literature differentiates between the two approaches according to deployment method; manual vs. automated. Principles. Continuous delivery treats the commonplace notion of a "deployment pipeline" as a lean Poka-Yoke: 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. 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. 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. 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. 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. These ASRs require a high priority and cannot be traded off lightly. Microservices are often used when architecting for continuous delivery. The use of Microservices can increase a software system's deployability and modifiability. The observed deployability improvements include: deployment independence shorter deployment time, simpler deployment procedures, and zero downtime deployment. The observed modifiability improvements include: shorter cycle time for small incremental functional changes, easier technology selection changes, incremental quality attribute changes, and easier language and library upgrades. Implementation and usage. The CD book written by Jez Humble and David Farley (2010) 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. The difference in domains, e.g. medical vs. web, is still significant and affects the implementation and usage. Well-known companies that have this approach include Yahoo!, Amazon, Facebook, Google, Paddy Power and Wells Fargo. Benefits and obstacles. Several benefits of continuous delivery have been reported. Obstacles have also been investigated. Eight further adoption challenges were raised and elaborated on by Chen. These challenges are in the areas of organizational structure, processes, tools , infrastructure, legacy systems, architecting for CD, continuous testing of non-functional requirements, and test execution optimization. Strategies to overcome adoption challenges. Several strategies to overcome continuous delivery adoption challenges have been reported.