Document Properties
- ICM 11
- ICM 12
- Intershop Commerce Platform
- ICM 13
Introduction
This guide outlines the policies surrounding deployments on AKS-based systems, covering the process of requesting a production (PRD) deployment for various applications (predominantly PWA, ICM 11+ and IOM 3+, see Applications to be deployed in the Glossary) and of doing self-deployments.
It is aimed at customers and developers who wish to request or perform deployments to PRD for these applications.
Deployments to non-PRD (UAT and INT) environments are not covered by this guide. The same applies to production (PRD) deployments before the platform is active (i.e., prior to the initial go live). These deployments are usually performed by the developer team and do not have to be announced or scheduled. They cannot be requested via deployment request tickets (Intershop Customer Service) either.
Glossary
Deployment Types
Regular deployment | Deployment of a regular release, with or without DB operations or additional tasks. In case certain DB operations are necessary, deployment by Intershop OPS is required. See Migration Tasks required to be communicated to Operations for a detailed list. |
Emergency deployment | Urgent deployment that:
An emergency deployment performed by OPS can be requested at short notice and for days that would not be eligible otherwise. In this case, the issue to be fixed must be explained briefly. |
Applications to be Deployed
PWA | |
ICM 11+ | |
IOM 3+ |
References
General Rules
Prerequisites
Deployment (self-deployment or otherwise) of a particular release on PRD is only allowed if it has been thoroughly and successfully tested in a non-PRD environment (UAT or INT) prior to deployment on PRD. If this is not the case, the PRD deployment will be canceled/self-deployment rights can be revoked.
Eligible Deployment Times
Times are displayed in Coordinated Universal Time (UTC). Central European Time is UTC+01:00, Central European Summer Time UTC+02:00.
Important: The following times will not be available on public holidays in the specific region and on days before public holidays in Jena, Germany (exception to the latter: emergency deployments).
Time (UTC) | Mondays | Tuesdays | Wednesdays | Thursdays | Fridays and days before public holidays in Germany (Thuringia) | Saturdays, Sundays and public holidays |
|---|---|---|---|---|---|---|
APAC: 00:00-08:00 | Premium | Premium | Premium | Premium | Premium, Emergency only | No deployments |
EMEA: 08:00-16:00 (Summer: 07:00-15:00)1 | Standard | Standard | Standard | Standard | Standard, Emergency only | |
AMER: 16:00-00:00 | Premium | Premium | Premium | Premium | Premium, Emergency only |
1 During European Summer Time (last Sunday in March to last Sunday in October).
Deployments Performed by Intershop (OPS)
In general, the customer and developer team can decide whether their deployment should be performed by Intershop (OPS) or the developer (DEV) team. However, there is a limit of 2 deployments per month by OPS for customers with SLA level Standard and 10 deployments per month for customers with SLA level Premium.
In case certain DB operations are necessary, deployment by Intershop OPS is required. See Migration Tasks required to be communicated to Operations for a detailed list.
When deciding on a deployment time, it is important to remember that a member of the project team, usually a developer, must stand by during the deployment, even at night, to run checks, answer questions in the ticket, and check whether the deployment needs to be rolled back.
How to Request a Deployment
To request a deployment performed by OPS, create a deployment request ticket using the Deployment Request form in the Customer Service Portal. Note that other types of tickets cannot be accepted.
How to Request an Urgent Deployment
You can request emergency deployments to be carried out by OPS using the Deployment Request form. Select Hotfix Deployment as the deployment type to do so.
You can create such a request without lead time, even for the same day, including Fridays and days before public holidays. However, the prerequisite is that you need to fix a critical issue with your shop with a quick deployment. Describe the nature of the problem under Hotfix Deployment Reason so that these requests can be assessed and prioritized.
Since hotfix requests are usually created at short notice, the exact deployment time requested may not be available. You can speed up the booking process by having a requester or developer stand by to answer questions in the tickets, especially during EMEA business hours, and by specifying whether the deployment can start without confirmation.
When to Request a Deployment (Lead Times)
Deployments must be requested in advance to allow for the assignment of engineers to the tasks.
Submitting a valid deployment request in a timely manner does not guarantee deployment on that day. Requests will be granted as resources become available. Be sure to request important release deployments early, especially during busy times of the year (e.g., before Black Week or Christmas). Additionally, give OPS engineers sufficient time to prepare if the deployment requires additional tasks.
Deployment type | Lead time |
|---|---|
Regular deployment | At least two full business days |
Emergency deployment | No lead time |
How to Book a Series of Deployments in Advance
You can create a Customer Service Portal ticket to book deployments to be performed by OPS in advance if you have a foreseeable deployment schedule. This includes monthly deployments, three-week sprints, or any other planned deployment dates for the near future, such as the following quarter or the current year. You will receive a list of successfully booked deployments in this planning ticket. Request changes to an existing schedule in the same way.
At least two days before each deployment, create a Deployment Request ticket for the respective date to confirm the deployment and provide instructions. If a planned deployment is not needed, cancel the appointment as soon as possible, usually via a Customer Service Portal ticket. A Deployment Request ticket is not required for canceling.
Deployments Performed by DEV (Self-Deployments)
The developer team is allowed to deploy releases tested on non-PRD environments themselves. However, not all self-deployment times are allowed, see Eligible deployment times above.
In case certain DB operations are necessary, deployment by Intershop OPS is required. See Migration Tasks required to be communicated to Operations for a detailed list.
Intershop reserves the right to revoke self-deployment privileges for the following reasons: unsafe or untested self-deployments; deployment outside of eligible times; or deployment of standard releases on Fridays or days before public holidays.
How to Request Self-deployment Rights
Self-deployments are currently enabled by default. In the past, they were disabled as part of the go-live process. If self-deployments are not enabled for your project, you can request access via a Customer Service Portal ticket. With ICM 11+ it is not necessary to list the responsible developers because everyone with access to AKS will be able to perform self-deployments.
How to Announce Self-deployments
Currently, self-deployments for AKS-based systems do not have to be announced. Instead, they are tracked in New Relic and can be viewed as described here: How to Verify Deployments via Monitoring.
Note that self-deployments are restricted to eligible deployment times.
How to Do Self-deployments
You can find instructions on the following page: Guide - Self-Service Deployments for AKS-Based Systems
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.