Preparations before Installation Procedure(4.2)

Owned by Jenni Wallin
Jun 03, 2024
3 min read

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. 

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

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

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