This document describes the DevOps processes for Intershop Commerce Management in a CaaS context.
Intershop CaaS follows the DevOps principles:
The DevOps process can be visualized in the following way:
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.
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:
Intershop | Partner | |
---|---|---|
Documentation, Communication |
|
|
Requirements |
|
|
|
| |
|
| |
Checklist |
| |
Connect |
|
|
Test Infrastructure and Processes |
| |
Deployment Demo |
| |
Acceptance declaration |
|
|
For the collaboration between Intershop and the CaaS Partner, a shared Confluence space will be set up.
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.
Note
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.
The REST API Documentation can be found here: http://developer.cloud.intershop.com.
The Java API (JavaDoc) is available in Intershop Studio.
For more information see Guide - 3rd Party Integration.
Debugging the solution is possible as follows:
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
'!
Intershop provides frameworks for testing on all levels
Additionally, code quality checks and performances tests can be performed.
For details refer to Overview - Test Frameworks.
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.
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:
DPLs are used in the following three environments:
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).
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:
During the development phase:
After Go live:
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:
Technical Reporting:
Capacity Management:
Performance Management:
Security Management:
Continuity Management:
Incident Management:
Problem Management:
Intershop Component | Infrastructure and System Layer | Application Layer |
---|---|---|
Intershop Commerce Management | The partner/customer does not have direct access |
|
Intershop Order Management | Intershop 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
| |
Process Automation Environment |
|
Technical monitoring includes:
Responsibility:
Business Process Monitoring includes:
Responsibility:
Available tools and data sources:
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.
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.