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

• Overview - Intershop Commerce Management
• Intershop REST API Documentation
• Guide - 3rd Party Integration

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.

4.1 API

The REST API Documentation can be found here: http://developer.cloud.intershop.com.

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: 

• Concept - Continuous Delivery Tools
• Cookbook - Setup CI Infrastructure

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.

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 operations-support-CUSTOMER@intershop.de 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.

The following DPL types are available:

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.