Document Properties
- ICM 11
- ICM 12
- ICM 14
- Intershop Commerce Platform
- ICM 13
Introduction
This guide provides information on self-service processes for AKS-based systems. For an overview of production (PRD) deployment policies, including self-deployments, refer to the deployment guidelines.
It is intended for developers who want to deploy to various applications, including PWA, ICM 11+ and IOM 3+, as well as environments such as production (PRD) and non-production (UAT and INT).
Glossary
Applications | PWA | |
ICM | ||
IOM | ||
Environments | PRD | Production environment |
NonPRD | UAT and INT environments | |
UAT | User Acceptance Test environment | |
INT | Integration environment | |
Other | AKS | Azure Kubernetes Service |
CI/CD
The following page provides a general overview of the CI/CD process:
Concept - Intershop Commerce Platform DevOps - CI/CD Development Process
Self-Service Deployments
When deploying to production, please observe our deployment guidelines.
How to Do Self-Deployments by Default
With AKS-based systems, self-deployments of all applications work in a similar way.
The following sections describe the default configuration. Your branch and environment names, as well as other configurations, may vary. If you are unsure, refer to your project documentation.
Deployment to NonPRD (UAT or INT): By Commit
You can trigger an automatic deployment by committing or merging your release to either the master branch (UAT) or the develop branch (INT) of the respective application.
This will trigger the creation of a new Docker image named after the build number and push it to the container registry. The Flux configuration
(for instance version-edit.yml or version-live.yml in the environment’s application, according to GitOps Repository Structure) will then be automatically updated and applied to the Kubernetes cluster.
Deployment to PRD: By Setting a Release Tag
Self-deployments to production are subject to certain restrictions. There are defined deployment times (it is not possible to deploy 24/7), releases must be tested on NonPRD in advance, and risky self-deployments must be avoided. Refer to our deployment guidelines.
Deployments to PRD follow a similar pattern as deployments to NonPRD.
After the release tag has been created (see picture above), commit the release tag once it is written into the correct environment file
(e.g., PWA PRD Edit: https://dev.azure.com/ish-<cstmr>/<cstmr>/_git/environments?path=/prd/pwa/version-edit.yaml).Flux recognizes this commit and starts the deployment process.
Self-deployments to PRD (as documented here) were disabled as part of the regular go-live process in the past. If this was the case for your system and you would like to re-enable them, you can request this via a service ticket.
How to Verify Deployments via Monitoring
To check the state of your deployments through dashboards in New Relic:
Log in to your New Relic account via this link and select your customer account in the drop-down menu All Accounts in the top right corner.
Click Dashboards in the side bar.
Select the dashboard with the name of the application you wish to check (PWA, ICM or IOM).
Select the tab Deployments.
Here you can check the version that is currently deployed and the status of the last deployment.
If you experience any problems with your deployment, check the Helm Deployment Events log for error messages:
Click Dashboards in the side bar.
Select the dashboard AKS Cluster Overview.
Select the tab Helm Deployment Events.
Here you can view the Helm Deployment Events log.
Disclaimer
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Website, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.