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
• Overview - Intershop REST API Documentation

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:

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.

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 (valid to 7.10)
• 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, see Guide - Intershop Commerce Platform Deployment Process (valid to 7.10).

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

General rules and guidelines for deployments in a CaaS environment are listed in Guide - Intershop Commerce Platform Deployment Process (valid to 7.10) to ensure a common understanding of rights and responsibilities.

A clear distinction is defined between the development phase and the post-go-live phase. Deployments during the project phase, before a store is live, are:

1. Much more frequent
2. A lot less critical. So the process is less strict and the responsibilities are distributed differently.

During the development phase:

• Deployments on all environments are done by the implementation partner. No arrangements have to be made with Intershop.

After Go live:

• Deployments on INT and UAT are generally done by the implementation partner. No arrangements have to be made with Intershop.
• Intershop resumes responsibility for deployments on PRD, since Intershop has to fulfill the SLAs.

9 Operate

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

Partner Access

10 Monitor

Technical Monitoring

Technical monitoring includes:

• Infrastructure (CPU, Memory, Storage)
• Basic application monitoring (Java Virtual Machine parameters)
• Endpoint Monitoring / Storefront Availability
• Certificate checks
• Database connections, Table space sizes
• etc.

Responsibility:

• Intershop Operations Team

Business Process Monitoring

Business Process Monitoring includes: 

• Jobs
  • Intershop Standard Jobs
    • e.g. "Reset Cost Center Weekly Spent Budgets", "Regular Replication Process", "Remove Invalid Baskets"
  • Transport
  • Import/Export
  • Search Index Build
  • etc.
• Replication Processes
• End-2-End Monitoring
  • Checkout flow, etc.

Responsibility:

• Intershop implementation partner / customer

Available tools and data sources:

• Intershop Commerce Insights (ICI)

• Intershop System Management (SMC)
  Access to the SMC is available after migration Intershop Commerce Management version 7.10.31.0. Fine grained permissions for SMC/Operations (IS-31719) introduced with this version allow to grant access to Intershop System Management.

• Job REST API
• Log files