1 Introduction

The Intershop offering provides several types of releases. These are presented in this concept.

Our continuous releases enable a fast deployment (DevOps) of improvements, new features and latest security enhancements/fixes. 
This way our customers always have the latest version and can thus avoid costly upgrades.

1.1 References

• Overview - CaaS DevOps
• Intershop Product Resources
• Overview - ICM Release Communication

2 Update Principles

The publishing of updates is always done according to the following principles:

1. Releases are backward compatible.
2. Releases are cumulative. 
3. Intershop provides regular announcements about upcoming releases.
4. UAT is updated first, followed by production.

The customer always retains control of the update process. This means there is a deployment window defined by the customer and a default monthly schedule for continuous releases. 

It is also possible to fall back to a LTS (long term support) release schedule, meaning that releases are applied every 6 months.

3 Release Types

Intershop essentially offers two types of release cycles, namely monthly releases and long term support (LTS) releases.

Furthermore, there are hotfix releases which apply for both types.

3.1 Continuous Releases for ICM – Monthly Releases

There are monthly releases that are planned in advance. As soon as a monthly release is introduced, the previous monthly release is considered outdated.

Hotfixes are only available for the current continuous release.

3.2 Long Term Support (LTS) Releases for ICM

Long term support releases are released every 6 months. In contrast to monthly releases, no new features are made available within these 6 months.

However, hotfixes are available as well.  LTS releases are supported for one year.

3.3 Continuous Releases for ICM – Hotfix Releases

Hotfix releases may be necessary between regular releases for urgent security or bug fixes. 

Typically, hotfixes:

• Are API-stable,
• Do not require migration of customizations,
• Require no database changes,
• Can be applied with zero-downtime deployment.

4 Impact of Continuous Releases of ICM

With regard to releases, please note the following:

• The customer is accountable for using a supported ICM version for the customization project.
• A downtime during deployment might be necessary, if database changes are part of the update.
• Sometimes changes to customization might be necessary, for example for deprecated APIs.
• Acceptance testing is required for every update (business capacity), this includes:
  • Core processes
  • Customizations
  • Interfaces to 3rd-party applications
  Furthermore, automated tests of the customizations are highly recommended.