can one deploy to cloud AEM via packages, instead of building which takes too long? | Community
Skip to main content
N
nutmix2
Level 2
September 2, 2021
Solved

can one deploy to cloud AEM via packages, instead of building which takes too long?

  • September 2, 2021
  • 4 replies
  • 1585 views

It takes 1 hour+ for the Adobe build process to build and deploy to a cloud env.  This means a simple fix takes many hours, as first we have to build and test on dev, then build and test on UAT, then build on stage, then live.

 

Thats 4+ hours just building duplicate code.

 

And that is if Adobe Build system is working. We get builds failing due to environment hosting issues on a weekly basis, and adobe take weeks or months to respond and fix them, taking out our deployment process and production changes with it.

 

Can we instead build on say dev, and deploy to UAT using a code package? Adobe say this doesnt work, but it would be much faster, and also much more reliable.

 

 

 

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 Lokesh_Shivalingaiah

As per the process enveloping governance and security and to adhere to the CI/CD process, we cannot deploy any changes using packages.

If it takes longer time to build the package, please look into your project repository structure and see how it can be optimized.

4 replies

Kishore_Kumar_
Kishore_Kumar_
Level 9
September 2, 2021

Hi @nutmix2 ,

 

I don't think you can. It has to be deployed via pipeline. If you try to install immutable contents via package manager it will throw an issue.

    Asutosh_Jena_
    Community Advisor
    Asutosh_Jena_Community Advisor
    Community Advisor
    September 2, 2021

    Hi @nutmix2 

     

    As per Adobe documentation; All content and code persisted in the immutable repository must be checked into git and deployed through Cloud Manager. In other words, unlike current AEM solutions, code is never deployed directly to a running AEM instance. This ensures that the code running for a given release in any Cloud environment is identical, which eliminates the risk of unintentional code variation on production. As an example, OSGI configuration should be committed to source control rather than managed at runtime via the AEM web console’s configuration manager.

     

    So all the deployment has to go through the Pipeline deployment.

     

    https://experienceleague.adobe.com/docs/experience-manager-cloud-service/implementing/deploying/overview.html?lang=en

     

    Thanks!

      Lokesh_Shivalingaiah
      Lokesh_ShivalingaiahAccepted solution
      Level 10
      September 2, 2021

      As per the process enveloping governance and security and to adhere to the CI/CD process, we cannot deploy any changes using packages.

      If it takes longer time to build the package, please look into your project repository structure and see how it can be optimized.

        T
        TB3dock
        Level 8
        September 6, 2021

        The 1 hour build time per env, resulting in a minimum 3 hours to go from dev to prod just in build time for a one line hotfix, is not acceptable.  With episerver, we could build on stage, then push the package between stage and prod without rebuilding for prod, which would be pointless.  Also builds took minutes vs hours. From a governance and security point of view, it would be far better to be able to push a tested package from say test to stage to prod, vs. building a potentially different one on each, with the associated unacceptable build times.  We have no idea how we could optimise for build time, other than to remove functionality, which is not an option.

        The simple outcome of this unworkable system is that if it takes 4+ hours to put a critical hotfix live, due to the slow build times, we will have to make changes directly to the production branch, and push it into production without any testing.  We cannot afford to have our site down for 4 hours to make a one line change in a P1 production emergency.  4 hours = hundreds of thousands in lost revenue.   With episerver we were able to write, build, test and deploy hotfixes within 1-2 hours, with full due diligence and due process.  Luckily we only had to do this rarely (e.g. if a exploit was found, or a provider failed unpredictably).

        If we add a more likely case, were we have to build on dev several times before we are ready to push a hotfix, then it could be 6-8 hours due to taking 1 hour each time.   Building and testing locally is often ineffective as the local env is so different from the cloud env.

        Add on to this the problem that the build on any env (including dev and prod) randomly fail due to Adobe issues (e.g. kubernetes issue), and we have to ask Adobe to fix, and adobe take anything from 1 week to 2 months to fix broken environments, and its a real concern.

          arunpatidar
          Community Advisor
          arunpatidarCommunity Advisor
          Community Advisor
          September 5, 2021

          Hi,

          Yes, Adobe is right , it does not work. When your package contains /apps and /libs, package install will failed because /apps and /libs are immuntable.

          Arun Patidar
            Terms & ConditionsAccessibility statement

            Loading footer...