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 come into contact with deployment processes.
The focus lies on post-go-live deployments. Deployments during the project phase are briefly mentioned at the end of this guide.
|Environments||INT||ICM Integration environment|
|UAT||ICM User Acceptance Test environment|
|PRD||ICM Production environment|
|Software||ICM||Intershop Commerce Management|
|PWA||Progressive Web App (new storefront of ICM)|
|IOM||Intershop Order Management|
Persons in the Process
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)||DEV||Development team|
|Release Manager||Person who decides when and how a deployment should take place|
|Deployment Attendant||Member 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)||OPS||Intershop Engineering Operations team|
|OPS Engineer||Member 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 Manager||Person who is in charge of the deployment schedule. Knows OPS team capacity and replies to deployment requests from the release manager.|
|DPL||Deployment of a new software version on one of the environments|
Deployment of a new software version on INT, UAT, and PRD (including SYN, if needed)
|Rollback||The database backup is restored and the previous version is deployed again.|
|SLA||Service Level Agreements|
|SYN||Synchronization process of database and file system. Usually between PRD to UAT, but also from PRD/UAT to INT.|
|WJF||Weekly Jour Fixe, a recurring meeting between implementation partner (DEV) and Intershop Operations (OPS).|
The process consists of different steps:
For more details, refer to Deployment Steps.
Generally all communication goes through Service Desk. Tickets can be opened and managed via Support Portal or via e-mail.
2-3 days before the deployment day, the release manager sends detailed instructions to OPS team via the Service Desk.
The following information must be included:
|Type of deployment||full DPL|
Current (custom) ICM release version
Target (custom) ICM release version
Custom release notes
|Short description of the changes (mandatory for hotfix)|
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.
On the deployment day an Intershop DevOps engineer will perform the deployment, according to the instructions in the Service Desk ticket.
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.
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 deployment attendant performs some basic tests to evaluate the deployment was successful.
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).
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.
CaaS systems are usually set up with an ICM application like this:
There are three different DPL types:
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.
Changes in functionality are made on code side (web and app tier) only. No database changes are included.
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.
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.
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 ).
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:
Overview of code DPL and hotfix:
Overview of 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 Deployment Instructions.)
The instructions must be sent (the very) latest on the day before the deployment, until the end of the German business day. 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).
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 Type||Lead Time||Performed by OPS|
minimum 1 week
Monday - Thursday, regular business hours
|Code||minimum 3 days|
Monday - Thursday, regular business hours
Monday - Friday, regular business hours
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.
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:
Deployment Type* / Environment
* This includes the SYN process (if in place).
** In the case of ICM deployment, the last UAT DPL will be performed by OPS to reduce the risk during the following PRD DPL.
In the case of IOM deployment the last UAT DPL will be performed by Intershop iOM-development team.
If implementation partners (DEV) execute a SYN or DPL job, they are responsible for error monitoring.
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.
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.
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.