Part of a series on |
Software development |
---|
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] [2] It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time,[ citation needed ] 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.
Continuous delivery treats the commonplace notion of a deployment pipeline [3] as a lean Poka-Yoke: [4] 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. 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. [5] 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.[ clarification needed ]
Continuous delivery is enabled through the deployment pipeline. The purpose of the deployment pipeline has three components: visibility, feedback, and continually deploy. [6]
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. [7] 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. [8]
To practice continuous delivery effectively, software applications have to meet a set of architecturally significant requirements (ASRs) such as deployability, modifiability, and testability. [9] These ASRs require a high priority and cannot be traded off lightly.
Microservices are often used when architecting for continuous delivery. [10] 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. [10]
The original 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. [11] Well-known companies that have this approach include Yahoo!, [12] Amazon, [13] Facebook, [14] Google, [15] Paddy Power [1] and Wells Fargo. [16]
Several benefits of continuous delivery have been reported. [1] [11]
Obstacles have also been investigated. [11]
Eight further adoption challenges were raised and elaborated on by Chen. [17] These challenges are in the areas of organizational structure, processes, tools, infrastructure, legacy systems, architecting for continuous delivery, continuous testing of non-functional requirements, and test execution optimization.
![]() | This section contains instructions, advice, or how-to content .(January 2022) |
Several strategies to overcome continuous delivery adoption challenges have been reported. [17]
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. |
DevOps is a software engineering approach that 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. [18] [19] [20]
Continuous deployment is a software engineering approach which uses automated software deployments. [17] In it, software is produced in short cycles but through automated software deployments even to production rather than requiring a "click of a button" for that last step. [1] : 52 Therefore, continuous deployment can be considered a more sophisticated form of automation. [21] Academic literature differentiates between continuous delivery and continuous deployment according to deployment method; manual vs. automated. [2] [22]
Continuous integration (CI) is the practice of integrating source code changes frequently and ensuring that the integrated codebase is in a workable state.
Release engineering, frequently abbreviated as RE or as the clipped compound Releng, is a sub-discipline in software engineering concerned with the compilation, assembly, and delivery of source code into finished products or other software components. Associated with the software release life cycle, it was said by Boris Debic of Google Inc. that release engineering is to software engineering as manufacturing is to an industrial process:
Release engineering is the difference between manufacturing software in small teams or startups and manufacturing software in an industrial way that is repeatable, gives predictable results, and scales well. These industrial style practices not only contribute to the growth of a company but also are key factors in enabling growth.
Build automation is the practice of building software systems in a relatively unattended fashion. The build is configured to run with minimized or no software developer interaction and without using a developer's personal computer. Build automation encompasses the act of configuring the build system as well the resulting system itself.
AnthillPro is a software tool originally developed and released as one of the first continuous integration servers. AnthillPro automates the process of building code into software projects and testing it to verify that project quality has been maintained. Software developers are able to identify bugs and errors earlier by using AnthillPro to track, collate, and test changes in real time to a collectively maintained body of computer code.
Release management is the process of managing, planning, scheduling and controlling a software build through different stages and environments; it includes testing and deploying software releases.
DevOps is a methodology in the software development and IT industry. Used as a set of practices and tools, DevOps integrates and automates the work of software development (Dev) and IT operations (Ops) as a means for improving and shortening the systems development life cycle. DevOps is complementary to agile software development; several DevOps aspects came from the agile way of working.
Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate. Continuous testing was originally proposed as a way of reducing waiting time for feedback to developers by introducing development environment-triggered tests as well as more traditional developer/tester-triggered tests.
Application-release automation (ARA) refers to the process of packaging and deploying an application or update of an application from development, across various environments, and ultimately to production. ARA solutions must combine the capabilities of deployment automation, environment management and modeling, and release coordination.
Continuous deployment (CD) is a software engineering approach in which software functionalities are delivered frequently and through automated deployments.
BuildMaster is an application release automation tool, designed by the software development team Inedo. It combines build management and ARA capabilities to manage and automate processes primarily related to continuous integration, database change scripts, and production deployments, overall releasing applications reliably. The tool is browser-based and able to be used "out-of-the-box". Its feature set and scope puts it in line with the DevOps movement, and is marketed as "more than a release automatigs together the people, processes, and practices that allow teams to deliver software rapidly, reliably, and responsibly.” It's a tool that embodies incremental DevOps adoption.
In software engineering, a microservice architecture is an architectural pattern that arranges an application as a collection of loosely coupled, fine-grained services, communicating through lightweight protocols. One of its goals is to enable teams to develop and deploy their services independently. This is achieved by reducing several dependencies in the codebase, allowing developers to evolve their services with limited restrictions, and hiding additional complexity from users. Consequently, organizations can develop software with rapid growth and scalability, as well as use off-the-shelf services more easily. Communication requirements are reduced. These benefits come with the cost of maintaining decoupling, so a microservice architecture may be suitable only if the application is too complex to manage as a monolith. Interfaces need to be designed carefully and treated as public API. One technique used is having multiple interfaces on the same service or multiple versions of the same service to avoid disrupting existing users of the code.
DBmaestro is a computer software company with sales headquartered in Boston. It markets its services for DevOps collaboration between development and IT operations teams.
Wercker is a Docker-based continuous delivery platform that helps software developers build and deploy their applications and microservices. Using its command-line interface, developers can create Docker containers on their desktop, automate their build and deploy processes, testing them on their desktop, and then deploy them to various cloud platforms, ranging from Heroku to AWS and Rackspace. The command-line interface to Wercker has been open-sourced.
A DevOps toolchain is a set or combination of tools that aid in the delivery, development, and management of software applications throughout the systems development life cycle, as coordinated by an organisation that uses DevOps practices.
Continuous configuration automation (CCA) is the methodology or process of automating the deployment and configuration of settings and software for both physical and virtual data center equipment.
In software engineering, CI/CD or CICD is the combined practices of continuous integration (CI) and continuous delivery (CD) or, less often, continuous deployment. They are sometimes referred to collectively as continuous development or continuous software development.
MLOps or ML Ops is a paradigm that aims to deploy and maintain machine learning models in production reliably and efficiently. The word is a compound of "machine learning" and the continuous delivery practice (CI/CD) of DevOps in the software field. Machine learning models are tested and developed in isolated experimental systems. When an algorithm is ready to be launched, MLOps is practiced between Data Scientists, DevOps, and Machine Learning engineers to transition the algorithm to production systems. Similar to DevOps or DataOps approaches, MLOps seeks to increase automation and improve the quality of production models, while also focusing on business and regulatory requirements. While MLOps started as a set of best practices, it is slowly evolving into an independent approach to ML lifecycle management. MLOps applies to the entire lifecycle - from integrating with model generation, orchestration, and deployment, to health, diagnostics, governance, and business metrics.
TestOps refers to the discipline of managing the operational aspects of testing within the software delivery lifecycle.
Mobile DevOps is a set of practices that applies the principles of DevOps specifically to the development of mobile applications. Traditional DevOps focuses on streamlining the software development process in general, but mobile development has its own unique challenges that require a tailored approach. Mobile DevOps is not simply as a branch of DevOps specific to mobile app development, instead an extension and reinterpretation of the DevOps philosophy due to very specific requirements of the mobile world.
DevOps Research and Assessment is a team that is part of Google Cloud that engages in opinion polling of software engineers to conduct research for the DevOps movement.
Continuous deployment is the natural outcome of continuous delivery done well. Eventually, the manual approval delivers little or no value and is merely slowly things down. At that point, it is done away with and continuous delivery becomes continuous deployment.