Multi-tenancy and multi-team development in AEM
Unfortunately, one solution very rarely fits the needs of all tenants. This talk elaborates on necessary namespacing rules to isolate individual AEM tenants with their own code running on the same AEM server/in the same AEMaaCS program as well as some tooling to enforce that isolation (aem-content-package-namespace-validators).
In addition, it outlines some means on how multiple teams can develop on the same AEMaaCS program along with advantages/disadvantages. The shared resources which require some governance/alignment will be clarified. One side aspect is how to establish common code among multiple tenants (possibly even managed by different implementation teams).
Helge
How do you handle UAT ?
Konrad
Dedicated slots for individual business stakeholders on the preprod instance. Always with the option to revert to apply a hotfix.
Tomasz Sobczyk
If you were starting from scratch would you select for fullstack repo: 1. git sub modules or 2. mono repo with well designed maven modules
Masoud Rozati
Multi-tenancy comes with a bunch of process complexities, like: different release cycles, ad-hoc hotfix deployments and rollbacks, inter-dependencies (shared components between teams), CDN changes that need to be reviewed by all teams, etc. How is your experience with such issues? Do you still recommend having shared program for such setups?
Jörg
in your opionion: what is the most important aspect for the long-term success regarding such platforms?
Jörg
Would you recommend to look at Sling API Regions to separate tenant code?
Konrad
Yes, but unfortunately not yet supported by Adobe. The only way to deploy to AEMaaCS is via content packages.
Henry Kuijpers
How does the tooling know about whether something is a OSGi factory or not? Can custom OSGi factories also be configured?
Konrad
There a certain name pattern for factories: https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#applying-of-configurations. This applies to all kind of serialization. The FileVault validator has a dedicated SPI for treating OSGi configurations: https://github.com/apache/jackrabbit-filevault/blob/master/vault-validation/src/main/java/org/apache/jackrabbit/vault/validation/spi/OsgiConfigurationValidator.java
Tad
If multiple programs is an option from a licensing perspective, have you run into customers where doing content transfers between *programs* is a big limitation?
Konrad
Not yet. But I expect this to become an issue in the future if Adobe does not provide tooling.
Jörg
What are you experiences regarding the integration tests (as even the best tenant isolation has its limits as long as all that code shares a single JVM)? How do you handle the never-ending discussions about when to deploy and when not? (In my personal experience such a project is a big exercise in stakeholder management, and the technology is often much easier to change and fix than peoples' minds and egos ...)
Konrad
You have to accept the fact that you might run into regressions, but hopefully those can be fixed soon after you ran into those on production. You will never capture all issues with tooling, establishing a good review process and allowing frequent deployments usually makes this less of an issue.