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 been accepted as final, is deployed and made available to end users.

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

Repository Content

A software project typically consists of three parts:

• code

• configuration

• data

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

Data in a Hippo CMS project is commonly referred to as "content", and stored in the content repository (Hippo Repository in this case). Examples of content stored in the repository are documents and images.

Configuration in a Hippo CMS project is also stored in the content repository, and therefore technically also considered "content". Examples of configuration stored in the repository are users, groups, document templates, website templates, and CMS UI component wiring.

In the repository, content is stored as a JCR node tree. Relevant paths include:

• /content - contains all content (i.e. data) like documents, images, assets.

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

• /hippo:namespaces - contains document namespaces defining document types (i.e. data structures) and editing templates.

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

Release Management and Repository Content

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 content (including data as well as configuration) is more difficult because, unlike code, it is likely to change in the production environment after deployment. This is by nature: data is constantly created, modified and removed by end users, and configuration is constantly modified and personalized by end users too. This means that any new release requires adequate handling of existing content:

• changes in configuration must be merged with existing configuration

• changes in data structures must be applied to existing data

In short, a new release must update existing content while conserving data integrity. Generally, this requires manipulating existing content, either manually or automatically.

Ideally, a software release should be completely self-contained, i.e. the release artifact(s) should contain anything necessary to update existing content, either automatically and/or through a repeatable series of simple manual steps. This enables consistent and reliable verification of a release through the release management stages.

Summary

In short:

• A Hippo CMS project stores data and configuration as repository content.

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

• Each new release of a Hippo CMS project can introduce changes in configuration and data structures.

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