Multi Site Development Workflow
Multi site web application support enables multiple development teams to develop separate delivery web applications within one BloomReach Experience Manager implementation project, largely independently from each other. To be able to deploy the different web application together in one environment, some coordination between the teams is necessary.
This page outlines the recommended workflow for development teams in multi site projects. The workflow is based on the notion that one team (the "core team") is responsible for the platform webapp and coordinating platform configuration changes required by the other teams (the "extra site teams").
The "Core Team"
The "core team" manages the BloomReach Experience Manager platform and optionally a "main site" in the so-called "parent sub-project" in a way that is very similar to development in single site mode.
In most respects, the core team does not need to change its workflow, but there is one additional responsibility: If an independent site team wants changes to be made to the CMS module to support their site, the core team will need to merge those changes back into the parent sub-project. This might happen if a site team wants to add new document types to the repository or add fields to an existing document type to support a new use case. It's also possible that a site team would request configuration changes to enable new repository daemon modules etc.
The core team and the extra site team can communicate proposed CMS changes via the source code repository of the site sub-project, described below. The timing of merging these changes is up to the teams, as long as they occur before a new version of the extra site, which depends on those changes, is deployed.
The "Extra Site Team"
The "extra site team" is a semi-independent development team that is responsible for developing a separate HST-based delivery application. Note that this is a fully-functional, multi-channel HST site with access to the same content repository as the main site, but with independent code and configuration for the delivery framework. The primary constraints on this team relate to interoperability with the platform managed by the core team. In practice, this will require that the extra site team uses a compatible version of the core BloomReach Experience Manager platform. The extra site team will also need to test their site with the platform code that will be running in production when their site is deployed, to ensure that document data is stored as expected by the site logic.
To facilitate this team, a "site sub-project" can be generated, using archetypeArtifactId=hippo-site-project-archetype, which has a similar structure to the "parent sub-project". The key difference is that the CMS module has been replaced with a single POM that depends on the parent sub-project CMS. By default, this CMS module will produce a cms.war that is functionally identical to the parent CMS. However, the extra site team can propose changes to CMS code, dependencies, or configuration and test these changes using this separate CMS module. This team can also have separate development-only configuration for auto-export, etc.
Before the extra site can be deployed to a combined staging or production environment, the proposed changes to the CMS, cms-dependencies and repository-data/application modules must be moved to the parent sub-project. Since these module directories are normally (almost) empty, the presence of files alone is a strong signal that coordination is required. A continuous deployment pipeline could be configured to detect this situation and generate appropriate feedback.
In most other respects, the development workflow for the extra site team is unchanged from previous BloomReach Experience Manager development practice. Existing dev tooling, such as auto-export and Essentials should work as expected.