Runmode migration - AMS to AEM Cloud | Community
Skip to main content
NageshRaja
Level 5
October 30, 2024
Solved

Runmode migration - AMS to AEM Cloud

  • October 30, 2024
  • 5 replies
  • 2420 views

Hi Guys,

 

I have the below problem statement -

"The AMS Environment has runmodes for dev (1 to 6), stage (1 to 4), qa (1 to 3), performance (1), integration (1) and production (1). All these environments have their runmode configurations". These environments are used by multiple business teams spread out geographically and divided along business units.

We need to find a mechanism to retain all these runmodes on AEM Cloud - The least viable option being we add 10 dev environments and tying each environment to one runmode in AMS which even then would be tricky as the runmode for instance config.author.dev6 and config.author.dev5 in AMS would still have to be put under config.author.dev in AEM Cloud.

 

Thanks in advance,

CL

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 Rohan_Garg

I have sent you the configs on chat @rohan_garg for your reference


Hey @nageshraja, Had a chance to review your configs.

Let me break it down for others on the forum too. Here's the sample configuration - 

{
"a": "/x/dev2/y/x",
"b": "/abc/dev2/x/y",
"c": "/x/dev2/a/b",
"d": "/x/dev2/a/y"
}

 

Instead of converting the entire values for keys (a,b,c and d) - you want to just set one environment variable for dev2. 

In your case the source system for REST API endpoint is Hybris where the endpoints for multiple environments are still same only the /dev2, /dev3 will change.

You can set an EnvironmentID variable which will replace the config as below - 

{
"a": "/x/$[env:API_ENV;default=dev2/y/x",
"b": "/abc/$[env:API_ENV;default=dev2/x/y",
"c": "/x/$[env:API_ENV;default=dev2/a/b",
"d": "/x/$[env:API_ENV;default=dev2/a/y"
}

 

This will replace your previously 4 environment variables with just 1.

And as @daniel-strmecki mentioned, you probably should not be using so many environment variables.

 

Hope this helps!

Rohan Garg

5 replies

NageshRaja
Level 5
October 30, 2024

@arunpatidar- Do you think that previous ID based approach can work for this use case?

narendiran_ravi
Level 6
October 30, 2024

Hi @nageshraja ,

 

In AEM as a Cloud Service (AEMaaCS), we have only the dev, stage, prod, and rde runmodes are available - https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/deploying/overview#runmodes . Configuration can be set under the dev runmode, with environment variables used to distinguish between different dev instances.

 

  1.  Define base configurations in config.dev, and adjust instance-specific values through environment variables in Cloud Manager 
NageshRaja
Level 5
November 1, 2024

Hi @narendiran_ravi,

Is there no other way to logically separate my dev3 and dev4 instances other than environment variables?

Because each instance has 100s of configurations which are uniquely different it will be messy to have them under environment variables with no source control to track the values being changed.

narendiran_ravi
Level 6
November 4, 2024

Hi @nageshraja ,

Yes, managing numerous environment variables can be challenging. I recommend:

  • Create a JSON file in your code repository for each environment to store these variables.
  • Use the Cloud Manager API to add or update environment variables programmatically.

Refer to the Cloud Manager API documentation for details on updating environment variables.

Tethich
Community Advisor
Community Advisor
October 30, 2024

Hi @nageshraja 

I believe you will find your answers in some previous thread opened on similar topic: https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/handling-runmodes-ams-to-aemaacs/m-p/714886

 

To sum up:
In AEMaaCS you only have Dev, RDE, Stage, Prod.

You can spin off multiple Dev envs and use them as QA, INT or whatever. Usually are those couple two.

And if you need a logic to distinguish them by something you still name "runmode", you need to leverage the environment variables to make a logical difference between them and accommodate your solution/code to work with those.

NageshRaja
Level 5
November 1, 2024

Hi @tethich, thanks for your reply but the problem with using environment variables is they can't be tracked in git history and then secondly I have 100's of configuration which differ my dev3 and dev4 environment for instance. Replacing these with environment variables will make them not easy to manage.

 

NageshRaja
Level 5
November 7, 2024

any insights into how to handle 200+ environment variables in runmodes for a particular environment? 

@estebanbustamante@daniel-strmecki @arunpatidar @sureshdhulipudi @rohan_garg 

EstebanBustamante
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
November 7, 2024

Your best option is to open a support case with Adobe and explain your use case. They may be able to help you with the limit. Sorry, I didn't fully read all the responses, but IMHO it is clear that a redesign needs to happen. You cannot simply 'lift and shift'; there are business strategies that need to be aligned with AEMaaCS.

Esteban Bustamante
kautuk_sahni
Community Manager
Community Manager
November 11, 2024

@nageshraja Did you find the suggestions helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!

Kautuk Sahni