Guide - CaaS DevOps - Intershop Commerce Management

1 Introduction

This document describes the DevOps processes for Intershop Commerce Management in a CaaS context. 

Intershop CaaS follows the DevOps principles:

  • Iterative
  • Incremental
  • Continuous
  • Automated
  • Self-service
  • Collaborative
  • Holistic

1.1 References

2 DevOps Life Cycle

The DevOps process can be visualized in the following way:

3 Plan

Every DevOps cycle starts with a planning phase. Requirements need to be defined and have to be broken down. The feedback of the last cycle has to be taken into account. 

When Azure DevOps is used, the "Azure Boards" is a good tool to do the planning.

3.1.1 Discovery Phase

At the very start of every CaaS project, there will be a discovery phase. Here you can find an overview about the typical tasks and responsibilities during the discovery phase:


Documentation, Communication

  • Setup Confluence Space
  • Define PM for OPS Setup
  • Define weekly status call
  • Provide users for Confluence
  • Define PM for OPS Setup
  • Define communication to customer
    (Partner as SPOC)
  • Validate sizing with SRF
  • Approval of non-standard Infrastructure
  • Provide SRF (sizing request form)
  • Provide detailed Infrastructure
    (incl. Standard & HA infrastructure)
  • Validate and schedule phases to be in sync with project timetable
  • Provide project timetable
    (incl. Start of Dev, Prod-deployments, GoLive and other milestones)
  • Validate contractual requirements
    (follow-up call)
  • Provide the exact ICM version
  • Create checklist for open topics

  • Artifact Repo Partner with ISH
  • Mailserver
  • CaaS license
  • Provide access to serveral systems
  • provide Art. Repo URL for Assembly
  • Provide mailserver credentials
Test Infrastructure and Processes
  • Transfer connections
  • Jenkins base configuration
  • Deployment jobs
  • Housekeeping jobs
  • Certificates + Whitelisting
  • System documentation

Deployment Demo

  • Demonstration of a complete deployment on INT/DEV

Acceptance declaration

  • Switch to ongoing operation
  • Test and verify full functional infrastructure, access and jobs

For the collaboration between Intershop and the CaaS Partner, a shared Confluence space will be set up.

4 Code

Intershop development is typically Java-based and uses Git as source code repository. Developers can have a development environment on their local machine. 
To kick-start the development process, blueprint projects are available.

Intershop Commerce Management development in particular is done using Intershop Studio, a standard Eclipse with some Intershop-specific extensions. For more details, see Overview - Intershop Studio. 
An Intershop project used the Gradle multi-project build. See Cookbook - Gradle Developer Workflow for more information.

Intershop Commerce Management consists of several development artifacts which are described here: Overview - Development Artifacts.


Storefront development can be done using the classic approach with Intershop templates and pipelines or by using the new Progressive Web App. The PWA is the recommend approach for CaaS.

For recommended customization options, please see: Guide - CaaS Customization Options.

4.1 API

The REST API Documentation can be found here:

The Java API (JavaDoc) is available in Intershop Studio.

4.2 3rd Party Integrations

For more information see Guide - 3rd Party Integration.

4.3 Debugging

Debugging the solution is possible as follows:

  • On HTTP basis
    • Pipeline debugging via Intershop Studio
    • Web development tools (CSS, JS, etc.)
  • JMX via SSH tunneling using the INT environment
    • Intershop basically takes over the setup on its own monitoring server
  • Access to DB schemas (read/write) of INT environment; sync with PRD environment is possible on-demand

5 Build

The build process has to be set up as described here: 

This needs some DevOps expertise on partner side. Due to that Intershop also provides the complete CI infrastructure as a service. Intershop uses Azure DevOps for that purpose, also see Guide - Azure DevOps for CaaS Projects.

Keep in mind that the environments PRD, UAT and INT are not using development settings, e.g., the CheckSource properties are generally set to false. Make sure all custom ISML templates are compiled during the build process by applying Gradle plugin 'com.intershop.gradle.isml'!

6 Testing

Intershop provides frameworks for testing on all levels

  • Unit tests
  • Integration tests
  • User interface tests

