Continuous Delivery: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(19 intermediate revisions by the same user not shown)
Line 9: Line 9:


=Overview=
=Overview=
'''Continuous Delivery''' is an [[Agile Software Development#CD|agile software development]] practice that encourages building software in such a way that it can be released in production at any time. Because of the safety mesh provided by CD, the  system is released in production often. Before releasing in production, the system is deployed in an environment similar to production and tested there. As such, Continuous Delivery extends the unit testing performed by [[Continuous_Integration#Overview|Continuous Integration]], ensuring full production readiness through integration testing. The essence of CD is to maximize the scope of testing initiated by CI, by exercising the entire system in its natural habitat. If properly conducted, an integration defect is caught immediately, instead of waiting for it to materialize later in production. Only the code that deploys and runs correctly in one or more test environments is promoted to production.
'''Continuous delivery''' is [[Software_Development#Software_Development_Practices|software development]] practice, in general, and an [[Agile Software Development#CD|agile software development]] practice, in particular, which encourages building software in such a way that it can be released in production at any time. Because of the safety mesh provided by CD, the  system is released in production often. Before releasing in production, the system is deployed in an environment similar to production and tested there. As such, Continuous Delivery extends the unit testing performed by [[Continuous_Integration#Overview|Continuous Integration]], ensuring full production readiness through integration testing. The essence of CD is to maximize the scope of testing initiated by CI, by exercising the entire system in its natural habitat. If properly conducted, an integration defect is caught immediately, instead of waiting for it to materialize later in production. Only the code that deploys and runs correctly in one or more test environments is promoted to production.


CD pipelines deploy the artifacts produced by the CI pipelines. Continuous Delivery is some times referred to as '''Continuous Deployment'''.
CD pipelines deploy the artifacts produced by the CI pipelines. Continuous Delivery is some times referred to as '''Continuous Deployment'''.
Line 25: Line 25:


Amazon take on Continuous Delivery: https://aws.amazon.com/devops/continuous-delivery/
Amazon take on Continuous Delivery: https://aws.amazon.com/devops/continuous-delivery/
=Continuous Delivery vs. Continuous Deployment=
=Continuous Delivery vs. Continuous Deployment=
Within the context of these articles, '''continuous deployment''' covers that part of the software delivery process that concerns itself with placing - deploying - artifacts and configuration into a target environment. The artifacts are products of a [[Continuous Integration|continuous integration]] process. Since the artifacts are continuously built and published as part of that process, it is natural to think that the deployment should also be a continuous process. However, not every deployment is a production deployment. A specific feature can be continuously deployed to a Stage environment while it is being worked on and tested in conditions similar to production, and thus iteratively refined, without being released to users. Multiple continuous integration and continuous deployment cycles are exercised as part of such an iterative deployment process, but the change may end not being delivered to production users.
Within the context of these articles, '''continuous deployment''' covers the part of the software delivery process that consists of placing - deploying - artifacts and configuration into a target environment, possibly production, every time there is an artifact or a configuration change, or at any moment an operator may choose so. The artifacts are the products of a [[Continuous Integration|continuous integration]] process. Since the artifacts are continuously built and published as result of upstream changes, automated deployments are triggered as result, by default. However, not every deployment is a production deployment, and the system must allow for selectivity and flexibility in deciding where and how these artifacts are deployed. A specific feature may be continuously deployed to a Stage environment while it is being worked on and tested in conditions similar to production, and thus iteratively refined, without actually being released to production users. Multiple continuous integration and continuous deployment cycles can be exercised as part of such an iterative deployment process, but the change may end not being delivered to production users. The system must allow flexibility and manual intervention for this kind of decisions.


'''Continuous delivery''' is a more generic concept. Aside from its intrinsic technical implications, it also has business implications. Continuous delivery is about propagating a business-level change all the way to production and in the hands of users. Such change translates internally in changes of code, data structures, configuration, etc. and those changes trigger continuous integration and continuous deployment cycles. Continuous delivery requires the capability to do continuous integration and deployment. Implementing continuous delivery means making sure that software is always production ready throughout its entire lifecycle and any build could potentially be released to production users at the touch of a button and using a fully automated process in a matter of seconds or minutes. This in turn relies on comprehensive automation of the build, test suite and deployment infrastructure. In the world of continuous delivery, a developer is only done when the feature is working in production and produces value for users.
'''Continuous delivery''' is a more generic concept. Aside from its intrinsic technical implications, it also has business implications. Continuous delivery is about propagating a business-level change all the way to production and in the hands of users. Such change translates internally in changes of code, data structures, configuration, etc. and those changes trigger continuous integration and continuous deployment cycles. Continuous delivery requires the capability to do continuous integration and deployment. Implementing continuous delivery means making sure that software is always production ready throughout its entire lifecycle and any build could potentially be released to production users at the touch of a button and using a fully automated process in a matter of seconds or minutes. This in turn relies on comprehensive automation of the build, test suite and deployment infrastructure. In the world of continuous delivery, a developer is only done when the feature is working in production and produces value for users.
Line 34: Line 35:
* http://timothyfitz.com/2009/02/08/continuous-deployment/
* http://timothyfitz.com/2009/02/08/continuous-deployment/


=Continuous Delivery Pipeline=
=Continuous Integration=
{{Internal|Continuous Integration#Overview|Continuous Integration}}
=Delivery Repository=
A delivery repository exposes packaged artifacts or code for use with the infrastructure tools that create infrastructure in the target environment or that deploy the applications in the application runtime. The delivery repository usually stores multiple version of a given project's code. The delivery repositories could be general purpose storage solutions such as file servers, S3 buckets, tool-specific repositories, such as [[Terraform_Concepts#Terraform_Registry|Terraform Registry]] or specialized artifact repositories like [[Nexus]] and [[Artifactory]] or [[ORAS]].


A '''continuous delivery pipeline''' is the automated expression of the process for getting software from version control through building, testing and deployment to the end users, in production.
Especially for infrastructure, given that the infrastructure code is already stored in the source repository, and many infrastructure code tools don't have a package format and a toolchain for threading their code as a release, many teams apply code to environments directly from the source repository. See: {{Internal|GitOps#Overview|GitOps}}
 
Every change to the software being built, committed in source control, goest through a complex process on its way of being released. This process involves building the software in a reliable and repeatable manner, as well as progressing the built software (called the "build") through multiple stages of testing and deployment.
 
One tool that provides continuous delivery pipeline functionality is [[Jenkins_Concepts#Pipeline|Jenkins]]. Another is [[AWS_CodePipeline_Concepts#Pipeline|AWS CodePipeline]].
==<span id='Continuous_Delivery_for_Infrastructure_Code'></span>Infrastructure Delivery Pipeline==
{{Internal|Infrastructure_Code_Continuous_Delivery_Concepts#Infrastructure_Delivery_Pipeline|Infrastructure Delivery Pipelines}}


=Deployment Pipeline=
=Continuous Deployment=
{{Internal|Continuous Deployment#Overview|Continuous Deployment}}


Commit, Acceptance, UAT, Production.
=<span id='CD_Tools'></span>Tools=
=<span id='CD_Tools'></span>Tools=
* [[Jenkins_Concepts#Overview|Jenkins]]
* [[Jenkins_Concepts#Overview|Jenkins]]
* [[Tekton_Concepts#Overview|Tekton]]
* [[Spinnaker]]
* [[Spinnaker]]
* [[GoCD_Concepts#Overview|GoCD]]
* [[GoCD_Concepts#Overview|GoCD]]
Line 66: Line 65:
{{Internal|GitOps#Overview| GitOps}}
{{Internal|GitOps#Overview| GitOps}}


=Delivery Repository=
A delivery repository exposes packaged artifacts or code for use with the infrastructure tools that create infrastructure in the target environment or that deploy the applications in the application runtime. The delivery repository usually stores multiple version of a given project's code. The delivery repositories could be general purpose storage solutions such as file servers, S3 buckets, tool-specific repositories, such as [[Terraform_Concepts#Terraform_Registry|Terraform Registry]] or specialized artifact repositories like [[Nexus]] and [[Artifactory]] or [[ORAS]].
Especially for infrastructure, given that the infrastructure code is already stored in the source repository, and many infrastructure code tools don't have a package format and a toolchain for threading their code as a release, many teams apply code to environments directly from the source repository. See: {{Internal|GitOps#Overview|GitOps}}
=Fan-in Pipeline Design=
=Fan-in Pipeline Design=
<font color=darkkhaki>
<font color=darkkhaki>

Latest revision as of 02:52, 1 July 2023

External

Internal

Overview

Continuous delivery is software development practice, in general, and an agile software development practice, in particular, which encourages building software in such a way that it can be released in production at any time. Because of the safety mesh provided by CD, the system is released in production often. Before releasing in production, the system is deployed in an environment similar to production and tested there. As such, Continuous Delivery extends the unit testing performed by Continuous Integration, ensuring full production readiness through integration testing. The essence of CD is to maximize the scope of testing initiated by CI, by exercising the entire system in its natural habitat. If properly conducted, an integration defect is caught immediately, instead of waiting for it to materialize later in production. Only the code that deploys and runs correctly in one or more test environments is promoted to production.

CD pipelines deploy the artifacts produced by the CI pipelines. Continuous Delivery is some times referred to as Continuous Deployment.

CD best practices:

  • version code and configuration
  • version environment
  • build binaries once
  • automate everthing
  • smoke test deployments
  • deploy to all environments the same way
  • create disposable environments

A core principle of CD is to never change the code after the build stage.

Amazon take on Continuous Delivery: https://aws.amazon.com/devops/continuous-delivery/

Continuous Delivery vs. Continuous Deployment

Within the context of these articles, continuous deployment covers the part of the software delivery process that consists of placing - deploying - artifacts and configuration into a target environment, possibly production, every time there is an artifact or a configuration change, or at any moment an operator may choose so. The artifacts are the products of a continuous integration process. Since the artifacts are continuously built and published as result of upstream changes, automated deployments are triggered as result, by default. However, not every deployment is a production deployment, and the system must allow for selectivity and flexibility in deciding where and how these artifacts are deployed. A specific feature may be continuously deployed to a Stage environment while it is being worked on and tested in conditions similar to production, and thus iteratively refined, without actually being released to production users. Multiple continuous integration and continuous deployment cycles can be exercised as part of such an iterative deployment process, but the change may end not being delivered to production users. The system must allow flexibility and manual intervention for this kind of decisions.

Continuous delivery is a more generic concept. Aside from its intrinsic technical implications, it also has business implications. Continuous delivery is about propagating a business-level change all the way to production and in the hands of users. Such change translates internally in changes of code, data structures, configuration, etc. and those changes trigger continuous integration and continuous deployment cycles. Continuous delivery requires the capability to do continuous integration and deployment. Implementing continuous delivery means making sure that software is always production ready throughout its entire lifecycle and any build could potentially be released to production users at the touch of a button and using a fully automated process in a matter of seconds or minutes. This in turn relies on comprehensive automation of the build, test suite and deployment infrastructure. In the world of continuous delivery, a developer is only done when the feature is working in production and produces value for users.

More thoughts on this subject:

Continuous Integration

Continuous Integration

Delivery Repository

A delivery repository exposes packaged artifacts or code for use with the infrastructure tools that create infrastructure in the target environment or that deploy the applications in the application runtime. The delivery repository usually stores multiple version of a given project's code. The delivery repositories could be general purpose storage solutions such as file servers, S3 buckets, tool-specific repositories, such as Terraform Registry or specialized artifact repositories like Nexus and Artifactory or ORAS.

Especially for infrastructure, given that the infrastructure code is already stored in the source repository, and many infrastructure code tools don't have a package format and a toolchain for threading their code as a release, many teams apply code to environments directly from the source repository. See:

GitOps

Continuous Deployment

Continuous Deployment

Tools

GitOps

GitOps

Fan-in Pipeline Design

TO PROCESS: Modeling Deployment Pipelines: Build Propagation using Fan-in/Fan-out https://www.gocd.org/2017/04/17/build-propagation-using-fan-in-fan-out.html

Used in Delivery-time integration.

Organizatorium

TO PROCESS:

Retrieved from "https://kb.novaordis.com/index.php?title=Continuous_Delivery&oldid=97120"