Infrastructure Code Continuous Delivery Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(46 intermediate revisions by the same user not shown)
Line 3: Line 3:
* [[Continuous_Delivery#Continuous_Delivery_for_Infrastructure_Code|Continuous Delivery]]
* [[Continuous_Delivery#Continuous_Delivery_for_Infrastructure_Code|Continuous Delivery]]
* [[Infrastructure_as_Code_Concepts#Infrastructure_Code_Continuous_Delivery|Infrastructure as Code Concepts]]
* [[Infrastructure_as_Code_Concepts#Infrastructure_Code_Continuous_Delivery|Infrastructure as Code Concepts]]
* [[Infrastructure_Code_Testing_Concepts#Overview|Infrastructure Code Testing]]
=Overview=
=Overview=
=<span id='Infrastructure Delivery Pipelines'></span>Infrastructure Delivery Pipeline=
The [[#Pipeline|delivery pipeline]] metaphor describes how a change in the infrastructure code progresses from the person that makes the change all the way to production.
 
<font color=darkkhaki>Reconcile with [[Continuous_Delivery#Overview|Continuous Delivery]]</font>.
<font color=darkkhaki>
<font color=darkkhaki>
TO CONTINUE: [[IaC]] Chapter 8 Core Practice: Continuously Test and Deliver → Infrastructure Delivery Pipelines.
TO CONTINUE: [[IaC]] Chapter 8 Core Practice: Continuously Test and Deliver → Infrastructure Delivery Pipelines.
Line 11: Line 15:
* [[Infrastructure_as_Code_Concepts#Pipeline_Stack_Parameters|Pipeline Stack Parameters]]
* [[Infrastructure_as_Code_Concepts#Pipeline_Stack_Parameters|Pipeline Stack Parameters]]
</font>
</font>
=<span id='Pipeline'></span><span id='Infrastructure_Delivery_Pipelines'></span>Infrastructure Delivery Pipeline=
A infrastructure delivery pipeline consists in multiple types of [[#Activity|activities]], grouped in [[#Stage|stages]]:
[[File:Infrastructure_Delivery_Pipeline.png|926px]]
==<span id='Activity'></span>Activities==
===Build===
The build stage compiles application code and makes the code available for use for other stages. Building is done once in a pipeline, every time the source code changes. A core principle of [[Continuous_Delivery#Overview|CD]] is never changing code after the build stage. Building implies the following steps:
* Retrieving build-time dependencies, such as libraries, including those from other projects in the code base and external libraries.
* Resolving build-time configuration (pulling in configuration files that are shared across multiple projects)
* Compiling or transforming the code, such as generating configuration files from templates.
* Publish [[#Artifact|infrastructure artifacts]] in a [[Continuous_Delivery#Delivery_Repository|delivery repository]].
Conceptually the build stage separates two repository types - the infrastructure code source repository and the delivery repository, which could contain  [[#Infrastructure_Artifacts|packaged artifacts]] or [[#Using_a_Repository_to_Deliver_Infrastructure_Code|raw source code]].
====Offline and Mock Tests as part of the Build Step====
[[Infrastructure_Code_Testing_Concepts#Offline_Stack_Tests|Offline stack tests]] and [[Infrastructure_Code_Testing_Concepts#Testing_with_Mock_APIs_and_Doubles|tests with mock API and doubles]] do not require provisioning infrastructure so they can be run at build stage.
====<span id='Artifact'></span>Infrastructure Artifacts====
Infrastructure code can be assembled into an artifact, which is a package file with a specific format (Python package, RPM, etc.) Not many infrastructure tools have a package format for their code projects. A generic format as ZIP or TAR.GZ could be used, or even Docker images that include stack project code along with the stack tool executable.
====Using a Repository to Deliver Infrastructure Code====
As an alternative to publishing packaged artifacts, the infrastructure code can be exposed to the next stage of the delivery pipeline directly from the source repository. The code could be stage in a separated delivery source repository.
===Promote===
Promotion means moving code between delivery [[#Stage|stages]]. Tags or labels could be used with the artifacts to indicated they have been promoted across stages.
===Apply===
An apply activity pulls the infrastructure code or packaged artifacts from a [[Continuous_Delivery#Delivery_Repository|delivery repository]] and applies it to a particular environment, creating infrastructure resources. The infrastructure resources are created in different environments, corresponding to the pipeline stage the activity belongs to: stage testing, integration, production.
===Validate===
==<span id='Stage'></span>Stages==
===Online Stack Testing Stage===
===System Integration Testing Stage===
===Production Stage===
=Tools=
* [[Atlantis#Overview|Atlantis]]
* [[Terraform Cloud#Overview|Terraform Cloud]]
* [[WeaveWorks#Overview|WeaveWorks]]

Latest revision as of 02:05, 23 January 2022

External

Internal

Overview

The delivery pipeline metaphor describes how a change in the infrastructure code progresses from the person that makes the change all the way to production.

Reconcile with Continuous Delivery. TO CONTINUE: IaC Chapter 8 Core Practice: Continuously Test and Deliver → Infrastructure Delivery Pipelines.

TO INTEGRATE:

Infrastructure Delivery Pipeline

A infrastructure delivery pipeline consists in multiple types of activities, grouped in stages: Infrastructure Delivery Pipeline.png

Activities

Build

The build stage compiles application code and makes the code available for use for other stages. Building is done once in a pipeline, every time the source code changes. A core principle of CD is never changing code after the build stage. Building implies the following steps:

  • Retrieving build-time dependencies, such as libraries, including those from other projects in the code base and external libraries.
  • Resolving build-time configuration (pulling in configuration files that are shared across multiple projects)
  • Compiling or transforming the code, such as generating configuration files from templates.
  • Publish infrastructure artifacts in a delivery repository.

Conceptually the build stage separates two repository types - the infrastructure code source repository and the delivery repository, which could contain packaged artifacts or raw source code.

Offline and Mock Tests as part of the Build Step

Offline stack tests and tests with mock API and doubles do not require provisioning infrastructure so they can be run at build stage.

Infrastructure Artifacts

Infrastructure code can be assembled into an artifact, which is a package file with a specific format (Python package, RPM, etc.) Not many infrastructure tools have a package format for their code projects. A generic format as ZIP or TAR.GZ could be used, or even Docker images that include stack project code along with the stack tool executable.

Using a Repository to Deliver Infrastructure Code

As an alternative to publishing packaged artifacts, the infrastructure code can be exposed to the next stage of the delivery pipeline directly from the source repository. The code could be stage in a separated delivery source repository.

Promote

Promotion means moving code between delivery stages. Tags or labels could be used with the artifacts to indicated they have been promoted across stages.

Apply

An apply activity pulls the infrastructure code or packaged artifacts from a delivery repository and applies it to a particular environment, creating infrastructure resources. The infrastructure resources are created in different environments, corresponding to the pipeline stage the activity belongs to: stage testing, integration, production.

Validate

Stages

Online Stack Testing Stage

System Integration Testing Stage

Production Stage

Tools