Guide - Intershop Commerce Platform Deployment Process (valid to 7.10)

Table of Contents


Product Version

7.10

Product To Version

7.10
Status

1 Introduction

Deployments of productive Intershop Commerce Management (ICM), Intershop Order Management (IOM), and Progressive Web App (PWA) systems are more or less complex procedures. This guide explains the various aspects and how the deployment process usually takes place. Additionally, general rules and guidelines are listed to ensure a common understanding of rights and responsibilities.

The target group of this document are project managers, release managers and developers of the implementation partner, as well as project managers and DevOps engineers of Intershop who are involved in deployment processes.

Note

The focus lies on post-go-live deployments. Deployments during the project phase are briefly mentioned at the end of this guide.

1.1 Glossary

EnvironmentsINTICM Integration environment

UATICM User Acceptance Test environment

PRDICM Production environment
SoftwareICMIntershop Commerce Management

PWAProgressive Web App (new storefront of ICM)

IOMIntershop Order Management

Persons in the Process


Roles

The following documentation will call the persons by their role in the process.

Depending on the partner, the size of the project and other factors, one person can cover one role or several roles.

Implementation Partner (DEV)DEVDevelopment team

Release ManagerPerson who decides when and how a deployment should take place

Deployment AttendantMember of the project team who can evaluate the success of the deployment

Deployment Mailing List

During a deployment several e-mail notifications are sent. A list of recipients is required for this. It should include the people responsible for the technical and the business side of the deployment, i.e. the release manager and the deployment attendant(s). This list will be defined with the first e-mail to the Service Desk, which includes the deployment instructions and the relevant recipients.

Intershop Operations (OPS)OPSIntershop Engineering Operations team

OPS EngineerMember of the Engineering Operations team who is assigned to a scheduled deployment

Project Manager (PM)Responsible person for the project progress on Intershop side and for the daily communication with customers and partners. Organizer of the Weekly Jour Fixe (WJF) meeting.

Deployment ManagerPerson who is in charge of the deployment schedule. Knows OPS team capacity and replies to deployment requests from the release manager.
Other AbbreviationsDBDatabase

DPLDeployment of a new software version on one of the environments

DPL block

Deployment of a new software version on INT, UAT, and PRD (including SYN, if needed)


RollbackThe database backup is restored and the previous version is deployed again.

SLAService Level Agreements

SYNSynchronization process of database and file system. Usually between PRD to UAT, but also from PRD/UAT to INT.

VMVirtual machine

WJFWeekly Jour Fixe, a recurring meeting between implementation partner (DEV) and Intershop Operations (OPS).

1.2 References

2 Process 

The process consists of different steps:

  • Scheduling
  • Provide deployment instructions
  • Perform the deployment

For more details, refer to Deployment Steps.

Note

Generally all communication goes through Service Desk. Tickets can be opened and managed via Support Portal or via e-mail.

2.1 Scheduling a Date 

  • The release manager requests a deployment via Service Desk ticket.
  • The following information must be included in the ticket:
    • Type of deployment
    • Desired date and time
    • Expected special activities (ICM upgrade, new channel, etc.)
  • The deployment manager (OPS) will respond to the ticket with either confirmation of the date and time, or suggest another time slot.
    • When a consent is reached, the deployment is added to the deployment schedule and the reservation is complete.

2.2 Providing Instructions

At least one day (better 2 or more) before the deployment day, the release manager sends detailed instructions to OPS team via the Service Desk.

Note

If deployment instructions are not received within this lead time, OPS cancels the deployment and a new deployment date must be scheduled.

The following information must be included:

ItemExample
Type of deploymentfull DPL

Current (custom) ICM release version

RELEASE/0.0.1-prod29

Target (custom) ICM release version

7.10.10.0

Additional options

  • DeployAppTier: yes
  • DeployWebTier: yes
  • InvalidatePageCache: yes
  • DBMigrate: yes (cartrige1, cartrige2, ...)
Shall Intershop (OPS) wait for the release manager feedback after a successful PRD (ED) deployment before proceeding with PRD (LV) so that DEV can perform tests or other changes?yes/no

