- Sitemap
Introduction
Intershop provides a GitOps concept that allows customers to easily build (CI) and deploy (CD) their products in the Azure DevOps organizations provided by Intershop. A suggested CI/CD procedure is described in this document.
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 errors 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 shorten 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. Customers can leverage the provided Azure DevOps organizations to easily configure and run their own CI/CD pipelines process for their Intershop products.
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/
Architecture
Schematic illustration of the process:
Process
The specific steps of the process are:
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 are functioning 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.
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.
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.
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.
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.
By 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 across environments, which can lead to problems during deployment on production.
Schematic structure of the repository:├── env1 │ ├── product1 │ ├── product2 ├── env2 │ ├── product1 │ └── product2 └── env3 ├── product1 └── product2Flux Agent: The Flux agent is responsible for detecting changes in the environment repository and deploying those changes to the corresponding environment for each product.
The CD pipeline should be designed to automate the entire release process, from code changes to deployment, in order to reduce the chance of human error and to ensure consistent results.
Product Process
In this section, the CI/CD process for the respective products is described.
ICM Customization
CI
The default repository for Intershop Commerce Management customization is <PROJECT_NAME>-icm, which includes a file named azure-pipelines.yml. This file serves as a reference for the <PROJECT_NAME>-icm pipeline and represents the CI process for the ICM customization.
Example of a pipeline provided by Intershop as a standard offering:
All possible parameters for controlling the behavior of the ICM CI job can be found here: https://github.com/intershop/icm-partner-devops.
# Triggers in a pipeline are used to start the pipeline when certain conditions are met.
# These conditions can be customized based on the specific needs of the project.
# See: https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/azure-repos-git?view=azure-devops&tabs=yaml#ci-triggers
trigger:
branches:
include:
- master
tags:
include:
- version/*
# The CI pipeline for an ICM customization requires two resources:
# - icm-partner-devops repository, which is a job template provided by Intershop that reflects the standard build process for an ICM customization.
# See: https://github.com/intershop/icm-partner-devops
# - ci-configuration repository, which is a project-specific repository that provides configuration files for the ICM customization.
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: <PROJECT_NAME>-ci-configuration
ref: master
# Variables are defined globally in the pipeline or in a library or are set at the start of the pipeline.
variables:
# Library icm11-build-configuration is provided by Intershops DevOps Environment. It provides
# the following variables:
# - BUILD_AGENT_POOL: name of the build agent pool
# - REPO_SERVICE_CONNECTION: service connection to the customer ACR
# - REPO_PATH: host name and path of the customer ACR
# - INTERSHOP_REPO_SERVICE_CONNECTION: service connection to the Intershop container registry
# - INTERSHOP_REPO_PATH: host name and path of the Intershop container registry
# - ARTIFACT_FEED name of the icm artifacts feed
- group: icm11-build-configuration
- name: isVersion
value: $[startsWith(variables['Build.SourceBranch'], 'refs/tags/version')]
# Pipeline workflow:
# This workflow can be extended or modified as needed.
stages:
- stage: CI
jobs:
# In order to customize the build process of an ICM customization, the job template provided by Intershop can be called with specific parameters.
# These parameters can modify the behavior of the pipeline and adapt it to the specific needs of the customization.
# See: https://github.com/intershop/icm-partner-devops
# The defined job builds the ICM customization, pushes the image to the container registry, and creates the property file.
- 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 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.
The default name of this pipeline is <PROJECT_NAME>-icm:
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
By default, there is a <PROJECT_NAME>-cd repository, where the CD pipeline for the ICM customization is located (default name: azure-pipelines-cd-icm.yml). This CD pipeline reacts to specific successful builds of the ICM customization's CI pipeline. The goal of this CD pipeline is to push the necessary changes to the environment configuration of the ICM customization in the environment repository.
All possible parameters for controlling the behavior of the CD job can be found here: https://github.com/intershop/cd-partner-devops.
trigger: none
name: $(Date:yyyyMMdd)$(Rev:.r)
appendCommitMessageToRunName: false
resources:
# The CD pipeline for an ICM customization requires one pipeline resource:
# This CD pipeline is triggered when a specific build of a CI pipeline is successful.
pipelines:
- pipeline: <PROJECT_NAME>-icm
source: <PROJECT_NAME>-icm
trigger:
branches:
include:
# Trigger by branch pipeline
- master
# The CD pipeline for an ICM customization requires two repository resources:
# - cd-partner-devops repository, which is a job template provided by Intershop that reflects the standard CD process for all Intershop products.
# See: https://github.com/intershop/cd-partner-devops
# - environments repository is a centralized repository that stores the manifests of Kustomization Custom Resources for all environments of all applications.
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
variables:
# Library icm11-build-configuration is provided by Intershops DevOps Environment. It provides
# the following variables:
# - BUILD_AGENT_POOL: name of the build agent pool
# - REPO_SERVICE_CONNECTION: service connection to the customer ACR
# - REPO_PATH: host name and path of the customer ACR
# - INTERSHOP_REPO_SERVICE_CONNECTION: service connection to the Intershop container registry
# - INTERSHOP_REPO_PATH: host name and path of the Intershop container registry
# - ARTIFACT_FEED name of the icm artifacts feed
- group: icm11-build-configuration
#
# The CD process can be very individual.
# The template has numerous parameters to configure the behavior separately for each environment.
#
#
# In the following example, each change is incorporated into the Int environment without any restrictions.
#
stages:
- stage: CD_int
jobs:
# The Pipeline Job Template includes several tasks that read the property file, evaluate it for the respective product, and create a pull request for the specific product and environment in the Environment Repository.
# The behavior can be controlled using parameters.
- template: cd-job-template.yml@cd-partner-devops
parameters:
agentPool: $(BUILD_AGENT_POOL)
product: icm
env: int
environmentPath: environments
triggerPipelineName: <PROJECT_NAME>-icm
versionFilePath: int/icm/version.yaml
prAutoComplete: true
The default name of this pipeline is <PROJECT_NAME>-icm-cd:
Exemplary process:
A developer commits a change to the master branch of the ICM customization repository. On the commit overview page, completed and current pipeline runs are also displayed.
As the master branch is a trigger for the corresponding CI pipeline, the CI pipeline is started for this commit.
The CI pipeline builds the ICM customization image and pushes it to the container registry.
Additionally, a property file is created and published as a pipeline artifact.
The corresponding CD pipeline is started as the master branch CI build is a trigger for it.
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.
PWA
CI
The default repository for Intershop Progressive Web App is <PROJECT_NAME>-pwa, which includes a file named .azure/azure-pipelines.yml. This file serves as a reference for the <PROJECT_NAME>-pwa pipeline and represents the CI process for the PWA.
Example of a pipeline provided by Intershop as a standard offering:
All possible parameters for controlling the behavior of the PWA CI job can be found here: https://github.com/intershop/pwa-partner-devops.
# Triggers in a pipeline are used to start the pipeline when certain conditions are met.
# These conditions can be customized based on the specific needs of the project.
# See: https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/azure-repos-git?view=azure-devops&tabs=yaml#ci-triggers
trigger:
branches:
include:
- master
tags:
include:
- version/*
# The CI pipeline for PWA requires one resource:
# - pwa-partner-devops repository, which is a job template provided by Intershop that reflects the standard build process for a PWA project.
# See: https://github.com/intershop/pwa-partner-devops
# Create a repository resource to the Github repo, that is providing the centrally managed CI job
resources:
repositories:
- repository: pwa-partner-devops
type: github
endpoint: INTERSHOP_GITHUB
name: intershop/pwa-partner-devops
ref: refs/heads/stable/v1
variables:
# Library pwa-build-configuration is provided by Intershop’s DevOps Environment. It provides
# the following variables:
# - BUILD_AGENT_POOL: name of the build agent pool
# - REPO_SERVICE_CONNECTION: service connection to the customer ACR
# - REPO_PATH: host name and path of the customer ACR
- group: pwa-build-configuration
# Pipeline workflow:
# This workflow can be extended or modified as needed.
stages:
- stage: CI
jobs:
# Run the CI job using the specified template, which receives input parameters based on the pwa-build-configuration library.
# Additional custom stages/jobs may be added.
- template: ci-job-template.yml@pwa-partner-devops
parameters:
# These parameters must not be changed. They are used to pass variables to the ci-job templaten, which
# are defined by library pwa-build-configuration.
agentPool: $(BUILD_AGENT_POOL)
registryServiceConnection: $(REPO_SERVICE_CONNECTION)
registry: $(REPO_PATH)
The pipeline job described in the template ci-job-template.yml@pwa-partner-devops builds the PWA, pushes the images 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.
The default name of this pipeline is <PROJECT_NAME>-pwa:
Example of the property file:
images:
- type: ssr
tag: 329
name: pwa-ssr
registry: <CUSTOMER-REGISTRY>
- type: nginx
tag: 329
name: pwa-nginx
registry: <CUSTOMER-REGISTRY>
CD
By default, there is a <PROJECT_NAME>-cd repository, where the CD pipeline for the PWA is located (default name: azure-pipelines-cd-pwa.yml). This CD pipeline reacts to specific successful builds of the PWA’s CI pipeline. The goal of this CD pipeline is to push the necessary changes to the environment configuration of the PWA in the environment repository.
All possible parameters for controlling the behavior of the CD job can be found here: https://github.com/intershop/cd-partner-devops.
trigger: none
name: $(Date:yyyyMMdd)$(Rev:.r)
appendCommitMessageToRunName: false
resources:
# The CD pipeline for PWA requires one pipeline resource:
# This CD pipeline is triggered when a specific build of a CI pipeline is successful.
pipelines:
- pipeline: <PROJECT_NAME>-pwa
source: <PROJECT_NAME>-pwa
trigger:
branches:
include:
# Trigger by branch pipeline
- master
# The CD pipeline for PWA requires two repository resources:
# - cd-partner-devops repository, which is a job template provided by Intershop that reflects the standard CD process for all Intershop products.
# See: https://github.com/intershop/cd-partner-devops
# - environments repository is a centralized repository that stores the manifests of Kustomization Custom Resources for all environments of all applications.
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
variables:
# Library pwa-build-configuration is provided by Intershops DevOps Environment. It provides
# the following variables:
# - BUILD_AGENT_POOL: name of the build agent pool
# - REPO_SERVICE_CONNECTION: service connection to the customer ACR
# - REPO_PATH: host name and path of the customer ACR
- group: pwa-build-configuration
#
# The CD process can be very individual.
# The template has numerous parameters to configure the behavior separately for each environment.
#
#
# In the following example, each change is incorporated into the Int environment without any restrictions.
#
stages:
- stage: CD_int
jobs:
# The Pipeline Job Template includes several tasks that read the property file, evaluate it for the respective product, and create a pull request for the specific product and environment in the Environment Repository.
# The behavior can be controlled using parameters.
- template: cd-job-template.yml@cd-partner-devops
parameters:
agentPool: $(BUILD_AGENT_POOL)
product: pwa
env: int
environmentPath: environments
triggerPipelineName: <PROJECT_NAME>-pwa
versionFilePath: int/pwa/version.yaml
prAutoComplete: true
The default name of this pipeline is <PROJECT_NAME>-pwa-cd:
The fundamental CD process is the same as described for ICM.
IOM
CI
The default repository for Intershop Order Management System is <PROJECT_NAME>-iom, which includes a file named azure-pipelines.yml. This file serves as a reference for the <PROJECT_NAME>-iom pipeline and represents the CI process for the IOM.
Example of a pipeline provided by Intershop as a standard offering:
All possible parameters for controlling the behavior of the IOM CI job can be found here: https://github.com/intershop/iom-partner-devops.
# Library iom-build-configuration is provided by Intershops DevOps Environment. It provides
# the following variables:
# - BUILD_AGENT_POOL: name of the build agent pool
# - REPO_SERVICE_CONNECTION: service connection to the customer ACR
# - REPO_PATH: host name and path of the customer ACR
# - INTERSHOP_REPO_SERVICE_CONNECTION: service connection to the Intershop container registry
# - INTERSHOP_REPO_PATH: host name and path of the Intershop container registry
variables:
- group: iom-build-configuration
# Create a repository resource to the Github repo, that is providing the centrally managed CI job.
resources:
repositories:
- repository: iom-partner-devops
type: github
endpoint: INTERSHOP_GITHUB
name: intershop/iom-partner-devops
ref: stable/v1
# Define, when the pipeline should be triggered.
# See https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/azure-repos-git?view=azure-devops&tabs=yaml#ci-triggers
trigger:
branches:
include:
- '*'
# Run CI job. Additional custom stages/jobs might be added, see example below.
stages:
- stage: CI
jobs:
- template: ci-job-template.yml@iom-partner-devops
parameters:
# You have to set here the name of the environment, that is providing the CI specific configuration!
projectEnvName: dev
# Project images, built and tested by the DevOps pipeline, are published to the project ACR only, if
# the name of the branch matches the regex passed in parameter branchesForPublication. If the default
# behavior does not fit your requirements, activate the following line and adapt the regular expression.
#branchesForPublication: '^refs/heads/develop$\|^refs/heads/master$\|^refs/heads/main$\|^refs/heads/release/\|^refs/heads/hotfix/'
# These parameters must not be changed. They are used to pass variables to the ci-job templaten, which
# are defined by library iom-build-configuration.
agentPool: $(BUILD_AGENT_POOL)
artifactsFeed: iom-maven-artifacts
dockerRepoIOMServiceConnection: $(INTERSHOP_REPO_SERVICE_CONNECTION)
dockerRepoIOM: $(INTERSHOP_REPO_PATH)
acrServiceConnection: $(REPO_SERVICE_CONNECTION)
acr: $(REPO_PATH)
The pipeline job described in the template ci-job-template.yml@iom-partner-devops builds the IOM, pushes the images 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.
The default name of this pipeline is <PROJECT_NAME>-iom:
Example of the property file:
images:
- type: iom
tag: 1.0.0-local-SNAPSHOT
name: <IMAGE-NAME>
registry: <CUSTOMER-REGISTRY>
CD
By default, there is a <PROJECT_NAME>-cd repository, where the CD pipeline for the IOM is located (default name: azure-pipelines-cd-iom.yml). This CD pipeline reacts to specific successful builds of the IOM’s CI pipeline. The goal of this CD pipeline is to push the necessary changes to the environment configuration of the IOM in the environment repository.
All possible parameters for controlling the behavior of the CD job can be found here: https://github.com/intershop/cd-partner-devops.
trigger: none
name: $(Date:yyyyMMdd)$(Rev:.r)
appendCommitMessageToRunName: false
resources:
# The CD pipeline for IOM requires one pipeline resource:
# This CD pipeline is triggered when a specific build of a CI pipeline is successful.
pipelines:
- pipeline: <PROJECT_NAME>-iom
source: <PROJECT_NAME>-iom
trigger:
branches:
include:
# Trigger by branch pipeline
- master
# The CD pipeline for IOM requires two repository resources:
# - cd-partner-devops repository, which is a job template provided by Intershop that reflects the standard CD process for all Intershop products.
# See: https://github.com/intershop/cd-partner-devops
# - environments repository is a centralized repository that stores the manifests of Kustomization Custom Resources for all environments of all applications.
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
variables:
# Library iom-build-configuration is provided by Intershops DevOps Environment. It provides
# the following variables:
# - BUILD_AGENT_POOL: name of the build agent pool
# - REPO_SERVICE_CONNECTION: service connection to the customer ACR
# - REPO_PATH: host name and path of the customer ACR
- group: iom-build-configuration
#
# The CD process can be very individual.
# The template has numerous parameters to configure the behavior separately for each environment.
#
#
# In the following example, each change is incorporated into the Int environment without any restrictions.
#
stages:
- stage: CD_int
jobs:
# The Pipeline Job Template includes several tasks that read the property file, evaluate it for the respective product, and create a pull request for the specific product and environment in the Environment Repository.
# The behavior can be controlled using parameters.
- template: cd-job-template.yml@cd-partner-devops
parameters:
agentPool: $(BUILD_AGENT_POOL)
product: iom
env: int
environmentPath: environments
triggerPipelineName: <PROJECT_NAME>-iom
versionFilePath: int/iom/version.yaml
prAutoComplete: true
The default name of this pipeline is <PROJECT_NAME>-iom-cd:
The fundamental CD process is the same as described for ICM.
FAQ
How Can I Expand the CD Pipeline to Automate Other Environments?
This process can be highly individualized depending on the project, and Intershop does not provide strict guidelines for extending or modifying the pipelines.
Example scenario: Images generated from a build of 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.
Fundamentally, there are the following options to extend 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 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 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 needs to 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: https://learn.microsoft.com/en-us/azure/devops/pipelines/?view=azure-devops.