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.
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.
- Release manager
- System administrator
- Functional administrator
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.
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.
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.
A channel freeze is a period of time during which users cannot make changes in the channel manager and template editor.
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.
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 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.
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.
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.
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.
After successful intake of the CMS the site is deployed by the system administrators.
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.
|Content and channel freeze||Release Manager||Yes|
|Database backup||System Administrator||Yes|
|Copy database to (acceptance) environment||System Administrator||No|
|CMS deploy||System Administrator, Developer (stand by)||Yes|
|Groovy updaters||System Administrator, Functional Administrator or Developer||No|
|JCR runner||System Administrator or Developer||No|
|Configuration||System Administrator, Functional Administrator or Developer||No|
|CMS intake||System Administrator, Tester, Developer (stand by)||Yes|
|Site deploy||System Administrator||Yes|
|Site intake||System Administrator, Tester, Developer (stand by)||Yes|
|End of content and channel freeze||Release Manager||Yes|
|Update Deployment Table||System Administrator||Yes|