Custom release notes
(migration path information and change log)


Short description of the changes (mandatory for hotfix)

For PWA Deployments, the following information need to be provided:

ItemExample
SSR image tag to be deployedSSR image tag: release-42
NGINX image tag to be deployedNGINX image tag: release-42
Additional values, need to be changed for the production configuration (i.e. environment variables for the SSR Container)

Please adapt the following environment variable for the SSR container:

  • name: MY_PROJECT_VAR
  • value: "foobar"

Recommendation

Please provide a deployment mailing list with the provision of the DPL instructions. It should contain the release manager and the deployment attendant(s) from the implementation partner and customer.

The mailing list will be used for communication during the deployment process, keeping all relevant persons up-to-date. Ideally, all participants are already included in the e-mail that provides the deployment instructions.

2.3 Synchronization of Database

See Concept - Intershop Commerce Platform Synchronization Process.

2.4 Performing the Deployment

On the deployment day an Intershop DevOps engineer will perform the deployment according to the instructions in the Service Desk ticket.

Note

A deployment attendant from the implementation partner must be available for the whole duration of the deployment, even if the deployment happens during the night.

A close collaboration between Intershop and implementation partner is key to a successful deployment. If anything goes wrong, DEV and OPS need to decide if a rollback should take place or not.

  • Directly before starting the deployment process, the DevOps engineer sends a short notification (reply to the the Service Desk ticket).
  • If, for any reason, the deployment cannot be started on time, the DevOps engineer will inform accordingly - if necessary jointly with the deployment attendant (DEV).

  • The DevOps engineer starts the deployment. If an ICM full deployment takes place, he will set - as the first step - a maintenance page.
  • The DevOps engineer sends a notification if any issues occur during the process and starts fixing the problem, if necessary together with the deployment attendant.
  • If a deployment of the ICM (and IOM) and PWA takes place, the (IOM and then the) ICM is deployed first, immediately followed by the PWA deployment on the same environment.
  • The DevOps engineer sends a notification after completion of PRD (ED) deployment. By default, s/he will start immediately with the PRD (LV) deployment. However, if mentioned in the instruction, s/he may wait for the release manager to test or do some configurations on the PRD (ED) before continuing with the PRD (LV) deployment.
  • If necessary, the DevOps engineer gives an update during the deployment, for instance in case of delay.
  • As soon as the deployment is completed, the DevOps engineer sends a completion notification.
  • The deployment attendant performs some basic tests to evaluate if the deployment was successful.

    Note

    The test has to be completed within 30 minutes. If it needs more time, this has to be addressed in advance and must be considered in the deployment scheduling (time).

    • If the tests were successful, the deployment attendant confirms this via the Service Desk ticket. In this case the deployment process is considered complete.
    • If there are any blocking issues, the deployment attendant informs the DevOps engineer via the same Service Desk ticket. Depending on the issue, a rollback can take place:
      • Rollback: The database backup will be restored and the previous version will be deployed again. Afterwards the deployment attendant performs the tests and confirms the successful deployment. The current deployment process is considered finished, even though not successfully completed. A new date must be scheduled to execute the deployment again.
      • No rollback: The deployment attendant decides the next steps to be taken, for instance, if a hotfix has to be performed in the following days.
    • If an ICM full deployment took place, as a last step the maintenance page will be removed.

3 Information, Guidelines, Rules

The following section describes some general and specific information around deployments.

It also contains some rules and guidelines which are required for a smooth process.

3.1 Environments

Intershop Commerce Platform systems are usually set up with an ICM application like this:

  • There are three environments: INT, UAT and PRD.
    • Each environment consists of a live and an edit cluster.
    • INT and UAT are also called PrePRD or NonPRD.
      • Both environments share a DB infrastructure (VM). The data is separated for each cluster by schema (Oracle) or database (Microsoft SQL Server).

3.2 Deployment Types

There are three different DPL types:

Full deployment

Changes in functionality are made on the code side (web and app tier) and the database side.

The increased testing effort on the operational side is ensured by a complete deployment block (consisting of SYN, UAT and PRD deployment), which is implemented by the OPS team. In addition, due to the necessary downtime, the work is usually carried out outside regular business hours (related to the chosen SLA) for PRD environments.

