Continuous deployment

Last updated

Continuous deployment (CD) is a software engineering approach in which software functionalities are delivered frequently and through automated deployments. [1] [2] [3]

Contents

Continuous deployment contrasts with continuous delivery (also abbreviated CD), a similar approach in which software functionalities are also frequently delivered and deemed to be potentially capable of being deployed, but are actually not deployed. [4] As such, continuous deployment can be viewed as a more complete form of automation than continuous delivery. [5]

Motivation

A major motivation for continuous deployment is that deploying software into the field more often makes it easier to find, catch, and fix bugs. A bug is easier to fix when it comes from code deployed five minutes ago instead of five days ago. [6]

Example

In an environment in which data-centric microservices provide the functionality, and where the microservices can have multiple instances, continuous deployment consists of instantiating the new version of a microservice and retiring the old version once it has drained all the requests in flight. [7] [8] [9]

See also

Related Research Articles

Rapid application development (RAD), also called rapid application building (RAB), is both a general term for adaptive software development approaches, and the name for James Martin's method of rapid development. In general, RAD approaches to software development put less emphasis on planning and more emphasis on an adaptive process. Prototypes are often used in addition to or sometimes even instead of design specifications.

Code review is a software quality assurance activity in which one or several people check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation. At least one of the persons must not be the code's author. The persons performing the checking, excluding the author, are called "reviewers".

In software engineering, service-oriented architecture (SOA) is an architectural style that focuses on discrete services instead of a monolithic design. By consequence, it is also applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.

A software requirements specification (SRS) is a description of a software system to be developed. It is modeled after the business requirements specification(CONOPS). The software requirements specification lays out functional and non-functional requirements, and it may include a set of use cases that describe user interactions that the software must provide to the user for perfect interaction.

<span class="mw-page-title-main">Continuous integration</span> Software development practice based on frequent submission of granular changes

In software engineering, continuous integration (CI) is the practice of merging all developers' working copies to a shared mainline several times a day. Nowadays it is typically implemented in such a way that it triggers an automated build with testing. Grady Booch first proposed the term CI in his 1991 method, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day – perhaps as many as tens of times per day.

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.

In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.

A reference architecture in the field of software architecture or enterprise architecture provides a template solution for an architecture for a particular domain. It also provides a common vocabulary with which to discuss implementations, often with the aim to stress commonality. A software reference architecture is a software architecture where the structures and respective elements and relations provide templates for concrete architectures in a particular domain or in a family of software systems.

Experimental software engineering involves running experiments on the processes and procedures involved in the creation of software systems, with the intent that the data be used as the basis of theories about the processes involved in software engineering. A number of research groups primarily use empirical and experimental techniques.

<span class="mw-page-title-main">SAP ERP</span> Enterprise software

SAP ERP is an enterprise resource planning software developed by the German company SAP SE. SAP ERP incorporates the key business functions of an organization. The latest version of SAP ERP (V.6.0) was made available in 2006. The most recent SAP enhancement package 8 for SAP ERP 6.0 was released in 2016. It is now considered legacy technology, having been superseded by SAP S/4HANA.

In software engineering, a software development process is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. It is also known as a software development life cycle (SDLC). The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

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.

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.

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, following a pipeline through a "production-like environment", 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.

In software engineering, a microservice architecture is a variant of the service-oriented architecture structural style. It 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 that teams can develop and deploy their services independently of others. This is achieved by the reduction of several dependencies in the code base, allowing developers to evolve their services with limited restrictions from users, and for additional complexity to be hidden from users. As a consequence, organizations are able to develop software with fast growth and size, as well as use off-the-shelf services more easily. Communication requirements are reduced. These benefits come at a cost to maintaining the decoupling. Interfaces need to be designed carefully and treated as a public API. One technique that is used is having multiple interfaces on the same service, or multiple versions of the same service, so as to not disrupt existing users of the code.

<span class="mw-page-title-main">SCR-1</span>

The Stellarator of Costa Rica 1 is a small modular stellarator for the magnetic confinement of plasma located at Cartago, Costa Rica. It is developed by the plasmaTEC group of the Plasma Laboratory for Fusion Energy and Applications at Costa Rica Institute of Technology. It began operation as Latin America's first stellarator on 29 June 2016.

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.

<span class="mw-page-title-main">Richard Vuduc</span>

Richard Vuduc is a tenured professor of computer science at the Georgia Institute of Technology. His research lab, The HPC Garage, studies high-performance computing, scientific computing, parallel algorithms, modeling, and engineering. He is a member of the Association for Computing Machinery (ACM). As of 2022, Vuduc serves as Vice President of the SIAM Activity Group on Supercomputing. He has co-authored over 200 articles in peer-reviewed journals and conferences.

Static application security testing (SAST) is used to secure software by reviewing the source code of the software to identify sources of vulnerabilities. Although the process of statically analyzing the source code has existed as long as computers have existed, the technique spread to security in the late 90s and the first public discussion of SQL injection in 1998 when Web applications integrated new technologies like JavaScript and Flash.

It is a common software engineering practice to develop software by using different components. Using software components segments the complexity of larger elements into smaller pieces of code and increases flexibility by enabling easier reuse of components to address new requirements. The practice has widely expanded since the late 1990s with the popularization of open-source software (OSS) to help speed up the software development process and reduce time to market.

References

  1. Shahin, Mojtaba; Ali Babara, Muhammad; Zhu, Liming (2017). "Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices". IEEE Access. 5: 3909–3943. arXiv: 1703.07019 . Bibcode:2017arXiv170307019S. doi:10.1109/ACCESS.2017.2685629. S2CID   11638909.
  2. Holmstrom Olsson, Helena; Alahyari, Hiva; Bosch, Jan (2012). "Climbing the "Stairway to Heaven" -- A Mulitiple-Case Study Exploring Barriers in the Transition from Agile Development towards Continuous Deployment of Software". 2012 38th Euromicro Conference on Software Engineering and Advanced Applications. IEEE Computer Society. pp. 392–399. doi:10.1109/SEAA.2012.54. ISBN   978-0-7695-4790-9. S2CID   15199568.
  3. Claps, Gerry Gerard; Berntsson Svenssonb, Richard; Aurum, Aybüke (2014). "On the journey to continuous deployment: Technical and social challenges along the way". Information and Software Technology. 57: 21–31. doi:10.1016/j.infsof.2014.07.009.
  4. Shahin, Mojtaba; Babar, Muhammad Ali; Zahedi, Mansooreh; Zhu, Liming (2017). "Beyond Continuous Delivery: An Empirical Investigation of Continuous Deployment Challenges". 2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). pp. 111–120. doi:10.1109/ESEM.2017.18. ISBN   978-1-5090-4039-1. S2CID   3479812.
  5. "Continuous Deployment: An Essential Guide". IBM. 2019-10-02. Retrieved 2022-11-28. 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.
  6. Rossel, Sander (2017). Continuous Integration, Delivery, and Deployment.
  7. Vera-Rivera, F. H. (2018). "A development process of enterprise applications with microservices". Journal of Physics: Conference Series. 1126 (1): 012017. Bibcode:2018JPhCS1126a2017V. doi: 10.1088/1742-6596/1126/1/012017 . ISSN   1742-6596.
  8. Serlet, Bertrand (2019). "Data-centric Software Manifesto". Fungible. Archived from the original on 2019-10-14. Retrieved 2019-10-14.
  9. Butler, Brandon (2016-11-09). "What you should know about microservices". Computerworld. Retrieved 2019-10-14.