AEM multi tenancy Production Deployment

[george6]

Hi Team,
We have 3 AEM projects (Different Vendors doing development) and we are planning multi -tenancy approach, since we have only one Program in our AEMasCS.

We will be creating the project structure as a multi-module project in our private repo with each of the 3 projects as child of main project as shown below.

Lets call this repo : Client Repo 1

   /AEM Multi project

         -/Tenant 1

         -/Tenant 2

         -/Tenant 3

         -/Dispatcher 

         -/POM (Parent Pom) 

Can each  Tenants developers  raise PR to  Client Repo 1?   Is this the best approach. 

For eg: Tenant 1 Developer can only push code to the Tenant 1 section of  Client Repo 1    

Here the automated deployment which we configure will do deployment if one of the tenant developer commit a change (lower environment) 

So in lower environment we can push the whole  AEM Multi project, But when it comes to Production , How to push specifically one project, with out interfering other projects. (Since all the three projects are in production and changes are only to one project) 

How to push only one Tenant code to adobe git master - (I have seen that the image will delete other code base during the deployment) 

What will be the effective Rollback Mechanisms we should consider  in case of multi tenant development.

I didn't find specific documentation on prod deployment (Pipeline configs) on multi tenancy , if anyone can share some insight it would be great.

Thanks,

Geo

[Love_Sharma]

Hi,

All questions you asked are project specific and what every vendor agrees on. So I would say there is no standard for such approaches but I am sharing my experience which I implemented as an Architect and worked well with some highs and lows.

Assuming all three vendors implementing three different sites where Site A may be a parent site and B and C are sub domains under parent sites. 

1) You can create project structure like you mentioned OR you could create a single project structure and do naming conventions of packages as per site domain. For eg 

/AEM project

         -com.cms.projectname.domainA.models - Vendor A will create their specific models here

         -com.cms.projectname.domainB.models - Vendor B will create their specific models here

         -com.cms.projectname.domainC.models - Vendor C will create their specific models here

         -/Dispatcher 

         -/POM (Parent Pom) 

Just like models package, you can create package for services, impl, constants etc.

2) Can each  Tenants developers  raise PR to  Client Repo 1?   For this question, may be try something like creating three different vendor specific branches from Master/Main branch

main-branch

     -- vendor-a (Merge latest changes from Main branch periodically)

         -- Create Feature branches from vendor-a branch and raise PR against your vendor-a branch

     -- vendor-b (Merge latest changes from Main branch periodically)

         --Create Feature branches from vendor-b branch and raise PR against your vendor-b branch

     -- vendor-c (Merge latest changes from Main branch periodically)

         --Create Feature branches from vendor-c branch and raise PR against your vendor-c branch

Merge your PR into your vendor specific branches and deploy to DEV and QA for testing.

After testing is completed on QA, you could merge your vendor branch into main and deploy to stage with agreement with other vendor in sequence

3) For Lower environments - I think better approach will be to have different DEV and QA environments for all three vendors. Trigger deployment after all PRs for that sprint are merged in Vendor specific branches. Test your code on DEV and get sign off from QA on QA envrn. 

Note: If you merge latest main branch changes every sprint or so into your vendor branch, on dev and QA when you are testing, you also have other vendor's code. So it will be kind of integration/regression testing that you are not breaking anything for them or vice versa

4) On Stage environments - All vendors can communicate within as per project need and plan there merge into main branch sequentially. For eg-

vendor A merges to main and deploy code to stage. Stage can be freeze for that time until they complete their testing.

After that vendor B merges to main and do the same. At this time, Vendor A has to perform regression. And repeat for Vendor C

I hope this helps in some way.

Best of Luck

[george6]

Hi @Love_Sharma ,

Thanks for the response.
We are in AEMasCS.
In Our scenario three entirely different websites and it is  developed by  different vendors.

And each vendor should NOT access others Code, Config, Content (edit/Modify)