Code deployment



General

Code deployment means that changes to functionality are only made to the code side (web and application layers). Changes to the database are not included. For PRD environments, this can be done by either OPS or DEV.

Performed by OPS

If a code DPL for PRD is to be performed by OPS, the following applies:

With a code DPL, the OPS team only takes over the DPL of the PRD environment.

Prerequisite is that all function and performance tests have been successfully performed by the implementation partner (DEV). The release needs to be deployed on INT and UAT - and a DPL can be carried out without manual activities if possible, but in any case without manual intervention in the system.

Performed by DEV

If a code DPL for PRD is to be performed by partners (DEV), the following applies:

Constraints

  • Organizational regulations can be forced through technical measures.
  • Access may be revoked at any time if the rules are not followed.
Requirements
  • The DPL of the new release must be successfully performed in advance in the UAT environment.
  • Quality assurance must be performed after the DPL by the development department (and the customer) in the UAT environment.
Rules
  • The DPL must be scheduled in advance via the Service Desk, see Scheduling a Date.
  • Up to three "Lead" DEVs are allowed to perform code deployments on PRD (live and edit). This requires access to the SMC and is only allowed to DEV users with this permission, (see Concept - CaaS DevOps - Access and Permissions | Access to SMC (PRD)). SMC access is required to technically cross-check the DPL afterwards regarding the app server logs and/or to use the SMC monitoring features (CPU and memory usage, query times, ...).
  • The deployment can only take places during regular business hours (Mo-Th, 9 to 5) of the regional OPS team (APAC, EMEA, AMER1) to ensure quick support in urgent cases.
  • DPL of code is not allowed on Fridays, the only exception to this rule is the DPL of hotfixes, see Scheduling and Lead Time.
Execution and Testing
Before any code deployment on PRD (live and edit) is performed and triggered, DEV has to ensure that no important jobs, job chains or processes are running (such as staging). After any DPL on PRD (live and edit) DEV has to validate/check:
  • Logs (per available mount point on INT via SSH) and/or per SMC file browser (especially local appserver logs)
  • URLs/site accessibility and semantical/functional correctness of the same


1 APAC is Asia Pacific. EMEA is Europe, Middle-East and Africa. AMER is North, Central and South America.
Hotfix deployment

General

A hotfix is used to repair a faulty release, usually one (or few) errors on web, app server and/or Solr server. The code changes should be minor and successfully tested beforehand. No change on database side is possible. The release has to be deployed successfully on UAT and INT before. 

A hotfix can be installed at the push of a button without additional manual steps - so this can be done on short notice.

Note

Hotfixes should only include small code changes to fix critical / show stopper bugs in the current PRD release. The hotfix release should only change at third position of the release number (e.g. 11.0. 2 ).

A hotfix DPL (as it is a code DPL, too) can be done by either OPS or DEV.

Performed by OPS

see Code deployment above

Performed by DEV

see Code deployment above

Rules

The software to deploy also has an influence on the type of DPL. The previous classification applies primarily to ICM with classic storefront. For other cases:

  • PWA deployments are always code deployments.
  • IOM deployments are always full deployments.

3.3 Deployment Steps

  1. Scheduling a deployment date depends on the deployment type: full = UAT and PRD, Code = PRD only
    1. (OPTIONAL) UAT DPL - Deployment of new release version on UAT environment
      1. (OPTIONAL) SYN - Synchronization of database and file system from PRD to UAT (see Concept - Intershop Commerce Platform Synchronization Process)
      2. Provide DPL instructions for UAT
      3. Performing the DPL on UAT
    2. PRD DPL - Deployment of new release version on PRD environment
      1. Provide DPL instructions for PRD
      2. Performing the DPL on PRD

Overview of

  • ICM (incl. PWA) code and hotfix DPL and
  • IOM full (incl. hotfix) DPL:

Overview of

  • ICM full DPL:


The start of each individual step needs to be requested explicitly via Service Desk ticket (separate deployment instructions for UAT and PRD), along with deployment instructions. (See also Providing Instructions.)

