Bloomreach Experience Manager Application Release Management Tasks And Roles

Application Release management and Content Management

Content management occurs separate from the release of a new version of a Bloomreach Experience Manager application. The workflow of documents (preview, live, scheduled) is not related to the release management of a Bloomreach Experience Manager application. But content management is dependent on functionality. For instance, a new type of document is needed for a new section of the website. For a new document type a change in both the code of the site and the configuration of the CMS is needed. A new version of the Bloomreach Experience Manager application must be released before the new website section relying on the new document type can be published.

New releases of Bloomreach Experience Manager applications introduce new types of content and website components. This results in new activities for the content editors, like creating content and marketing a new section of a website or a new channel.


Bloomreach Experience Manager Release Management in acceptance and production environments

Why only acceptance and production ?

Usually developer teams manage their deployment in the development or test environment. Each organization uses their development and test environments in a different way. This is not standardized. For the deployment in acceptance and production environments the process is more formalized and non-developer roles are involved.

release management roles


Which stakeholders are involved in the Hippo release management process? We distinguish the following roles: release manager, developer, system administrator, functional administrator, tester and editor.


Release Manager

The release manager coordinates the release preparation and the cross-functional activities during a release. The development team makes the deployment notes containing all the detailed steps and instructions for the deployments. The release manager organizes a review of the deployment notes, schedules the resources for the deployment and make sure that there is support from the development team during a complex deployment. Before the release maybe a content backup is needed for testing. After a release, additional activities are needed like setting configuration settings and importing users and groups. In large organizations people from different departments perform these activities. The release manager makes a release plan for these activities. A release plan is an high-level plan which is especially useful for large complex deployments.


  • Write release plan
  • Preserve test data
  • Organize reviews of deployment notes
  • Schedule resources
  • Coordination of deployments
  • Coordination of activities after the deployment

Template deployment notes


A developer makes the deployment notes with instructions and the Groovy updater scripts. After the deployment, the developer executes manual configuration steps in the CMS console. The developer is stand-by and assists if difficulties arise during deployment.


  • Write deployment notes
  • Write Groovy scripts and JCR runners
  • Manual configuration steps in the console
  • Assist during deployments (Stand-by)

System Administrator 

The system administrator performs the deployment of the release and maintains settings and configuration on the servers. In some organizations the system administrator has access to the CMS console to perform manual configuration steps and execute Groovy scripts in the CMS. The system administrator also executes JCR runners on the CMS. In other organizations, the system administrator does not have access to the CMS and and only performs the deployment on the server and maintains the technical infrastructure. In some cases the SA belongs to the same organization, and in other cases the system administrator is external to the organization and works for a hosting party.


  • Review of deployment notes
  • Copy database to acceptance
  • Backup of the database
  • Deployment of the release
  • Maintenance of technical infrastructure
  • Manual configuration steps in the console
  • Execution of Groovy scripts and JCR runners

Functional Administrator 

A functional administrator performs the setup and configuration of the content, creates sites and maintains channels. The FA maintains the users and groups in the CMS, translations, and maintains configuration documents like key-value lists and other configuration documents. In some cases the functional administrator has access to the CMS console and performs post-deployment activities during finalization of a release.


  • Review of deployment notes
  • Configuration of value lists, configuration properties, translations
  • Setting up new sites with the channel manager
  • Manual configuration steps in the console


A tester is part of the development team or performs accepting testing of the release. A tester in a development team uses the test environment.  Or a tester works outside the development team in the acceptance environment. Testers in the development team usually do more technically-oriented testing. Testers that work in a separate team, do functional or business oriented testing on the acceptance environment. Sometimes a tester works together with an editor or editors are doing the acceptance testing. A tester is involved in the review of deployment notes. Testers also perform an intake of a new release. This intake usually consists of a smoke test in order to verify if the deployment was successful. The testers report about the quality of the release and retests solved issues.


  • Review of deployment notes
  • Intake of deployments
  • Execution of technical or acceptance tests 
  • Report results
  • Retest issues


An editor works in the production environment and uses the CMS for editing, creating and publishing content. The editor uses the channel manager for creating new pages or publishing channels. An editor can be involved in the intake of an release and helps the testers with acceptance testing.


  • Help testers with setting up test scenarios
  • Intake and acceptance testing

The next section explains the process of Hippo CMS application release:

Hippo Application Release Process

Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?