Continuous Delivery: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 61: Line 61:
{{Internal|GitOps#Overview| GitOps}}
{{Internal|GitOps#Overview| GitOps}}


=Canary Release=
{{Internal|Canary Release|Canary Release}}
=Delivery Repository=
=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 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]].

Revision as of 22:36, 6 April 2022

External

Internal

Continuous Delivery vs. Continuous Deployment

Continuous Delivery vs. Continuous Deployment

Overview

Continuous Delivery is an 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, 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 Pipeline

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.

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. Another is AWS CodePipeline.

Infrastructure Delivery Pipeline

Infrastructure Delivery Pipelines

Deployment Pipeline

Commit, Acceptance, UAT, Production.

Tools

GitOps

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 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

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: