what is a "Rapid Development Environments" | Community
Skip to main content
T
TB3dock
Level 8
March 6, 2023
Solved

what is a "Rapid Development Environments"

  • March 6, 2023
  • 2 replies
  • 3272 views

We just noticed this feature in the cloud manager.

 

AEM Cloud is difficult to develop against because you have to build on every environment (we have 5 non prod envs), and each build takes anything from 2 to 48 hours if we have to restart it several times.

 

Very long cloud build and deployment times, coupled with

1) having to rebuild for every env ( as opposed to simply copying the built artifact to the new env), 

2) local cloud SDK being very different from cloud env.

3) when a dev needs to test something experimental, he has to deploy it to an env, which may be in use by other devs.  We use slack to try to arbitrage this, plus paying for a lot of non prod envs.

4) because the build times are so slow, we try to avoid putting tests in the pipeline. We run these manually.  This leads to more build issues.

 

Lead to long turn around times for simple changes.

 

We notice there is something called Rapid Development Environment.  It seems to require command line tools to be installed, and gets deleted.  What is it, and how could we use it?

 

WE only get one RDE, which would appear to be useless (as we have around 20 devs)

 

Ive read this page: 

 

https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/implementing/developing/rapid-development-environments.html?lang=en

 

But I am still unclear what this is, and how it differs from our normal envs (which dont require command line tools etc).

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 nitesh_kumar-1

There are some minor architectural differences when it comes to RDE,  FYI your question has been answered on the same documentation page which I mentioned before. https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/implementing/developing/rapid-development-environments.html?lang=en#how-are-rds-different-from-cloud-development-environments 

 

RDE would sync code from the local machine, making it easier and faster to debug. It's more for developers. while the cloud programs (Non-prod or prod) are meant to test full-fledged applications after the deployment, some customers even use it for QA which is why it is necessary to execute the steps and keep it clean.

 

Local SDKs and RDE should be sufficient to cover the regular use cases of development practices. Treating the Dev environment as local doesn't make sense, since you have the option to skip the test on your local and RDE, that's one of the reasons.

2 replies

nitesh_kumar-1
Adobe Employee
nitesh_kumar-1Adobe Employee
Adobe Employee
March 6, 2023

Hi @tb3dock ,

 

RDEs allow developers to swiftly deploy and review changes, minimizing the amount of time needed to test features that are proven to work in a local development environment.

 

You can have more than one RDE for environments, however, there are licensing costs involved, do check the documentation here

RDEs allow developers to swiftly deploy and review changes, minimizing the amount of time needed to test features that are proven to work in a local development environment. 

https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/implementing/developing/rapid-development-environments.html?lang=en#how-many-rds-do-i-need 

 

Also GEMS session for more details:-

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager-blogs/aem-gems-accelerating-experience-manager-as-a-cloud-service/ba-p/570615#M712 

 

 

You also mentioned long build duration, you can check the possibility of your project can make use of web-tier and front-end pipelines, which are relatively faster than Full stack. 

https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/implementing/developing/developing-with-front-end-pipelines.html?lang=en 

https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/implementing/using-cloud-manager/cicd-pipelines/configuring-production-pipelines.html?lang=en#web-tier-config 

 

Note: Build time is also dependent on the code base, so a project might build faster than others.

 

Hope that helps!

 

Let me know if you have further questions.

 

Regards,

Nitesh

    T
    TB3dockAuthor
    Level 8
    March 6, 2023

    Thanks for the reply.  Really, im trying to figure out what the difference is between a normal non prod AEM env, and the RDE one.  Are they exactly the same, other than one doest execute the tests in the AEM pipeline?  Why would Adobe not just give us the option to skip tests, thereby making any non prod env a RDE env?  

      nitesh_kumar-1
      Adobe Employee
      nitesh_kumar-1Adobe EmployeeAccepted solution
      Adobe Employee
      March 6, 2023

      There are some minor architectural differences when it comes to RDE,  FYI your question has been answered on the same documentation page which I mentioned before. https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/implementing/developing/rapid-development-environments.html?lang=en#how-are-rds-different-from-cloud-development-environments 

       

      RDE would sync code from the local machine, making it easier and faster to debug. It's more for developers. while the cloud programs (Non-prod or prod) are meant to test full-fledged applications after the deployment, some customers even use it for QA which is why it is necessary to execute the steps and keep it clean.

       

      Local SDKs and RDE should be sufficient to cover the regular use cases of development practices. Treating the Dev environment as local doesn't make sense, since you have the option to skip the test on your local and RDE, that's one of the reasons.

        V
        Adobe Employee
        vivekanand-mishAdobe Employee
        Adobe Employee
        March 7, 2023

        @tb3dock I'm surprised to see your experience about AEM Cloud. My experience has been opposite. I suggest you to reach-out to your Adobe POC for project health check. Also, I recommend cloud service training to your DEVs. Might be possible that you have migrated from an older version of AEM without proper code optimisation needed for AEM to run as Cloud Service. The numbers you shared are hard for any DEV team to work with. Please find my comments inline-

         

        AEM Cloud is difficult to develop against because you have to build on every environment (we have 5 non prod envs), and each build takes anything from 2 to 48 hours if we have to restart it several times.

        - Do RCA why build takes 2 hrs - find out/ rework costly operations in build, Why you need 5 non-PROD and Why you need restart several times

        Very long cloud build and deployment times, coupled with

        - Take advantage from new build options which provide decoupling of build: FE/ Dispatcher pipelines, RDE, npm caching, Content/ Code separation/ Repo-init etc.

        1) having to rebuild for every env ( as opposed to simply copying the built artifact to the new env), 

        - AEM runs as a service now, so no instance concept. Moving to scaling model has some costs to do away with old ways of doing things. 

        2) local cloud SDK being very different from cloud env.

        - Thats where RDE pitches in.

        3) when a dev needs to test something experimental, he has to deploy it to an env, which may be in use by other devs.  We use slack to try to arbitrage this, plus paying for a lot of non prod envs.

        - Use RDEs. You can have 3-4 RDEs that can be used by DEVs in turn.

        4) because the build times are so slow, we try to avoid putting tests in the pipeline. We run these manually.  This leads to more build issues. 

        - Use quality pipeline for Tests. Optimize your build steps and Skip anything not needed

         

          T
          TB3dockAuthor
          Level 8
          March 7, 2023

          Thanks for the reply.  very informative.  We pay for premium support from adobe and pay millions per year, but we don't have anyone at adobe we can contact. The best we have is to raise a ticket on the admin console and wait some weeks for a reply, so we rarely use it.

           

          I saw recently that we can separate the dispatcher from the build, but this wont save significant time unfortunately. We always are changing both front and backend, so separating these would be pointless.  What is the quality pipeline?  haven't seen this option.

           

          Any idea how much a RDE instance costs?  we have 5 Non prod instances because we have a dev one which builds ever change (so every 2 hours), a QA one where UAT happens on a release candidate, and 3 "spare" envs which devs deploy to to tests specific branches or features.  Depending on how hard DREs are to use and how much they cost, we could switch to using these.

           

           

           

            Terms & ConditionsAccessibility statement

            Loading footer...