The preparations described below are required to install the example CI/CD pipeline. The installation tar contains Readme files that explain the various parts of the installation. Important information:

The Helm chart installs the base product and is used in all environments - build, test, and production.
The ECD Helm charts install services/solutions and are used in system test and production environments.
The Script folder contains all the scripts needed to run the pipeline.
The Test folder contains unit tests to verify business logic.

Prerequisites

There are the prerequisites for installing the example pipeline:

Knowledge of Git and Jenkins.
For the Canary upgrade, the example pipeline uses Istio to handle the traffic between the deployments. See Istio website.
Pipeline plugins must be installed, supporting Stages and Steps (see table below).
Kubectl, Helm, and Docker must be installed on Jenkins Node.
Jenkins Node must have contact to a Kubernetes cluster or have Minikube as its current context.
Internet access.

The example of a CI pipeline contains the following main stages. Typically, customizations are needed for all stages.

Stage	Description
Build DTK Image	If there are any DTK MZPs:s in the Dtk directory a docker image will be built with all the DTK MZPs in that folder. This image is then used in the Deploy step and in CD Pipeline. The image is built using the docker build command with the docker file from the Scripts folder. Example Run the following command to create a DTK docker image: ./Scripts/pipeline.sh build-dtk-img
Deploy	In this stage, the helm chart from the directory Helm is installed in the cluster used by Jenkins. Example Run the following bash script to install helm: ./Scripts/pipeline.sh install
Wait for pods	The pipeline hangs on this stage until the cluster is started successfully. Example Run this command to wait until the desired number of the pods is running: ./Scripts/pipeline.sh wait_for_pods
Import configuration	The use case configuration is imported and a verification of a successful import is done. It is done using the `systemimport(3.0)` command. Example Run the following command to do an import of the use case configuration: ./Scripts/pipeline.sh import
Test	After the successful import, the test configuration is imported, the test ecd is installed in the cluster (using the Helm chart in the Test directory), and the test data from the directory testdata is copied to the EC and platform. To execute the test, run the python script in the testdata directory, `test_executor.py`, After all tests are executed, the test result is exported from the EC. Example Run the following command to execute the test result: ./Scripts/pipeline.sh test
Build packages	After the test result is exported, a Workflow package is built in a two-step process: Self-contained Workflow Package is built using the mzcli command `packageexport(3.0)` with the `packages.xml` from the Configuration folder. Example Run the following command to build the Workflow Package: ./Scripts/pipeline.sh build Then an package image containing the packages and external files is built using the docker `build` command with the docker file from the Scripts folder. Example Run the following command to build the package image: ./Scripts/pipeline.sh build-pkg-img
Create archive	After the packages are built, you need to create an archive. To create a CSAR, extract all images using docker `save` command. A zip `csar` archive is created containing images, Helm charts, install script and external files. Example Run the following command to create an archive: ./Scripts/pipeline.sh archive

The structure in Git

The structure in Git contains all information needed to test a configuration, build the configuration packages, and create PODs for production. A map file describes the mapping of configurations to packages. A package can contain several configurations.

Git structure

Usage Engine Private Edition 3 Documentation

Preparations before Installation Procedure(3.0)

Analytics

Prerequisites

The structure in Git

Related content