Introduction

Intershop provides a GitOps approach that allows customers to easily build (CI) and deploy (CD) their products in the Azure DevOps organizations provided by Intershop. This document describes a suggested CI/CD procedure.

CI stands for Continuous Integration, which is the process of automatically building and testing code changes as they are committed to a version control repository. The goal of CI is to catch and fix bugs early in the development process.

CD stands for Continuous Deployment or Continuous Delivery, which is the process of automatically deploying/delivering code changes to an environment after they have been built and tested. The goal of CD is to reduce the time it takes to release new features and bug fixes to customers while ensuring the highest level of quality and reliability.

In the Intershop GitOps concept, the CI/CD process is automated and controlled through Git. This approach ensures that changes to the applications are tracked, auditable, and repeatable. The processes provided aim to build the product Docker images only once and then roll them out to all the necessary environments. This prevents redundant builds, saving time and resources. Customers can easily set up and run their Intershop product CI/CD pipelines using the provided Azure DevOps organizations.

This documentation first provides an overview of the general process and then explains the process in detail for each Intershop product.

References

• Flux: https://fluxcd.io/flux/

• GitHub | intershop/icm-partner-devops: devops pipeline for ICM projects

• GitHub | intershop/pwa-partner-devops: devops pipeline for PWA projects

• GitHub | intershop/iom-partner-devops: devops pipeline for IOM projects

• GitHub | intershop/cd-partner-devops: azure devops pipeline for continuous delivery

Architecture

Schematic illustration of the process recommended and provided by Intershop:

The specific steps of the process are:

1. CI Pipeline: Whenever a defined change is made to a product repository, it triggers a specific CI pipeline. The triggers for this pipeline are defined in the pipeline configuration. This configuration can be customized to execute a variety of tests and analyses to ensure that the code changes work as intended.

   The CI pipeline can perform a range of tests, including unit tests, integration tests, and acceptance tests. These tests help to ensure that the code changes are working correctly and are compatible with other components of the system. Additionally, the pipeline can perform code analysis and validation to ensure that the code adheres to best practices and standards. The goal of the CI pipeline is to build all artifacts, such as Docker images, and make them available to downstream systems.

2. Docker-Images: Upon successful execution of the CI pipeline, the generated Docker product images are pushed to a provided container registry. This ensures that the images are available for deployment and can be accessed by other components of the CI/CD process or developers.

3. Property File: In addition, the CI pipeline generates a property file that contains information about the Docker images created by the pipeline. This property file is uploaded as a pipeline artifact by the CI pipeline. The property file contains a variety of information, including the version number (tag) of the images, name of the images, and other relevant metadata about the images.

4. CD Pipeline: The CD pipeline is a separate pipeline that is triggered when a corresponding CI pipeline has completed successfully. The triggering behavior can be defined separately depending on specific requirements.

   The main purpose of the CD pipeline is to read the property file provided by the CI pipeline, evaluate it based on the product, and make the necessary changes to the deployment configuration in the environment repository.

5. Environments Repository: The Environments repository is a centralized repository that stores the manifests of Kustomization Custom Resources for all environments of all applications.

   The repository is designed to simplify the management of the deployment configurations for multiple applications and environments. It provides a single location where the deployment configurations can be stored and updated, making it easier for developers to maintain and update the configurations.

   Using this repository, developers can easily access the deployment configurations for each environment and make changes as needed. This reduces the risk of errors and inconsistencies between environments that can cause problems during production deployment.
   Schematic structure of the repository:

   ├── env1
   │   ├── product1
   │   ├── product2
   ├── env2
   │   ├── product1
   │   └── product2
   └── env3
       ├── product1
       └── product2

6. Flux Agent (managed by Intershop): The Flux Agent is responsible for detecting changes in the environment repository and deploying those changes to the corresponding environment for each product.

Product Process

In this section, the CI/CD process for the respective products is described.

CI Pipeline File

The CI process for ICM customization, PWA, and IOM includes automated builds and tests triggered by code changes in the respective repositories. Azure DevOps pipeline files are created by Intershop based on blueprint templates during the initial setup of product repositories, enabling a quick start to development.

