Bloomreach Experience Manager Application Release Process

Process of a Bloomreach Experience Manager release

A Bloomreach Experience Manager release is a sequence of activities that need to be executed in the right order and with the correct timing. The activities can be grouped into three phases: preparation, execution and finalization. The stakeholders described earlier are all involved in the different phases. The release manager coordinates all those activities for all the different types of stakeholders.

Preparation

In the preparation phase, the development team writes the deployment notes. The deployment notes are a set of instructions which explain in detail the different steps before, during and after the deployment. The release manager organizes review meetings with the developers and system administrator and/or functional administrators, to assure that all parties have a common understanding of the deployment notes. Also, the time needed for deployment and other activities are estimated. For instance, the execution of long running migration of configuration or content is taken into account. The release manager plans and schedules the resources for the deployment.

Involved are:

• Developer
• Release manager
• System administrator
• Functional administrator

Template deployment notes

Execution

In the execution phase the deployment, manual configuration changes are made, upgrade scripts are executed, the intake is done and in case the deployment fails, a rollback is performed. Much coordination is needed because all roles are involved the execution phase. The deployment plan made by the release manager in the preparation phase ensures that all activities are coordinated.

Deployment procedure

The deployment procedure contains a number of steps which are not always obligatory. In the most simple scenarion only the CMS and site applications are deployed. The release manager describes in the deployment plan, all the steps needed for the deployment. Also the release manager describes who is doing each step.

Content and channel freeze

Before the start of the deployment the release manager announces a content and channel freeze in the production environment.

Content freeze

A period of time during which the editors cannot enter content. A content freeze can be enforced in different ways. One way is to temporarily deactivate the CMS users. Another way is to disable access to the CMS server. Or make an agreement with the users to not access the CMS during the content freeze. Another option is to bring the CMS temporarily offline.

Channel freeze

A channel freeze is a period of time during which users cannot make changes in the channel manager and template editor.  

Database backup

The system administrator does a backup of the database after the content and channel freeze has started. It is recommended to estimate the time needed to make the backup, as backing up a large database can take a lot of time.

Copy database to acceptance environment

When deploying a release in the acceptance environment, it is recommended to make it closely resemble the current production environment before the release is deployed. To achieve this the acceptance environment must run the same application release as the production environment, and the database contents from the production environment must be copied to the acceptance environment.  Some additional configuration steps in the console are required to ensure that the host configuration works for the domain of the acceptance environment. The database copy will also replace the users and groups in the acceptance environment so in some organizations these are backed-up first, and restored afterwards.

CMS deployment in acceptance environment

The system administrators bring the CMS and site applications down at the start of the deployment. Then the new CMS release is deployed. 

Upgrade and update on acceptance

When the CMS is up again, scripts are executed to upgrade and/or upgrade content and configuration.

• Upgrade: the release introduces a new version of Bloomreach Experience Manager, or a new version of a Bloomreach Experience Manager plugin. Existing configuration might need to be upgraded to the new version.
• Update: the release introdces changes to the content model or delivery tier configuration. Existing content and configuration might need to be updated to reflect the new model or configuration.

Scripts come in two flavors: Groovy scripts and JCR runner scripts. 

References:

Content upgrade use cases

Groovy updater editor 

Groovy scripts

The release contains Groovy scripts delivered by the development team. These scripts take care of the configuration changes or content migration. Usually developers are running the Groovy updater scripts. But it is also possible to automatically bootstrap the scripts after the deployment using Bloomreach Experience Manager's bootstrap mechanism.

JCR runners

JCR runners are stand-alone batch Java applications which are used to performs updates of the Bloomreach Experience Manager configuration after the deployment. The system administrators start the JCR runner on the server. The development team delivers the runner as a separate package. Instructions for the runners are included in the deployment notes. Since Groovy updaters where introduced in v7.8, JCR Runners are not used very often anymore.

Configuration

For most deployments some manual configuration steps are required after the deployment. These steps are described as instructions in the deployment notes. The instructions also indicate when the manual configuration changes are done.  They usually take place during the downtime of the site or during a short time window after the site is up again. 

By whom the manual configuration steps are performed depends on the organization. Sometimes developers do these configuration steps, because they have the most knowledge about the configuration options and the console. This is especially true for the HST configuration. Sometimes system administrator do these steps following the instructions in the deployment notes. And in other cases, a functional administrator does the manual configuration.

CMS intake

During the intake, the tester verifies if the CMS was deployed successfully. Usually a standard smoke test script is executed that verifies basic functionality of the CMS. Another useful check is for errors and warnings in the log files. This is done by the system administrator. During the intake developers are stand-by to help and solve unexpected issues.

Rollback

In case the deployment fails or the intake shows that there are blocking failures which cannot be solved, the release manager must announce a rollback. The system administrator will execute the rollback. After the rollback is done, again an intake is needed for the CMS and site. Usually the best moment to decide for a rollback is after the CMS intake.

Site deployment

After successful intake of the CMS the site is deployed by the system administrators.

Site intake

During the site intake the tester verifies if the site was deployed successfully. Again a standard smoke test is executed that verifies the site. Another useful check is for errors and warnings in the log files. This is done by the system administrator. During the intake developers are stand-by to help and solve unexpected issues.

End of content and channel freeze

When the intake of the release is a success, the release manager announces the end of the content and channel freeze.

Update deployment table

The system admin updates after the release the deployment table. This table is an overview of all releases with versions for all environments.

Example deployment table

Overview