Feature Toggling in AEM

[mark_mcintyre]

As our team migrates toward a Continuous Delivery model (wherein we deploy our continuous integration branch to production several times a day), we find ourselves pushing code for features that pass all of our tests and criteria, but still aren't quite ready for prime time. 

As a simple example, let's say we're working on a new component, and we're half-way through its development. The code for this component will be pushed live to production as part of our continuous integration / continuous delivery strategy, but we don't actually want the component to appear in the AEM sidekick on the production environment yet because it's not 100% finished. (It should be available on the development environments for engineers to test and develop, however.) In this sense, we'd like the visibility of this component to depend on the environment configuration using the same code base.

Another example: We may make a modification to an existing component which includes adding a new dialog tab to it, but we don't want to expose this new tab on production just yet.

For those of you who are also using a CD strategy, how did you approach this requirement in AEM without resorting to separate feature branches (which we would very much like to avoid) or different compiled packages for different environments? Is it possible to define different JCR content packages for different environments within the same codebase?

[Jörg_Hoh · Accepted solution]

Hi,

with components it's a bit hard, as they just need to have the right nodetype (cq:Component). What you could do is the add them to the special group ".hidden" untill they are ready. When components are in this group, they don't show up on the sidekick, but are usable. That could work. But IIRC it's not possible to make components available based on runmode (which would be a quite easy way to implement feature flags). With templates you probably have to play with the allowedPaths property.

In code it's much easier, as long as you have special runmodes for local development, testing environments and production systems. You can build a config property "enabled" or just have a component which is only working of a config is present

@component(policy=required)

Does this help?

kind regards,
Jörg

[mark_mcintyre]

Thanks, Jörg.

I suspected that this capability wasn't available, but thank you for verifying! (This would actually make a nice feature request for future AEM releases.)

Since our publishers don't actually have design-mode access, we may simply exclude new components from our templates' parsys until they're ready and just have the engineers add them to the sidekick manually in design mode for testing purposes.

I like the idea of using allowedPaths to control the exposure of templates.

Dialog changes are probably our most difficult problem here. We may need to develop in a duplicate, hidden component until all of the changes are ready and validated before replacing the older in-use version.

At any rate, thanks again for your reply!

Cheers,

Mark

[Jörg_Hoh]

Hi Mark,

well, I haven't thogught of the design mode, that's a good solution too.

The dialog thing is a tricky one. I haven't used it and also don't know if it's possible, but you might play around a bit with the resource merger [1]. If you add a path /dev as a 3rd search path (check the correct priority of the paths) to your resource resolver, you can overlay your own components. And if you give only developers the permissions to read from there, it could work. I haven't thought through all cases, but it might be worth a try.

In case you give it a try, please report back here. I would be interested in the result too :-)

kind regards,
Jörg

[1] https://docs.adobe.com/docs/en/aem/6-0/develop/platform/overlays.html