AEM.Design is about identifying best practices and patterns that should be embedded and used a starting point for creating solutions for AEM. Our approach is to combine these best practices and patterns into the open source framework that can accelerate projects and provide a pathway for sharing knowledge with community in a consumable production ready framework. A lot of articles detail individual knowledge fragments that at times useful on their own but do not provide a clear direction for end use. We have tried to create a consolidated reference end-to-end approach with AEM.design framework and tools.
This initiative aims at collating best practices and patterns that are proven to be useful on projects. It’s aim to leverage best practices not only from AEM knowledge base, but also leverage best of the best from Front End, Automation Testing, DevOps and other related enablement tech. The aim of this initiative to provide a framework that can fit into existing solution practices without mandating a particular process.
All of the code is located in github, Docker Hub, SonarCloud and published to Maven central.
Best place to start with this framework is to try out the Docker Bundle that has the framework and demo of all of the components. You can find how to get started here: https://aem.design/blog/2019/08/30/docker-aem-bundle
Our archetype project is aimed to generate a new tenant project that has all of the components required to run AEM implementation project. It including automation tests, site showcase, frontend code implementation and component overrides tailored to you tenant name and project.
If you have any questions on particular issues you can raise issues in github for repos there are a few of them.
Creating and managing am environment for Multi-Tenants requires considerable upfront planning. Starting AEM project is easy and you can feel great sense of velocity early on. Although your initial velocity will make you feel comfortable, this might not last and avoiding future pitfalls is hard once you have released to production. To avoid pitfalls of the future means that you will need to be aware of some of the pitfalls you might encounter up front and this is very hard to convey and predict.
To protect projects from encountering technical pitfalls in the future it’s recommended to follow number of product best practices. Sheer number of best practices and patterns is overwhelming and it’s very hard for new entrants to appreciate all of the suggested practices. We found that establishing a set of goals and principles early on help to provide a project a pathway to success.
Technical patterns are easily avoided by leveraging frameworks that seek to embed knowledge into usable framework. Providing input into business processes is a more complicated endeavors due to the way project can be executed. From our experience teams need to aim to establish a common design language which is used to communicate requirements, and establish a efficient delivery processes that builds trust in the tools being used. This requires having open dialog at the start of the project to ensure everyone is on the same page and are willing to commit to trust automation process.
Following sections outline some of the elements of knowledge that should be kept in mind when establishing project for single site or multi tenant sites.
Be very transparent with whole team, every person needs to understand that they will all be required to login into AEM and use it, PMs and steak holders included, after all its their future digital platform. Everyone must to learn basic terminology of AEM and Design Language that will be used to describe requirements, this avoid confusion for everyone, and everyone should be encouraging peers to use correct language.
- Select primary Business Analyst to run project knowledge transfer, this will be you primary conduit
- Project team focus is primarily on Authoring Experience, as this what will enable authors to create the visual experiences they want
- Create a common Design Language to ensure designers and BA’s lead the conversation of explaining how designs are authored in AEM, not in some other external concepts
- Establish a religious training for all end users of AEM
- Create a showcase of you chosen components and walk everyone (including stake holders) thought it, showcase must be used for functional tests, so it’s not a throw away
- Establish a common knowledge repository for sharing knowledge while AEM project is running, use Confluence as it’s most accessible, do not treat this knowledge base as a dumping ground of notes, treat it like a knowledge book for the future. This space is for people to see what you have built not read endless meeting notes, all admin related content should not be primary focus for the space
- Establish a author training site that will be updated by Authors and BAs, this should be like any other tenant
- Delay all modification to core Authoring Experience, use YAGNI banner especially if everyone is new to AEM
- Component that appears in multiples experiences(pages) and show same data structure but different visual presentation are variant of same component.
- Focus on identifying Unique Experiences and Unique components Variants that make up those Unique Experiences.
- Ensure analytics is discussed as Definition of Ready for each component.
- Focus on content taxonomies to ensure content structure can scale from the start in DAM, Content Fragments, Experience Fragments, Tags, Forms and Site Pages. Each site should be in its own tenant folder with additional contextual segmentation that should apply for each type of content.
- Site Content must always be in Region/Language structure with primary Country and Language as default, essentially your site must be multi languish compatible from the start.
- Do not let Information Architecture dictate site Content Architecture
- All legacy SEO ideas and practices (anything that does not talk about micro data in page and components) should be tested using Functional Tests using the Build in AEM Hobes framework, this allows authors to test their content when they create it. If it can’t be automatically tested it’s not a requirement, it’s 2020 excuses don’t apply drop that requirement if it does.
- Acceptance Criteria and Acceptance tests must be part of Definition of Ready for DEV
- Automation testing is not optional and it’s the only way to verify Definition of Ready.
For single and Multi Tenant Projects consider that each site is a “tenant” not a sling workspace tenant but more of a virtual tenant used to segregate content from each site. This additional provides a method for security policies to be applied as users create content, as well as provide clean separation of content and application code if required, especially as you are working of a single component codebase.
- Create a showcase with you chosen components which is maintained Developers throughout development and Testers when helping to test
- Focus on Functional Automation Testing for all components with Authoring (does dialog work), Publishing (does it interact in publish) and Screenshot (does it look right) perspectives. Automation test suit is for the team not for selected few it does not have to be pretty is need to be quick to adopt and allow testing other web services, Selenium still works.
- Leverage Docker containers to ensure you are running consistent versions of services across all environments and especially Developers desktops, see Operations/Docker project
- Run AEM with Segment and Datastore separates from the start
- Leverage external ESB tool for API dev, eg ApacheNifi, try not to write API’s in AEM, external API tools can template/translate requests into direct Sling API request.
- Offload processing to Kubernetes container farm to leverage containers.
- Use overlays for each component per each site, as you will be using multiple framework eventually, this will allow you so substitute/update components in the future.
- Segregate each individual site content into “tenant” like silos
- Ensure Pipelines for build and deploy are established as soon as git and repos are created.
- Ensure dispatchers and present for Author and Publish instances
- Ensure that Frontend code is package as a stand-alone package and Page Client Libs are used to include in Templates, see Support/Compose module.
- Leverage VLT tool to export and backup content from prod and import into Development environments as required, packages don’t work for large content farms
- Leverage Ansible to persists logic for environment configuration, see Operations/Deploy and Operations/Ansible-Roles project.
- Ensure dispatcher config is in code and in a Docker container, see Docker-Dispatcher repo
- Do not allow manual modification of services/servers via console etc follow Configuration as Code for all infrastructure and services, especially servers, preferably run Centos Atomic edition which will force Docker usage, see Operations/VM project for how to generate Centos Atomic VMs appliances.
- Leverage Content Fragments for structured content, use templated component to present that content.
- Leverage Experience Fragments for building reusable Page Sections.
- Do not build footer and header as massive components, instead create experience fragments and add them to Site Root page and inherit it thought the tree.
- Ensure Analytics content can be updated by authors
- Use Data Layer spec to output analytics content in page header
- Use Data Layer spec to manage all fields that will be output by components and use for analytics
- Ensure each component has a unique ID attribute
- Ensure each component you output is easily distinguishable from other stuff AEM adds, AEM.Design uses Boolean attribute “component”
- Use lists for re-using content for presentation, look at Generic Details and List components for reference, they provide dynamic field specific templating and expose of component content without dumping all of the content on the page. Hiding 48 out of 50 fields of a component content is poor design, output only content you need, see Component Variant and List Badge patterns.
- Separate config into separate package and use run-modes
- Separate authoring experience updates into separate package
- Use ACS commons tools and check them before you build new components.
- When using components from frameworks consider impact on authoring experience, different frameworks have different authoring possibilities, with some making authoring very Front End heavy without enabling Authors.
This is a short list and can be use a starting point.
As always if you think of things to be added to the list let us know by leaving a comment or better yet raise an issue in the repo.
Share this on your favorite network if you find this useful.