Building Internally, Pulling From Private Repository & Deploying via Cloud Manager to AEM as CloudService or AMS Managed environment | Community
Skip to main content
M
mmange
Level 2
March 5, 2021
Solved

Building Internally, Pulling From Private Repository & Deploying via Cloud Manager to AEM as CloudService or AMS Managed environment

  • March 5, 2021
  • 2 replies
  • 2517 views

We have recently implemented the below successfully with our partner sandbox AEM as a Cloud Service environment

 

 

1. Built project A & B with internal jenkins & deployed them to our internal nexus

2. Created a new wrapper project C with an all package only which embeds project A & B's all artifacts

3. Sync'd only the project C repo with Cloud Manager repo - do a build

 

We were able to successfully deploy project A & B onto AEM in the cloud w/o ever having to commit the code for Project A & B into Cloud Manager git repo. This is game changing because this allows customers to maintain their multiple repositories and, existing build processes and still leverage cloud manager pipeline to build and deploy their privately built artifacts to AEM. 

 

The project C All pom screenshot below. 

 

 

 

My question - is this allowed in real world customer AMS environments? Given the code for Project A & Project B was never sync'd to Cloud Manager git repo it isn't scanned for security etc. so I am wondering if Adobe AMS or Cloud Manager allows this in real world production customer environments? Is anyone out there doing something like this? 

 

I would like to recommend this and use this approach where it's not possible for merge multiple tenant repo's into a single repo or need to install legacy AEM projects / packages but, not sure what's Adobe / AMS official position on this. 

 

Thanks in advance for sharing any tips / pointers / recommendations.  

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by joerghoh

With CloudManager and AMS it's most likely working well, because there you have much more active control over the AEM itself; especially you collaborate with the CME regarding product updates, service packs and such.

 

With AEM as a Cloud Service the siituation is different; and while technically it still might be possible to do so, the system cannot guarantee that your artifacts, which are compiled on your own systems against some version of the AEM API, will deploy correctly on AEM as a Cloud Service. This also prevents Adobe from making well informed decisions about API changes, because if you are using some rarely used API, Adobe cannot know that.

 

Another more operational topic is that you include a deployment dependency into the build, which you control. Meaning that the build can break anytime if your infrastructure (Nexus/Artifactory) is not available.

2 replies

Pawan-Gupta
Pawan-Gupta
Level 8
March 5, 2021

Hello,

 

first of all thanks for sharing that you were successfully able to deploy your local git repo via using cloud pipeline.

 

now, as per my understanding the deployment workspace will be created based on GIT repo so in your case the project C git repo will be treated as separate workspace then to your project a & b. and i am not sure if will be possible to refer projects from different repo on cloud for build

 

thanks. 

    M
    mmangeAuthor
    Level 2
    March 5, 2021

    Hi Pawan,

     

    Thanks for your message. We have the above already working, so the question is not if we are able to refer projects from different repo.

     

    The questions is we are some what circumventing security/code scanning of repo A & repo B so is that an issue with AMS or AEM as a cloud service. 

    joerghoh
    Adobe Employee
    joerghohAdobe EmployeeAccepted solution
    Adobe Employee
    March 7, 2021

    With CloudManager and AMS it's most likely working well, because there you have much more active control over the AEM itself; especially you collaborate with the CME regarding product updates, service packs and such.

     

    With AEM as a Cloud Service the siituation is different; and while technically it still might be possible to do so, the system cannot guarantee that your artifacts, which are compiled on your own systems against some version of the AEM API, will deploy correctly on AEM as a Cloud Service. This also prevents Adobe from making well informed decisions about API changes, because if you are using some rarely used API, Adobe cannot know that.

     

    Another more operational topic is that you include a deployment dependency into the build, which you control. Meaning that the build can break anytime if your infrastructure (Nexus/Artifactory) is not available.

      M
      mmangeAuthor
      Level 2
      March 9, 2021

      Hi, 

       

      Ok, so for AMS based customers you think this approach is ok to recommend? 

       

      For the AEM as a cloud services, yes completely understand the caveats you've outlined. 

      Terms & ConditionsAccessibility statement

      Loading footer...