Release strategies for content and configuration updates

A new release can bootstrap configuration and content into the repository. However the repository typically already contains configuration and content, for instance created by users, or from other previous releases. Consequently conflicts can arise between existing and newly bootstrapped content and configuration. This is especially the case for HST and application specific configuration, because this configuration changes often in a live environment.

Several strategies are possible to handle configuration changes. But before diving into the strategies for configuration changes, we need to explain the difference between code and configuration flows through the DTAP.

Audience

• Release managers
• Developers
• Testers
• Functional administrators
• System administrators

See also documentation on about deploying content and configuration updates

Code flow

The development of new types of content and website component are developed in a staged environment, which is isolated from the production environment. This is often called a DTAP environment, where D stands for development, T for testing, A for acceptance and P for production. The code of the new release flows in the direction of DTAP. This is called the code flow.

Configuration flow

The configuration can contain environment specific configuration and configuration coupled to the code flow. The configuration can be coupled to the code flow when new configuration is bootstrapped into the CMS. But configuration can also flow into the opposite direction (PATD).  This is explained in more detail in the next chapters about deployments and data.

In summary this table shows what directions code, content and configuration can flow through the DTAP environments.

	DTAP	PATD
Content	No	Yes
Code	Yes	No
Configuration
HST	Yes	Yes
Application	Yes	No
Backend	Yes	No

Overwrite configuration

The first strategy is to bootstrap all configuration from the release and overwrite all configuration. When following this strategy, configuration in the production environment must first be transferred back to the development environment. The production and development configurations are then merged in the development environment. The result is transferred to the production environment with the code flow.

For more technical information about update content and configuration:

• deploying content and configuration updates

Channel freeze

During this cycle a channel freeze is needed in order avoid that the configuration is lost during the deployment. The advantage of this strategy is that it is very secure and controllable because all configuration changes are contained within the release. However there are some serious disadvantages to this approach. A major drawback is that you cannot allow users to make changes in the channel manager in a test environment during the time in which the latest changes are transported to the staged environments or DTAP. This means that you have to arrange a channel freeze, a period of time in which end users cannot make changes in channel manager. This approach is suitable for situations where editors and testers do not use the channel manager and do not apply changes to the configuration. The developers are in complete control of the release.

Update configuration

A more hybrid approach is to let developers write Groovy scripts that handle the merging of new configuration with existing configuration. Content can be upgraded in this way too. The Groovy scripts are bootstrapped during deployment or executed from the editor UI in the CMS. The configuration coupled to the code flow is merged with the existing configuration.

This approach gives more flexibility and allows users to use the channel manager and template editor until the release. A disadvantage is that the application in the target environment must be tested very thoroughly. Also the editors are not allowed to make changes during the release (channel freeze). Technical details about upgrading HST configuration are described in this article.

How to bootstrap groovy runners during deployment

There are three ways to bootstrap Groovy runners during deployments:

• Manually start the scripts in the UI
• Initialize the scripts in the /hippo:configuration/hippo:update/hippo:queue. The scripts are  automatically executed during deployment.
• If system admins do not have access to the CMS, the Groovy scripts can also be bootstrapped with an external application through RMI.  The external application copies the Groovy updaters from the registry into the queue in order to execute them. 

Manual configuration

Another approach is to make any required configuration changes manually based on deployment instructions. For each release deployment notes are delivered with detailed instructions for manual configuration in CMS console.  

However this approach is error-prone by nature so in general it is better to minimize the number of manual steps and do as much as possible with Groovy updaters.

Copy to target environment

When deploying a release in the test or acceptance environment, it is good practice to copy the production database to the target environment. The source and target environment must run the same release. The database is copied from source to target (1). Then the new release is deployed into target environment (2). After the copy some additional actions are needed on the acceptance environment. For instance the virtualhost configuration should be adapted, or users and groups from the acceptance environment are imported.