Handling Runmodes - AMS to AEMaaCS

[Cross_Leaf]

Hey folks,

I am working on a project migration in AEM from AMS to Cloud.

The AMS codebase has an awful lot of runmodes and runmode based configurations.

They have Dev, Dev1 to Dev6 - 7 DEV runmodes; 5 QA runmodes and more of Stage and Prod runmodes.

Currently they are using a sandbox program which has 1 RDE, 1 Dev, 1 Stage, 1 Prod environment configured.

We are targeting 1 Dev runmode to map to RDE; 1 QA to Dev, 1 Stage to Stage and 1 Prod to Prod config mapped.

Once the customer moves out of sandbox after testing the cloud environment - should we look at a way to reduce the runmodes defined in AMS or should we simply spin off more instances in Cloud for Dev?

They have separate instances for performance as well hence a whole lot of code written on basis of runmodes.

So couple of questions here -

1. Is RDE a valid runmode? Is it possible to map configs from one of the dev explicitly to RDE?

This query because RDE does deployment by aio plugin and isn't really deployment pipeline based.

2. The site is multi-tenant based. So we have multiple domains. Is it possible to set the hostname as an environment variable and then use it dynamically for each domain? Does RDE also allow domain setup?

3. For a large project with so many runmodes, what is the best way to simplify?

[daniel-strmecki]

Hi @Cross_Leaf,

my thoughts on this:

1) You should for sure look to reduce the number of runmodes. The decision if you need an additional environment should not be based on legacy code and legacy ways of working. In case you do have good reasons to add additional DEV environments and the client can afford it, then go for it. Some examples that make sense are: separate DEV and QA testing, have INT for integration testing where code from multiple teams gets merged and tested.

2) RDE is a valid run mode, so you can use the config.author.rde folder for example

3) Why would you set a hostname as an environment variable? You can have different domains that map to different content trees in AEM. Then you can use either Sling Mapping or Dispatcher to map different domains to the correct content.

4) I think that a lot of the stuff that is currently managed via runmodes will need refactoring and moving things to environment variables. Please keep in mind that is case you add additional DEV environments and use them as QA or INT, they will still only support the DEV runmode, so the only solution to differentiate their config is by using environment variables.

Hope this helps,

Daniel

[arunpatidar]

Hi @Cross_Leaf 
Please check following links, where 1st one allow you to setup your own runmode whereas second links obsolete that because In AEMaaCS env variable can be used instead of multiple/runmode config.

https://blog.developer.adobe.com/custom-runmodes-on-aem-as-a-cloud-service-79b757f51a6b 

https://medium.com/@achimkoch/dont-use-osgi-configs-in-aemaacs-18ed91053dee

[Tethich]

Hi@Cross_Leaf 

In addition to what have already been said, please also consider to put down on paper all the original reasons for which your project initially needed to have multiple runmodes. Could be technical reasons, could be business reasons. Either way, they should be revised. Then you will have two ways to go:

- See which ones can be dropped, communicate that to all parties involved and come to a common ground.

- See which ones still apply and make sense to keep and find a way to maintain the solution and behavior, as much as possible of course, in the context of AEMaaCS (which is entirely another beast). 

And always remember, Less is More !