Multi Delivery Webapp Development Workflow

Introduction

Multi delivery 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 webapp 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 delivery webapp teams").

To get some hands-on experience, it is recommended to follow the Add a Second Delivery Webapp tutorial.

The "Core Team"

The "core team" manages the Bloomreach Experience Manager platform and optionally a "main delivery webapp" in the so-called "parent sub-project" in a way that is very similar to development in single webapp mode.

In most respects, the core team does not need to change its workflow, but there is one additional responsibility: If an independent delivery webapp team wants changes to be made to the CMS module to support their webapp, the core team will need to merge those changes back into the parent sub-project. This might happen if a delivery webapp 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 delivery webapp team would request configuration changes to enable new repository daemon modules etc.

The core team and the extra delivery webapp 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 delivery webapp, which depends on those changes, is deployed.

The "Extra Delivery Webapp Team"

The "extra delivery webapp 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 webapp with access to the same content repository as the main webapp, 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 delivery webapp team uses a compatible version of the core Bloomreach Experience Manager platform. The extra delivery webapp team will also need to test their webapp with the platform code that will be running in production when their webapp is deployed, to ensure that document data is stored as expected by the webapp logic.

To facilitate this team, a "delivery webapp 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 delivery webapp 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 delivery webapp 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 delivery webapp team is unchanged from previous Bloomreach Experience Manager development practice. Existing dev tooling, such as auto-export and Essentials should work as expected.