Additionally, code quality checks and performances tests can be performed. 

For details refer to Overview - Test Frameworks.

7 Release

A release is automatically created by the CI system, when the code is tagged with a release label in Source Code Repository (e.g., GIT). The release tag must be of the format RELEASE_x.x.x.

Snapshot releases cannot be deployed. 

8 Deploy

Deployment of the production system will be done by the Intershop operations team in collaboration with the CaaS partner. The partner provides the release in the project artifact repository. From there it will be picked up by the Intershop deployment process.

Deployments of the pre-production/UAT and integration system can be triggered by the parter in self-service. For this purpose, access to a Jenkins web console will be provided by Intershop. This allows triggering of jobs like:

  • Deployment
  • Restart
  • Dump export/import
  • Shared file system sync
  • Database dump upload
  • Etc.

8.1 Environments

DPLs are used in the following three environments:

  • INT (Integration)
  • UAT (User Acceptance Test)
  • PRD (Production)

These consist of a live and an edit cluster. The INT and UAT are also called PrePRD. Both environments share a DB infrastructure (VM). The data is separated for each cluster by schema (Oracle) or database (MS Sql Server).

8.2 Deployment Rules for ICM

A deployment (DPL) of a release always consists of a block of individual steps. This usually consists of a synchronization process (SYN) in which the file system and the DB are synchronized from PRD to UAT, as well as a UAT and a PRD DPL. The individual steps are only carried out by the OPS team after prior instruction (request). This means that the start of each block step (SYN, UAT- and PRD-DPL) is released by the developer (DEV) by e-mail to with details of the deployment or other instructions (release number etc.) at the agreed time. Otherwise the block step is cancelled and a new date is agreed.

Furthermore, a distinction is made between three different DPL types:

  • Full
  • Code
  • Hotfix

In a Full-DPL, function changes are made both on the code and on database side (the latter in the form of dbinit/dbmigrate), which are always accompanied by a downtime of the webshop, in order to ensure the consistency of the data as far as possible when making the necessary changes on the database level. With a Code-DPL, compared to a Full-DPL, no changes are made to the database and, as a rule, no downtime is necessary. A Hotfix-DPL (without downtime) is only used to correct one (or fewer) errors within a short period of time after the errors have been detected. A hotfix is used to repair a faulty release so that a new server (Web, App or Solr) can be reinstalled at any time at the push of a button, without additional manual steps being necessary.

8.3 Rights and Obligations

In addition to the OPS team, the DEV teams are also able to independently perform DPLs (via Jenkins jobs) on the respective INT and UAT environments. On the PRD environment, however, only the OPS team is allowed to execute DPLs.

Basically, the DPL order of a new release is as follows:

  1. DPL on INT
  2. SYN (from PRD to UAT)
  3. DPL on UAT
  4. DPL on PRD

The person who executes a SYN or DPL job is also responsible for ensuring that any errors that may occur are corrected immediately or that the OPS team is at least informed (keyword: monitoring and alarm messages).

8.4 Scheduling

For the three DPL types, there are different handling procedures for the execution. The dates must always be agreed in advance with the OPS team leader. An appointment should be made as early as possible and according to a fixed rhythm (e.g. every 2nd Tuesday of the month). This makes resource planning easier and safer. Short-term DPL appointments cannot be guaranteed for reasons of resource utilisation.


PRD-DPLs are only carried out on weekdays from Monday to Thursday. At least  working day after the DPL must follow. The aim is to be able to solve any problems that may arise during regular working hours. On the other hand, no employee from DEV, OPS or Customer Success Manager (SPoC) is available at the weekend. Public holidays must be taken into account in scheduling.

The following DPL types are available:






Full-DPLs contain the most comprehensive changes. Therefore an appointment of at least one week (better 2 weeks) in advance is necessary.

The increased testing effort on the operational side is ensured by a complete DPL block (consisting of SYN, UAT and PRD-DPL), which is implemented by the OPS team.