And we have only One program in AEMasCS so basically only one DEV, STAGE and PROD.

So in apps it should be like

/apps/Customer/project1components

/apps/Customer/project2components

/apps/Customer/project3components

/conf/project1/configs

/conf/project2/configs

/conf/project3/configs

/content/project1/

/content/project2/

/content/project3/

So the code of each project (vendor) should be added inside a parent reactor project (as mentioned in initial diagram)

I need some understanding on the best approach on  PR raising in the customer repository 
From feature branch to develop branch where the reactor project is defined , and from there complete code should get deployed to dev environment.?

Then to stage and production since there is only one pipeline , can we push all the project code together to STAGE or separately?
How to plan the prod deployment specifically only one project code and dispatcher changes ? How the cutover should plan?

I did not see relevant documentation on this 

@arunpatidar 

@aanchal-sikka 

EstebanBustamante
@Albin_Issac 
 
Thanks,
Geo

[aanchal-sikka]

Hello @george6 

In general for large organizations with multi-tenant, they have separate code repositories for each tenant and dispatcher.

These separate dedicated repos are used for development and PR reviews.

Next, they have scripts that would merge these individual repos into common repo before pushing them to AEMaaCS Cloud manager. The common-repo looks like the one you shared.

Can we deploy individual repos to AEMaaCS? No... When a pipeline is built only mutable areas like /content /etc /var /conf etc are retained. /apps for example is built with OOTB code + the  latest codebase. Thus, you would loose tenant 2,3 ... when you deploy only tenant1

[george6]

Thanks, @aanchal-sikka ,
Regarding the last paragraph, in DEV environment, also we wont be able to to get all the tenants code ,We need all the tenants code ,config,and content in lower environment for testing 

In Prod If the apps will get overwritten in prod then suppose already tenant 1 got deployed and next week suppose tenant 2 code is planning to deploy   to prod, then how the tenant 1 website can be accessed (if apps got overwritten )

/apps/project1/comp
/apps/project2/comp

apps/project3/comp

If we create three sections then can we deploy the code change only specific to a folder ?

[aanchal-sikka]

@george6 

Please refer to the documents shared by @Rohan_Garg . They cover it really well

[arunpatidar]

Hi @george6 

To support multi-tenant project deployments in an AEM environment using Maven and Adobe Cloud Manager, you can adopt an artifact-only approach. Here's how you can streamline the process:

Each vendor opens a Pull Request (PR) and merges code into the master branch of their respective repositories (e.g., GitHub or Bitbucket).
After code is merged into the master branch, a Jenkins pipeline is triggered. This pipeline will:

• Build the project using mvn clean install.
• Generate the necessary artifacts/packages for the project.
• Upload these packages to an artifact repository (e.g., Artifactory).

Adobe Cloud Manager Integration:

In the Adobe Cloud Manager Git repository, include the generated artifacts as dependencies for embedding or as subpackages. For example, the all.pom file will include modules or external dependencies.

Dispatcher Configuration:

Use a common repository for dispatcher-related changes. This ensures that all tenants share the same dispatcher configurations and any updates or changes are consistently applied across all environments.

This approach allows each vendor to manage their code and artifacts independently while ensuring a streamlined and consistent deployment process in Adobe Cloud Manager. It supports multi-tenant deployments efficiently, leveraging shared configurations and centralized artifact management.

[Rohan_Garg · Accepted solution]

Hi @george6, 

There is an excellent blog on this - please refer Multi Tenancy with Adobe Cloud Manager

It talks about 3 deployment models - 

• Model 1 - Using Multiple Repositories
  Here Adobe explains how we can sync customer managed Git repositories with CM repos by making use of Git actions and CI jobs.
• Model 2 - Shared Repository Managers
• Model 3 - Git submodules - Refer Managing Repositories in Cloud Manager

You can also refer Understanding Multitenancy and Concurrent Development

Hope this helps!