Introduction to Release Management

Server Environments

In software development, there are several stages in the release management process of a project. Typically, at each stage the software project is deployed in different server environments associated with that stage:

• Development refers to the local environment in which the developers work on the next release of a software project.

• Test refers to the environment in which the software is deployed in order to test features under development.

• Acceptance refers to the environment in which a software release is deployed in order to test finished features, before deployment in the production environment.

• Production refers to the environment in which a software release, which has passed all acceptance tests, is deployed and made available to end users.

In general, "production" is at least one version behind "development" (and most likely behind "test" and "acceptance").

Repository Data

A software project typically consists of three parts:

• code

• configuration

• content

In a typical Bloomreach Experience Manager project, code is managed as a Maven project and stored is some kind of Version Control System (such as SVN or Git).

Configuration in a Bloomreach Experience Manager project is stored in the content repository and therefore part of the Repository Data. Examples of configuration stored in the repository are users, groups, document templates, website templates, and CMS UI component wiring.

Content in a Bloomreach Experience Manager project is stored in the content repository and therefore part of the Repository Data. Examples of content stored in the repository are documents and images.

For clarity, we will use the following definitions:

Repository data: everything stored in Hippo Repository, including configuration and content.

Configuration: the part of the repository data contributed and maintained by developers and administrators in order to control how a particular instance of the system behaves.

Content: the part of the repository data contributed and maintained by CMS users to manage their websites.

The repository data is stored as a JCR node tree. Relevant paths include:

• /content - contains all content like documents, images, assets.

• /hippo:configuration - contains all CMS configuration, including plugin configurations.

• /hippo:namespaces - contains document namespaces defining document types and editing templates.

• /hst:hst - contains configuration of all publication channels, e.g. websites, mobile sites, etc.

• /hst:hst/hst:configurations/[channel_name]/hst:workspace - contains content like user-created pages, site menus and components.

Release Management and Repository Data

Release management on the code is usually done through the creation of tags in the VCS and their associated Maven artifacts such as JAR or WAR files. The process is mostly standardized and automated, making deployment of a new release in any of the server environments straightforward.

Release management on the repository data (including content and configuration) is more difficult because, unlike code, it is likely to change in the production environment after deployment. This is by nature: content is constantly created, modified and removed by end users, and configuration may be updated by administrators. This means that any new release requires adequate handling of existing repository data:

• changes in configuration must be merged with existing configuration

• changes in content structure must be applied to existing content

In short, a new release must update existing repository data while conserving data integrity. Generally, this requires manipulating existing repository data.

Ideally, a software release should be completely self-contained, i.e. the release artifact(s) should contain anything necessary to update existing repository data automatically. Incidentally, a repeatable series of simple manual steps may be necessary. This is necessary to enable consistent and reliable verification of a release through the release management stages.

Summary

In short:

• A Bloomreach Experience Manager project stores content and configuration as repository data.

• By nature, repository data changes over time in a production environment.

• Each new release of a Bloomreach Experience Manager project can introduce changes in configuration and content structure.

• On deployment of a new release in a production environment, existing repository data must be updated to the standards of the new release.