In addition, due to the necessary downtime, the work is usually carried out outside regular business hours for PRD environments.

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 DEV and that a DPL can be carried out without manual activities if possible, but in any case without manual intervention in the system.

Due to the limited code change(s), it is possible to request a DPL date for PRD at short notice.

As a rule, this should be at least one day in advance. In an emergency, a DPL is possible on the same day, depending on the available resources.

8.5 Rollback

Basically, a rollback is done by deploying an older version. A distinction is made between two variants:

  • On code level only
    With a rollback at code level, the database does not have to be adapted and can therefore be carried out in a short time without downtime.

  • On code and on database level
    In the second variant the database have to be changed too. For this reason, an older database state must be restored.

Two scenarios can be distinguished for this second variant:

  • Short-term rollback
    In a deployment with database changes, replication between the active and passive database will be stopped. Deployment then takes place. If an error is detected at database level for a short time, a manual switch is made from the active to the passive database instance and the deployment of the previous version takes place. The formerly active database is then updated to the status of the formerly passive database, which is now active, and the replication process is reactivated in order to ensure reliability.

  • Medium-term rollback
    A database backup is created on a daily basis. This can be used to restore the database if an failure wasn't discovered until a few hours after deployment. To do this, a downtime is agreed and a restore of the database and the code deployment of the previous version is performed.

9 Operate

9.1 Intershop's Responsibilities

In general, Intershop is responsible for the infrastructure and system layer. The partner does not have direct access.

The following tasks are Intershop's responsibility:

Technical Monitoring:

  • Automated monitoring of hardware, functional system components, automated jobs, availability of certain services & resources
  • Manual review of application-specific log files
  • Automated alerts (e-mail, SMS)

Technical Reporting:

  • System performance and utilization
  • Diagrams per timeframe, component, pipeline
  • Reporting including suggestions for defect prevention and system improvements

Capacity Management:

  • System utilization monitoring
  • Pro-active and early communication/advice for necessary increase of resources

Performance Management:

  • Monitoring of critical application performance changes
  • Operating system, database and application tuning
  • Monitoring of application performance
  • Pro-active and early communication/advice for necessary increase of resources

Security Management:

  • Definition, setup and maintenance of administrative permissions and roles
  • Software component updates

Continuity Management:

  • Backup & recovery of agreed directories
  • Transactional database backup
  • Functional restore (recovery of minimal functions)
  • Redundant multi-staged backup architecture

Incident Management:

  • 24x7 by phone and mail
  • Trouble ticket system
  • Focused on minimal business impact
  • Recovery of operational readiness

Problem Management:

  • 24x7 by phone and mail
  • Trouble ticket system
  • Focused on minimal business impact
  • Recovery of operational readiness

9.2 Partner Access

Intershop ComponentInfrastructure and System Layer

Application Layer

Intershop Commerce Management

The partner/customer does not have direct access
  • To storefront and back office on all environments like PRD, UAT and INT
  • To virtual machines via SSH (via low-privileged users) and database schema (read/write) on INT environment
  • To SMC on INT environment
  • No changes or installations without consultation with Intershop
Intershop Order ManagementIntershop is responsible; the partner does not have direct access.
CI System

If the partner uses his own CI system, then the partner is responsible within his own domain for

  • Providing and operating source code repository
  • Build environment and corresponding artifact repository (master)
  • Granting access to master artifact repository to Intershop’s proxy artifact repository in Azure
Process Automation Environment
  • Deployment on UAT and INT
  • Export of DB dumps
  • Import of DB dumps to INT
  • Triggering of transfer processes where applicable

10 Monitor

10.1 Technical Monitoring

Access to monitoring web interface to technical layer possible, like:

  • System parameters (e.g., CPU usage)
  • Application parameters (e.g., storefront availability, java virtual machine parameters).


10.2 Business Monitoring

Access to monitoring web interface with extended monitoring services is possible with the following restrictions:

  • Intershop basically takes over the setup on its own monitoring server
  • Partner delivers coordinated checks and notification paths (like e-mail, SMS, etc.) in advance
  • Intershop will review and implement those checks
  • Partner is responsible for responding to business monitoring alerts


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