Deploying multiple tenants to AEM through Adobe Cloud Manager can be challenging. Cloud Manager does not provide the ability to configure multiple deployment pipelines to AEM. More specifically, Cloud Manager cannot deploy from more than one Git repository.
In a multi-tenant ecosystem, each tenant dev team needs to store their code in separate repositories and deploy them when needed. Ideally, this should be done automatically for lower environments like DEV whenever there is a code commit. To achieve this with Cloud Manager, someone must manually update the deployment pipelines to point to different code repositories or all tenants must be wrapped into a singular aggregator project.
Since manually updating pipelines is cumbersome and does not produce the desired result for AEM as a Cloud Service (AEMaaCS), we will look at the latter approach of creating a singular aggregator Maven artifact for deployment. In this blog, we’ll quickly cover the following approaches:
- Maven Submodules
- Maven Dependencies
- Hybrid Maven Dependencies (not applicable for AEMaaCS)
For a more in-depth look at these approaches, stay tuned for my upcoming guide to Multi-Tenant AEM Deployment Strategies in Adobe Cloud Manager.
Maven Submodules
Using Maven submodules means adding each tenant’s code into a parent or aggregator project that encapsulates the building of all the tenants. As long as a tenant’s project is added in the reactor pom.xml, it will get built along with the aggregator project to produce a single Maven artifact that can be deployed. Essentially, the tenant’s code must be copied into the aggregator project’s Git repository which is then made available to Cloud Manager’s deployment pipelines.
There are a couple of ways to achieve this. One is to use Git submodules in the aggregator project. By configuring Git submodules in the aggregator project, each tenant’s code is pulled into the aggregator when the Git submodule commands are explicitly executed within the aggregator’s Git repository. This should be done every time a deployment is needed, otherwise, updates in the tenant code will not be reflected in the aggregator project.
A second way is to create a script that will copy a tenant’s code into the aggregator’s code repository based on a tenant’s criteria such as on commit to a particular branch in the tenant’s code repository. This will ensure that updated code is pushed to the aggregator project whenever a tenant is ready. This also provides each tenant control over when their code should be made available for deployment.
Maven Dependencies
With Maven dependencies, the aggregator project does not require each tenant’s codebase to reside in its project but rather their built artifacts. Instead of adding each tenant as a Maven submodule, the aggregator project embeds each tenant’s artifact as a Maven dependency. Hence, when the aggregator project is built, it will bundle each tenant’s previously built artifact into its own artifact to produce a singular artifact. This is similar to bundling 3rd party libraries like ACS Commons into your own build so that it can be deployed simultaneously with your own artifact.
For this approach to work, each tenant is required to build their own artifacts and store them in a Maven artifact repository. Along with that, Cloud Manager will need access to the artifacts to embed them in the aggregator’s artifact.
Do note that since no tenant code is available to Cloud Manager, the code is also not subject to the code quality SonarQube scan provided by Cloud Manager. These SonarQube rules must be met for Adobe to provide the support based on agreed-upon SLAs. One way this can be mitigated is by having the customer provide such scanning before the artifacts being stored in the artifact repository. An alternative is to leverage the code quality pipelines in Cloud Manager in conjunction with Git webhooks to make use of the SonarQube scanning from Adobe.
Hybrid Maven Dependencies
A variation of the previous approach is to perform a hybrid deployment where lower environment deployments are handled directly by each tenant, and the higher environment deployments are via Cloud Manager. In the lower environments, tenants will individually deploy their artifacts directly to AEM instead of using an aggregator project through Cloud Manager. This can be easily done with AMS infrastructure by ensuring network connectivity exists between the tenants’ CICD pipeline and the lower environments.
However, this is not a feature that is available for AEMaaCS infrastructure due to its requirement for holistic deployments. AEMaaCS does not allow individual tenant deployments as each deployment wipes out any previous deployments. Hence, it is an all-or-nothing deployment strategy.
For the higher environments, the approach remains the same as the previous one. Again, code quality scanning can be performed either by utilizing the customer’s managed SonarQube instance or utilizing Cloud Manager’s code quality pipelines along with Git webhooks.
The advantage of this approach is the faster availability of code changes in the lower environments without any dependency on other tenants or the aggregator project. Each tenant will build and deploy independently as expected with typical multi-tenant setups. However, as noted earlier, this is not available for AEMaaCS.
A leader in AEM as a Cloud Service Migrations. Learn More
Summary
As shown in this blog, there are different ways of deploying multiple tenants to AEM through Cloud Manager. They all rely on making a single aggregator project’s codebase available to Cloud Manager for deployment. Again, for a more detailed look at these approaches as well as a comparison of each one, please be on the lookout for my upcoming guide to Multi-Tenant AEM Deployment Strategies in Adobe Cloud Manager. Hope this will help serve your needs for deploying multiple tenants on your AEM platform through Cloud Manager.
