AEM as a cloud service - How to manage builds of dependent or common code in a separate repo?

[#1]

I have got a repo of all common components which are deployed to multiple brand websites . If I have to migrate this to AEM cloud service then I will create a single brand project based on the new AEM archetype. But then I also need to embed the common components package with the brand package. The pipeline in cloud manager can be setup to deploy the brand package(and embedded packages). Can I create a separate pipeline in cloud manager for common repo as well so that I can make sure that all quality gates are passed for common components ? Just trying to figure out what is the best way to setup CM pipelines in this scenario.

[kunal23]

@kunal23  With AEM cloud service, it is expected to deploy all the code together since a new image is created with every deployment. This is further clarified here: https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/profile-builds-with-cloud-...

Though in this use case where you want to do a separate build to validate the quality of common code/ components, you can create a Non-Prod "Code Quality" pipeline (not a deployment pipeline) to run unit tests and evaluate code quality. This common code can reside in a separate branch and a new code quality (non-prod) pipeline can be configured with this branch and an appropriate trigger.

[kunal23]

Hi @shelly-goel

Thanks for your inputs.  As I said, I have got multiple brand AEM code repos and a shared common components repo. Each brand will have its own code as well and it will be deployed to a program and in Cloud Service. The common repo code will be included as sub package in the brand package. I can not have common code in a separate branch in this scenario since every brand will have its own independent repo so this will not work. Also, the common code is completely divergent from the brand repo code.

As per Adobe a single program in cloud can have just one single git repository. So in this case I have got only two options-

- I use custom Jenkins CI pipeline for code quality checks for common repo.

- Or else I create a separate program and create new pipeline for compiling the commons component package. I can trigger this common component pipeline via my Jenkins pipeline and if the build in CM is successful then I can trigger the main brand project pipeline.  But the only drawback is that I will have to create a separate program in cloud service just to create a separate pipeline.

[shelly-goel]

Okay, where (which repo) do you plan to keep the common code to build and package as I understand it cannot be together with the brand's code? Unless I'm missing out on something here, common code is going to be checked-in or version-controlled in some repo which can be either organization's git repo or Adobe git repo. Custom jenkins pipeline would be useful if common repo is in org git repo. Else if you're planning to keep common code in Adobe git repo then a separate Program/ git repo would anyways be required.

[kunal23]

Both the common code and brand repos will be managed in org git repos. We plan to sync these repos with Adobe GIT repos via custom Jenkins Pipeline. You can consider common code just like core components library and it lives in its own repo as it is maintained independently of brands code. Every brand gets this library as a separate package installation just like core components.

[shelly-goel]

That was my initial understanding that you would be keeping the common code in separate org git repo though I assumed you would sync it to a folder in brands' adobe git repo. In this case when it is not synced to brand's repo, I'm assuming you would upload common code (jar & zip) to a maven repository and add it's dependency.