Continuous Integration and Deployment(4.1)

Owned by Jenni Wallin
Mar 06, 2024
3 min read

The  Continuous Integration and Deployment (CI/CD) pipeline automates the building, testing, and deployment of use- and test cases. 

 is designed to provide API driven operations to enable fully automated CI/CD pipelines.

In , so called Workflow Packages are used to facilitate the transportation of data between different environments, such as development, test, and production environments.

It is possible to run multiple versions of a workflow in parallel using Workflow Packages in the same system or in independent systems.

Using tools for traffic management there are also solid processes for doing “Blue/Green” or “Canary” deployments to achieve zero-downtime upgrades. See Upgrade Strategy for more information.

CI/CD pipeline steps

The picture below shows an example of the steps involved in a CI/CD pipeline. The third party products Git, Jenkins, and Artifactory are just examples.

The example is based on the assumption that the finished deliverable contains everything, including images. Furthermore, it does not require internet access from the target environment, for example the pre-production or production environment.

Example of a CI/CD pipeline

  1. Development environment: Code is changed and workflows are built in a  development environment, where environment specific data such as EC Deployments, scheduling rules, and global parameters are also handled. When suitable, the developer exports the configured workflows to a central version control system, such as Git. The version control system is where test cases, configurations, workflows, and test data are stored. The export format is based on JSON and is structured in a way that makes it easy to track changes between versions. 

  2. Build and Test Server: Once workflows are ready, they are moved into a staging or integration environment. Here, workflows and other parts of the solution are compiled into packages and possibly assembled with pieces from other development environments. Automated test suites are automatically applied to the packages in this environment. When all tests are passed, an orchestrator (for example Jenkins) orders , which acts as a build server, to create Workflow Packages (binaries). In our example, the package is created in the form of an archive zip-file including all needed components, such as Docker images and Helm charts. Workflow Packages can also be built manually directly from any  system. See Workflow Packages for more information.

  3. Docker image and Helm chart: At this point, the Workflow Package can be promoted to the next step. The Docker image contains all relevant information required for running in, for example, a pre-production environment. The Helm chart, located in a Helm repository, points out the Docker image, the Workflow Package version, and workflows.

  4. (Pre-)Production environment: The Helm chart pointing out the Docker image is deployed in a target environment, for example the pre-production environment. When suitable, the exact same procedure can be applied to a production environment. The configuration and workflows look exactly like in a development environment but are read only.

Use the  Desktop client to select workflows and configurations to be packaged into Workflow Packages, tested, and later deployed in production. 

For information on how to install the example pipeline, see Install the Example CI/CD Pipeline.

This section contains the following sub-sections: