A lot of us in the AEM developer community depended on custom runmodes to control custom code behavior, whether it’s via an OSGi config to activate a certain piece of code or via the getRunModes method of the SlingSettings class.
For the most part, using custom runmodes was considered best practice, but, all of us including myself are also guilty of using them incorrectly.
With AEM as a Cloud Service and following the 12 factor app methodology, custom runmodes are a slowly becoming a thing of the past.
In AEM as a Cloud Service, only a certain set of runmodes and a certain naming convention for your config directories are supported. Read the docs for more details.
Now to see how you can migrate custom runmodes usage to AEM as a Cloud Service. Starting with the easier one.
Custom runmodes in configurations
There are two possible incompatibilities here
1. Incorrect naming convention — config.(dev|stage|prod).(author|publish)
2. Unsupported runmodes — config.!(dev|stage|prod)
Custom runmodes in code
This happens to be one of the ways we have all abused runmodes in AEM. As always, starting with the good news.
If you check runmode in code using the getRunModes method, but, only check for author or publish, you don’t have to do anything.
If you use it to check any other runmode, including dev, stage and prod, there are some changes needed to ensure your application continues to work. In AEM as a Cloud Service, the getRunModes will only return author or publish because dev, stage and prod are technically not run modes, but, environment types.