The instructions must be sent right in time. Otherwise the deployment step is considered cancelled and has to be re-scheduled.

Receiving deployment instructions is considered as final and binding deployment request. Only send instructions when the deployment is completely agreed upon/authorized on the implementation partner's (DEV) side. The requested release version has to be successfully deployed on UAT (with same tag).

3.4 Scheduling and Lead Time

Deployments which are done by Intershop must be scheduled in advance with the Intershop deployment manager.

The necessary lead time depends on the deployment type.

Deployment TypeLead TimePerformed by OPS
Full

minimum 1 week
(better 2 weeks)

Monday - Thursday, regular business hours (9h-17h CET/CEST)

PRD deployments are bound to business hours for standard SLA customers, which does not apply to premium SLA customers, however.

Code
minimum 3 days

Monday - Thursday, regular business hours (9h-17h CET/CEST)

Hotfix

short notice
same or next day

Monday - Friday, regular business hours (9h-17h CET/CEST)

Depending on the available team capacity, a hotfix deployment is executed on the same day, or at the latest on the following day.

Short-term deployment appointments cannot be guaranteed for reasons of team capacity.

Generally at least one working day must follow after the deployment. The aim is to be able to solve any problems that may arise during regular working hours. No employee from the implementation partner (DEV), Intershop (OPS) or other related person is available at the weekend. Also public holidays must be taken into account.

Recommendations:

  • If you are planning to do continuous updates to your shop, we strongly recommend you define a fixed deployment rhythm.
    This can be e.g. "every 2nd Tuesday of the month", or "every 2 weeks", following the development sprints of the implementation partner.
    This allows the implementation partner (DEV) to have a recurring reservation in the deployment schedule. It also helps the Intershop deployment manager (OPS) to plan ahead team-wise. This can be arranged easiest in the Weekly Jour Fixe (WJF) with the Intershop project manager (OPS).
  • Make sure to request your deployments early to ensure you get the slot you desire, especially if you plan deployments in generally busy times (before Black Friday, before Christmas, ...).

Note

Even with a recurring reservation, you still have to submit a Service Desk ticket each time in order to provide the required instructions.

3.5 Who Performs the Deployment?

For an ICM production live cluster (PRD-LV), Intershop Operations team performs all deployments on production, since we are also responsible for fulfilling the SLAs.

The implementation partner is able to perform DPLs via Jenkins jobs on INT and UAT.

See the following responsibility matrix:



ICMIOM

Deployment Type* / Environment

INTUATPRDINTUATPRD
FullDEVDEV/OPS**

OPS



DEV (ISH)



OPS

Code


DEV


DEV/OPS

Hotfix

* This includes the SYN process (if in place).

** In case of an ICM deployment (same version), a UAT DPL will be performed by OPS again (or DPL by DEV will be checked) to reduce the risk during the following PRD DPL.

If implementation partners (DEV) execute a SYN or DPL job, they are responsible for error monitoring.

  • Occurring errors must be fixed immediately.
    If this is not possible, the OPS team must be informed about this per Service Desk ticket.

3.6 Downtime

In a full deployment changes are made on the database side (in the form of DBMigrate) which are always accompanied by a downtime of the web shop. This is necessary to ensure data consistency as far as possible.
This is why full deployments are usually done outside business hours of the web shop.

With a code deployment no changes are made on the database and, as a rule, no downtime is necessary.

Hotfix deployments (=small code deployment) do not require any changes on the database and, therefore, have no downtime either.

3.7 Deployments During the Setup Phase

Deployments during the project phase, before a shop is live, are a) much more frequent and b) a lot less critical. So the process is less strict and the responsibilities are distributed differently.

  • Deployments on INT and UAT are generally done by the implementation partner. No arrangements have to be made with Intershop.
  • During the setup phase implementation partners are able to do the initial deployment on PRD themselves.
  • Subsequent deployments are done by the implementation partner.
  • Once the shop is live, Intershop resumes responsibility for deployments on PRD, since Intershop has to fulfill the SLAs.

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 Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.

Customer Support
Knowledge Base
Product Resources
Tickets