what is a "Rapid Development Environments"

[TB3dock]

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/develo...

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

[nitesh_kumar]

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/develo... 

Also GEMS session for more details:-

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager-blogs/aem-gems-acceleratin... 

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/develo... 

https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/implementing/using-... 

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

[TB3dock]

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 · Accepted solution]

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/develo... 

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.

[vivekanand-mishra]

@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

[TB3dock]

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.

[TB3dock]

Ive just noticed one major show stopper - the content is lost on reset.  This means we cant easily reset the RDE env. Our content is more than 2GB, and there is no way to automate movement of content from one env to another.  Content syncing frequently times out and fails, so we have to create a number of smaller packages.  Getting exactly the right packages is difficult as there is no process or system to keep these in sync between envs.

[vivekanand-mishra]

Looks like you did not read the doc properly before use - [0]. That's what reset does.Content copy (Higher to lower env.) - feature is a possibility in near future. You may raise support ticket to enquire about it. Till then you have to rely on smaller packages.

Regarding "code quality pipeline" - Create a new "Non-Prod" pipeline, the first thing you see -select pipeline type: there you select "code quality pipeline". Costing- You need to reach to Support team.

[0]- https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/implementing/develo...

[TB3dock]

Thanks for the reply. If reset copies content from a higher env, can we specify which env it comes from (we have 5 non prod envs, so it would have to be a specific one, and adobe calls them all "dev"?

Docs say:

Upon creation, RDEs are set to the most recently available AEM version. An RDE reset, which can be performed using Cloud Manager, will cycle the RDE and set it to the most recently available AEM version.

Typically, an RDE would be used by a single developer at a given time, for testing and debugging a specific feature. When the development session is done, the RDE can be reset into a default state for the next usage.

It doesn't mention pulling content from another env?

I have read this doc several times:

https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/implementing/develo...

I cant see any mention of where it gets content from?

[vivekanand-mishra]

Kindly read my comments again- "Content copy (Higher to lower env.) - feature is a possibility in near future. You may raise support ticket to enquire about it."