The pipelines are defined in YAML files and adhere to a consistent structure comprising four sections:

Pipeline Triggers

This section defines the events that automatically initiate the execution of the CI pipeline and trigger a product build. The goal is to strike a balance between triggering builds frequently enough to make progress, and minimizing unnecessary builds that consume resources. Minor branch changes, such as “spike”, should ideally not trigger builds to avoid resource bottlenecks for more critical builds.

Following Intershops best practices in the blueprint templates, the initial trigger configuration includes:

trigger:
  branches:
    include:
      - master
      - develop
      - release/*
      - feature/*
      - hotfix/*
  tags:
    include:
      - version/*

The following events in the product repository automatically trigger a CI build:

This initial trigger configuration can be further customized within the project itself to suit the team-specific workflows and preferences. For a comprehensive list of available trigger types and their capabilities, refer to the Microsoft documentation: Microsoft | Build Azure Repos Git repositories - Azure Pipelines.

Non-auto-triggered builds can still be manually initiated at any time.

Pipeline Resources

Resources in YAML pipelines are references to other repositories, pipelines, builds, and more. Embedded resources can be consumed and used in all pipelines. Resources defined in the CI pipeline blueprint templates are mandatory for the build. The following section briefly explains the resources used, using the CI pipeline for ICM customization as an example:

resources:
  repositories:
    - repository: icm-partner-devops
      type: github
      endpoint: INTERSHOP_GITHUB
      name: intershop/icm-partner-devops
      ref: refs/heads/stable/v1
    - repository: ci-configuration
      type: git
      name: <projectName>-ci-configuration
      ref: master

In this example, two repositories are embedded as resources because they are required for the build.

Repository one is icm-partner-devops and embeds the GitHub repository intershop/icm-partner-devops with the ref refs/heads/stable/v1. The fact that it is a GitHub repository can be identified by the type:github. This repository resource includes the template provided and continuously developed by Intershop to build the respective product. The template for PWA can be found in the GitHub repository intershop/pwa-partner-devops and for IOM in intershop/iom-partner-devops.

The second repository ci-configuration is an ICM customization-specific repository that exists and is embedded in the same Azure DevOps project under the name <projectName>-ci-configuration.

The integration of pipeline resources can be customized or extended based on the teams workflow or usage. For comprehensive information about pipeline resources, please refer to the Microsoft documentation: Microsoft | Define YAML resources for Azure Pipelines .

Pipeline Variables

This section uses variables and secrets that are securely stored in an Azure DevOps library. These variables provide access to sensitive information or configuration settings that are essential to the build process. A key benefit of using libraries is that variable values are not hard-coded into pipelines. Instead, they are consistently referenced from the current values stored in their respective libraries. This approach allows for modifying values within the libraries without requiring any changes to the pipeline itself. Additionally, you can also define variables directly within the pipeline code. The following is a brief explanation of the variables used, using the ICM customization CI pipeline as an example:

- group: icm-build-configuration
- name:  isVersion
  value: $[startsWith(variables['Build.SourceBranch'], 'refs/tags/version')]

Library

The icm-build-configuration library and other product-specific libraries are created and maintained by Intershop. You can find these libraries in the Azure DevOps project under Pipelines | Library. For example, the BUILD_AGENT_POOL variable is defined within the icm-build-configuration library. Once a library is integrated using - group: icm-build-configuration, all variables from that library become available within the pipeline itself. For example, the BUILD_AGENT_POOL variable can then be used within the pipeline using the variable syntax $(BUILD_AGENT_POOL).

Key-Values

In addition, it is possible to define individual variables required for the pipeline directly within the pipeline itself. For this purpose, the variable's value can be either statically defined or dynamically generated using a large number of available functions. See: Microsoft | Expressions - Azure Pipelines. In this example, the isVersion variable is set to true or false depending on whether the source branch starts with refs/tags/version. the isVersion variable can then be utilized within the pipeline using the variable syntax $(isVersion).

The list of variables or embedded libraries can be customized or extended based on the team's workflow or usage. For comprehensive information about libraries, please refer to Microsoft | Library for Azure Pipelines. Additionally, a description of the variables in a pipeline can be found here: Microsoft | Define variables - Azure Pipelines.

Pipeline Job

In this section, a template maintained by Intershop is executed for each of the three products. The template orchestrates the product-specific build tasks, including the creation of the corresponding Docker images. The following templates are available:

• ICM: https://github.com/intershop/icm-partner-devops/blob/main/ci-job-template.yml

• PWA: https://github.com/intershop/pwa-partner-devops/blob/main/ci-job-template.yml

• IOM: https://github.com/intershop/iom-partner-devops/blob/main/ci-job-template.yml

The behavior of the templates can be controlled by various parameters. These parameters are described in the respective template repositories.

In the following, the use of the CI template is briefly explained using the ICM customization CI pipeline as an example:

stages:
- stage: CI
  jobs:
    - template: ci-job-template.yml@icm-partner-devops
      parameters:
        agentPool:                          $(BUILD_AGENT_POOL)
        dockerRepoICMServiceConnection:     $(INTERSHOP_REPO_SERVICE_CONNECTION)
        dockerRepoICM:                      $(INTERSHOP_REPO_PATH)
        acrServiceConnection:               $(REPO_SERVICE_CONNECTION)
        acr:                                $(REPO_PATH)
        artifactsFeed:                      $(ARTIFACT_FEED

This example runs the template ci-job-template.yml, which is included via the icm-partner-devops repository resource. In addition, various required or optional parameters are passed to the template.

The relevant variables have been imported from a library available in the project in the previous step.

CI Pipeline

The corresponding YAML file, defined as a file that describes the CI pipeline workflow, must be actively used by an Azure DevOps pipeline. All required Azure DevOps CI pipelines are created during the initial setup for all products. The following pipelines will be created:

• ICM: <PROJECT_NAME>-icm

• PWA: <PROJECT_NAME>-pwa

• IOM: <PROJECT_NAME>-iom

All pipelines available in the project can be found under Pipelines | Pipelines | All. The overview there shows all pipeline runs, their status, their trigger reason, and other meta information for these pipelines.

Example - Finding the ICM Pipeline:

Results and Artifacts

The CI pipeline delivers various results and artifacts that are crucial for further processing in the CD process and for deploying the applications to the target environments.

Docker Images

The primary task of the CI pipeline is to build Docker images. For each product, the following images are created:

• ICM: 1 image

  • ish<customer-id>acr.azurecr.io/icm-as-customization-<customer-id>-icm:<image-tag>

• PWA: 2 images

  • ish<customer-id>acr.azurecr.io/<customer-id>/<customer-id>/pwa-nginx:<image-tag>

  • ish<customer-id>acr.azurecr.io/<customer-id>/<customer-id>/pwa-ssr:<image-tag>

• IOM: 1 image

  • ish<customer-id>acr.azurecr.io/<customer-id>-iom:<image-tag>

The built images are pushed to each project's Azure Container registry, making them available to developers and the various environment instances in the cluster.

Test Results

The CI pipeline executes tests of the product and publishes the results in the Tests tab of the respective pipeline run. These results provide insight into the quality of the software and enable early defect detection and resolution.

Example - Selecting a Pipeline Run:

Example - Viewing Test Results:

Property File

In addition to the Docker images themselves, the CI pipeline also generates a file for the metadata about the images. This information includes the name and tag of the images as well as other relevant details.

The metadata is stored in a file named imageProperties.yaml and published as a pipeline artifact image_artifacts. This file is essential to the CD process because it contains information about the available images and their properties.

Example - Accessing Pipeline Artifacts:

Example - Finding the Property File

Example ICM Customization:

images:
  - type: icm-customization
    tag: 1.0.0-local-SNAPSHOT
    name: icm-as-customization-<PROJECT_NAME>-icm
    registry: <CUSTOMER-REGISTRY>
    buildWith:
      - type: buildWith
        tag: 11.0.11
        name: icm-as
        registry: intershop
      - type: buildWith
        tag: 1.0.7
        name: icm-as-customization-headless
        registry: intershop
      - type: buildWith
        tag: 4.0.10
        name: icm-as-customization-f_solrcloud
        registry: intershop

Example PWA:

images:
  - type: ssr
    tag: 329
    name: pwa-ssr
    registry: <CUSTOMER-REGISTRY>
  - type: nginx
    tag: 329
    name: pwa-nginx
    registry: <CUSTOMER-REGISTRY>

Example IOM:

images:
  - type: iom
    tag: 1.0.0-local-SNAPSHOT
    name: <IMAGE-NAME>
    registry: <CUSTOMER-REGISTRY>

Additional Information

Furthermore, the Extensions tab on the pipeline run page displays further crucial information about the pipeline itself, the created artifacts, and the tests. This information can be useful for monitoring the CI process and for troubleshooting.

Example - Accessing Pipeline Extensions tab:

CD Pipeline

The CD process is defined by respective CD pipelines, which are stored by default in the <project_name>-cd repository. The CD pipelines are triggered when the corresponding CI pipelines for each product successfully complete a build. Subsequently, the pipeline artifact image_artifacts/imageProperties.yaml of the CI pipeline is analyzed, and the necessary changes are implemented in the environment repository.

Default CD pipeline file paths and names:

Pipeline Resources

Resources in YAML pipelines are references to other repositories, pipelines, builds, and more. Embedded resources can be used and consumed throughout the pipelines. Resources defined in the CD pipeline blueprint templates are mandatory for the CD process. The following section briefly explains the resources used, using the ICM customization CD pipeline as an example:

resources:
  pipelines:
  - pipeline: <icm-ci-pipeline-name>
    source: <icm-ci-pipeline-name>
  repositories:
    - repository: environments
      type: git
      name: environments
      ref: master
    - repository: cd-partner-devops
      type: github
      endpoint: INTERSHOP_GITHUB
      name: intershop/cd-partner-devops
      ref: refs/heads/stable/v1

This example references another pipeline and two repositories as resources. The pipeline <icm-ci-pipeline-name> is the name of the CI pipeline for this product. It also includes the repository environments where the respective CD process changes should be entered. The actual job of the CD pipeline is provided as a job template by Intershop and is integrated under the name cd-partner-devops.

Pipeline Trigger

The CD pipeline is not triggered by changes to itself, but by its respective CI pipeline. By default, the CD pipeline for a product is not triggered after every successful CI build for that product. The exact timing of CD pipeline triggering is explained using the triggers defined in the ICM customization CD blueprint template.

resources:
  pipelines:
  - pipeline: <icm-ci-pipeline-name>
    source: <icm-ci-pipeline-name>
    # Trigger by branch pipeline
    trigger:
      branches:
        include:
          # Trigger by branch pipeline
          - master
          - develop
          - release/*
      # Trigger by tag pipeline
      tags:
        include:
          - version/*

Automatic Start by Successful CI Build

The CD pipeline is only triggered when there is a successful CI build for the pipeline <icm-ci-pipeline-name> for the branches master, develop, release/* or for a build for a tag starting with version/.

Manual Start

The CD pipeline will not be triggered if a different branch or an invalid tag is the basis of the CI pipeline. In addition, each pipeline can be manually triggered for specific branches or tags, even if the trigger conditions are not met. In the case of the CD pipeline, the respective CI build can be selected under Run Pipeline | Advanced options | Resources and the process can be started manually.

CD Pipeline Job Template

Intershop provides a CD job template that can be used to automate the CD process. The pipeline job template includes several tasks that read the property file of the CI build, evaluate it for the respective product, and create a pull request for the specific product and environment in the environment Repository. The behavior of the template can be customized using various parameters. An example of this job is described below:

stages:
- stage: CD_int
  jobs:
    - template: cd-job-template.yml@cd-partner-devops
      parameters:
        agentPool: $(BUILD_AGENT_POOL)
        env: int_edit
        product: icm
        environmentPath: environments
        triggerPipelineName: <icm-ci-pipeline-name>
        versionFilePath: int/icm/version-edit.yaml
        prAutoComplete: true
        useDeploymentJob: true

    - template: cd-job-template.yml@cd-partner-devops
      parameters:
        agentPool: $(BUILD_AGENT_POOL)
        env: int_live
        product: icm
        environmentPath: environments
        triggerPipelineName: <icm-ci-pipeline-name>
        versionFilePath: int/icm/version-live.yaml
        prAutoComplete: true
        useDeploymentJob: true
        dependsOn: "CD_icm_int_edit"

The CD_int stage is responsible for automating the deployment process for two environments: int_edit and int_live. It uses the cd-job-template.yml@cd-partner-devops job template provided by Intershop to analyze the property file of the respective CI pipeline and update the necessary information in the versionFilePath file in the environmentPath repository via a pull request.

Job 1: int_edit Environment Deployment

• Parameters:

  • agentPool: Specifies the agent pool to use for executing the job.

  • env: Sets the environment variable to int_edit.

  • product: Sets the product variable to icm.

  • environmentPath: Defines the name of the environment repository resources.

  • triggerPipelineName: Identifies the name of the CI pipeline that triggered the CD process.

  • versionFilePath: Specifies the path to the int/icm/version-edit.yaml file within the environment repository.

  • prAutoComplete: Enables automatic completion of pull requests.

  • useDeploymentJob: Indicates that a deployment job should be executed. The name of the Azure DevOps pipeline environment is <product>_<env> → icm_int_edit.

• Execution:

  • A pipeline job is executed, which receives the following job name: CD_<product>_<env> → CD_icm_int_edit.

  • Analyzes the property file of the CI pipeline associated with triggerPipelineName.

  • Extracts relevant information for the int_edit environment.

  • Updates the versionFilePath in the environmentPath repository with the extracted information. This creates a pull request that can be merged automatically with prAutoComplete.

  • The change to the environmentPath repository triggers a deployment for the int_edit environment.

Job 2: int_live Environment Deployment

The parameters, execution flow, and purpose of this job are the same as Job 1, except that the parameter dependsOn: CD_icm_int_edit defines that this job should only start after Job 1 has finished and only if Job 1 was successful.

Pipeline Deployment Job

In the context of Azure DevOps pipelines, deployment jobs play a critical role in automating the deployment of code changes to target environments. They provide a structured and controlled approach to delivering updated code to production or staging environments.

Key features of Azure DevOps deployment jobs, also see Microsoft | Deployment jobs - Azure Pipelines:

• Environment-Specific Configuration: Deployment jobs allow for environment-specific configurations, enabling tailored deployment strategies for different environments.

• Deployment Strategies: They support various deployment strategies, including rolling updates and blue-green deployments, providing flexibility in deployment approaches.

• Pre-Deployment and Post-Deployment Steps: Deployment jobs facilitate the execution of pre-deployment and post-deployment steps, enabling tasks such as database migrations or configuration updates.

• Deployment Tracking and Monitoring: They provide comprehensive tracking and monitoring capabilities, allowing users to visualize the deployment progress and identify potential issues.

• Approvals and checks: For each environment, specific approvals, checks, or rules can be defined that must be met before the deployment job can be started.

Integration with CD pipeline templates:

The useDeploymentJob parameter within CD pipeline templates enables the integration of deployment jobs into the overall CD workflow. By setting this parameter to true, the corresponding job is transformed into a deployment job, leveraging its features and capabilities for streamlined deployments.

The environment name is generated from the product and environment parameters using the pattern <product>_<environment> or can be explicitly defined using the deploymentEnvironment parameter. This pipeline environment must exist in the Azure DevOps project. All available pipeline environments can be found under Pipelines | Environments.

Example - Accessing project pipeline environments:

For more information on pipeline environments, refer to Microsoft | Create target environment - Azure Pipelines.

Manual Validation for ICM and IOM Production CD Processes

Manual validation for ICM and IOM CD processes is enabled by default for the production environments (starting with prd), ensuring that a human review is always required for production deployments. This behavior is controlled by the manualValidationEnabledForPrd parameter, which is set to true by default.

When a CD process is initiated for the prd (production) environment, the manual validation step is automatically triggered. This step stops the pipelines progress until the required approvals are obtained.

If the manualValidationEnabledForPrd parameter is true, the product is icm or iom, and env starts with prd, then manual validation is integrated as a pre-job. A user must then approve this manual validation.

If the manual validation is not approved or times out, then this job fails, and the subsequent CD job is not executed.

For more information on manual validation, refer to Microsoft | ManualValidation@0 - Manual validation v0 task.

CD Blueprint

Intershop provides standardized CD pipeline blueprint templates for the product ICM customization, PWA, and IOM . These templates adhere to CI/CD principles, ensuring efficient and consistent deployment processes across environments.

ICM: https://github.com/intershop/cd-partner-devops/blob/main/azure-pipelines.yml.icm.tmpl

PWA: https://github.com/intershop/cd-partner-devops/blob/main/azure-pipelines.yml.pwa.tmpl

IOM: https://github.com/intershop/cd-partner-devops/blob/main/azure-pipelines.yml.iom.tmpl

Key Features:

• Artifact Reuse: Artifacts, in the form of Docker images, are created once and reused throughout the pipeline, eliminating redundant build steps.

• Environment-Agnostic Builds: Builds are not environment-specific, ensuring consistent deployments across environments.

• Branch-Based Triggering: Pipelines are triggered for CI builds based on specific branches (master, develop, release/) and git tags starting with version/.

• Automated Deployment to int Environment: All artifacts are automatically deployed to the INT environment.

• UAT Stage for Tagged Builds: UAT (user acceptance testing) stage is executed only for CI builds with a git tag starting with version/*. This stage facilitates final testing before production deployment.

• PRD Stage for Tagged Builds and Manual Validation: PRD (productive) stage is triggered only for CI builds with a git tag starting with version/*. Manual validation is enforced for ICM and IOM products in this stage.

• PRD Environment Deployment with Version Validation: The imageTagPattern parameter ensures that only releases following semantic versioning guidelines are deployed to the PRD environment.

• Deployment Job Execution: Each job is executed as a deployment job using useDeploymentJob=true, leveraging Azure DevOps pipeline environments.

Customization:

These templates serve as a foundation and can be customized to suit specific project requirements. Modifications can be made to accommodate project-specific workflows, configurations, and integrations.

Benefits:

• Streamlined Deployments: Automated and consistent deployments across environments reduce manual effort and error-proneness.

• Reduced Deployment Risks: Artifact reuse and environment-agnostic builds minimize the risk of environment-specific issues.

• Efficient Testing: Automated deployment to int and UAT stages facilitates thorough testing before production deployment.

• Controlled PRD Releases: Manual validation and version validation safeguards PRD releases.

• Leveraging Azure DevOps Features: Deployment job execution utilizes Azure DevOps pipeline environments for enhanced deployment management.

Intershop's CD pipeline bluprint templates provide a robust and customizable template for streamlining and optimizing the deployment process for ICM customization, PWA, and IOM products. By adopting these templates, organizations can achieve efficient, reliable, and controlled deployments across development, testing, and production environments.

CI/CD Process Example

The CI/CD process is illustrated below using an example of a new commit to the develop branch for the ICM customization. This process is nearly identical for PWA and IOM.

The following section always refers to the following pipeline templates:

• ICM CI Pipeline Blueprint: https://github.com/intershop/icm-partner-devops/blob/main/azure-pipelines.yml.tmpl

• ICM CI Job Template: https://github.com/intershop/icm-partner-devops/blob/main/ci-job-template.yml

• ICM CD Pipeline Blueprint: https://github.com/intershop/cd-partner-devops/blob/main/azure-pipelines.yml.icm.tmpl

• CD Job Template: https://github.com/intershop/cd-partner-devops/blob/main/cd-job-template.yml

CI Pipeline Trigger

Pushing a commit or merging a pull request to the develop branch triggers a CI build for ICM the customization. The azure-pipelines.yml file within the product repository <PROJECT_NAME>-icm defines the develop branch as one of the branches that triggers the build.

File: azure-pipelines.yml
trigger:
  branches:
    include:
      - master
      - develop
      - release/*
  tags:
    include:
      - version/*

CI Pipeline Run

The pipeline job described in the template ci-job-template.yml@icm-partner-devops builds the ICM customization, pushes the image to the container registry, and creates the property file required for the CD process. The provided job template can be used, but it is not mandatory.

stages:
- stage: CI
  jobs:
    - template: ci-job-template.yml@icm-partner-devops
      parameters:
        agentPool:                          $(BUILD_AGENT_POOL)
        dockerRepoICMServiceConnection:     $(INTERSHOP_REPO_SERVICE_CONNECTION)
        dockerRepoICM:                      $(INTERSHOP_REPO_PATH)
        acrServiceConnection:               $(REPO_SERVICE_CONNECTION)
        acr:                                $(REPO_PATH)
        artifactsFeed:                      $(ARTIFACT_FEED)

The triggered pipeline run can be found under Pipelines | Pipelines | All | <PROJECT_NAME>-icm>.

Example - Finding Pipeline Runs:

The Pipeline Run Overview provides access to the following information:

1. Pipeline Run status: Indicates whether the pipeline run was successful, failed, or is still in progress.

2. Detailed overview of all executed tasks and their logs: Allows you to examine the individual steps involved in the pipeline run and any associated output or error messages.

3. All utilized resources: Provides insight into the resources consumed during the pipeline run, such as CPU, memory, and network bandwidth.

4. Published test results: If the pipeline includes test execution, the results of those tests are displayed here.

5. Additional information summarized and published by the CI template: This may include custom metrics, environment details, or other relevant data captured by the CI template.

6. Pipeline artifacts such as the property file: Artifacts are files or data generated during the pipeline run, and the property file might contain configuration settings or other useful information.

Example - CI Pipeline Run Overview:

Example of the property file:

images:
  - type: icm-customization
    tag: 1.0.0-local-SNAPSHOT
    name: icm-as-customization-<PROJECT_NAME>-icm
    registry: <CUSTOMER-REGISTRY>
    buildWith:
      - type: buildWith
        tag: 11.0.11
        name: icm-as
        registry: intershop
      - type: buildWith
        tag: 1.0.7
        name: icm-as-customization-headless
        registry: intershop
      - type: buildWith
        tag: 4.0.10
        name: icm-as-customization-f_solrcloud
        registry: intershop

CD Pipeline Trigger

Upon successful completion of the CI build for the develop branch, the CD pipeline <PROJECT_NAME>-icm-cd for ICM is triggered.

File: azure-pipelines-cd-icm.yml
resources:
  pipelines:
  - pipeline: <icm-ci-pipeline-name>
    source: <icm-ci-pipeline-name>
    # Trigger by branch pipeline
    trigger:
      branches:
        include:
          # Trigger by branch pipeline
          - master
          - develop
          - release/*
      # Trigger by tag pipeline
      tags:
        include:
          - version/*

CD Pipeline Run

The triggered pipeline run can be found under Pipelines | Pipelines | All | <PROJECT_NAME>-icm-cd>.

The Pipeline Run Overview provides access to the following information:

1. Pipeline run status: Indicates whether the pipeline run was successful, failed, or is still in progress.

2. Detailed overview of all executed stages, jobs, tasks and their logs: Allows you to examine the individual steps involved in the pipeline run and any associated output or error messages.

3. All utilized resources: Provides insight into the resources consumed during the pipeline run, such as CPU, memory, and network bandwidth.

4. Additional information summarized and published by the CD template: This may include custom metrics, environment details, or other relevant data captured by the CD template.

5. Pipeline artifacts such as the property file: Artifacts are files or data generated during the pipeline run, and the property file might contain configuration settings or other useful information.

Example - CD Pipeline Run Overview:

In this example, only the CD_int stage is executed because the CI pipeline source branch is develop, which does not meet the general stage condition for the CD_uat and CD_prd stages.

stages:
- stage: CD_int
  jobs:
    ....

- stage: CD_uat
  dependsOn:
    - CD_int
  condition: and(succeeded(), startsWith(variables['resources.pipeline.<icm-ci-pipeline-name>.sourceBranch'], 'refs/tags/version/'))
  jobs:
    ....
- stage: CD_prd
  dependsOn:
    - CD_uat
  condition: and(succeeded(), startsWith(variables['resources.pipeline.<icm-ci-pipeline-name>.sourceBranch'], 'refs/tags/version/'))
  jobs:
    ....

This CD pipeline evaluates the property file and creates a corresponding pull request in the environment repository for the environment and product. Whether to use AutoCompletion or to set pull request reviewers can be controlled through the respective parameters in the CD pipeline.

FAQ

How Can I Expand the CD Pipeline to Automate Other Environments?

Example scenario:

Images generated from a build on the develop branch should be deployed to the INT environment without additional confirmation. However, images associated with a tag starting with "version/" should not be automatically deployed to the UAT environment. Instead, a pull request must be created for such images, and a reviewer must approve the pull request prior to deployment.
Basically, there are the following options for extending the CD pipeline to include another environment:

Expanding the Existing Pipeline

The trigger of the respective CD pipeline needs to be adjusted to start when a successful CI build of either the develop branch or a build starting with "version/" has been completed.

...
resources:
  pipelines:
  - pipeline: <CI-PIPELINE-NAME>
    source: <CI-PIPELINE-NAME>
    trigger:
      branches:
        include:
        # Trigger by branch pipeline
        - develop
        # Trigger by tag pipeline
        - refs/tags/version/*  
...

Images built from the develop branch and ending with SNAPSHOT (imageTagPattern: '-SNAPSHOT$') will be deployed to the INT environment. Additionally, the prAutoComplete parameter will be set to True, enabling the changes to be rolled out without further confirmation.

On the other hand, images will only be deployed to the UAT environment if the image tag ends with a number according to semantic versioning (imageTagPattern: '^[0-9]+\.[0-9]+\.[0-9]+$'). The pull request prAutoComplete feature is not enabled, and a pull request reviewer will be assigned.

...
stages:
- stage: CD_int
  jobs:
    - template: cd-job-template.yml@cd-partner-devops
      parameters:
        agentPool: $(BUILD_AGENT_POOL)
        product: icm
        env: int
        environmentPath: environments
        triggerPipelineName: <CI-PIPELINE-NAME>
        versionFilePath: int/icm/version.yaml
        prAutoComplete: true
        imageTagPattern: '-SNAPSHOT$'

- stage: CD_uat
  jobs:
    - template: cd-job-template.yml@cd-partner-devops
      parameters:
        agentPool: $(BUILD_AGENT_POOL)
        product: icm
        env: uat
        environmentPath: environments
        triggerPipelineName: <CI-PIPELINE-NAME>
        versionFilePath: uat/icm/version.yaml
        prAutoComplete: false
        prReviewers: user@mail.com
        imageTagPattern: '^[0-9]+\.[0-9]+\.[0-9]+$'
...

Furthermore, additional parameter functions can be used to deploy the respective image in the correct environment.

Creating an Additional Pipeline

If the scenario cannot be represented within a single pipeline, additional pipelines can be created in the <PROJECT_NAME>-cd repository.

For each separately created pipeline file, a corresponding pipeline must be set up in the Azure DevOps project.

Example:

Where Can I Find the Project CI Pipeline Property File?

The property file can be found in the published artifacts of the respective pipeline runs:

How to Customize an Azure DevOps Pipeline?

Microsoft provides comprehensive documentation on the workflows, functionalities, and configurations of a pipeline: Microsoft | Azure Pipelines documentation.