Best Practices: Project Organization & Managing Changes

[markj1644785]

I have a question for the community regarding best practices for handling project organization, changes and regression.

Project organization

1. Is it more common for clients to have their sites built out into separate projects that share jar or .class files across them, or to have the sites as subprojects of the main project?
   1. What are the pros/cons of each approach?
   2. Have you seen any examples of this type of configuration done in Gradle?

Managing changes and regression bugs

1. Are there any best practices for implementing the Open/Closed principle in components in use across multiple sites, in multiple configurations?
   1. For example, if we cannot modify existing components, how do we avoid requiring authors to replace every instance of the v1 slide component with the extended v2 slide component, across multiple sites, in order to access the new functionality?

thanks

Mark

[smacdonald2008]

What Experience Manager version are you using?

[smacdonald2008]

Using Gradle is NOT BEST Practice for AEM Development.

Best Practice can be found in this AEM article - that shows you how to use AEM editable templates,Core Components, Maven Archetype and so on...

Getting Started with AEM Sites - WKND Tutorial

[markj1644785]

Currently on 6.2 and getting ready to move to 6.4

[smacdonald2008]

As i stated - the WNDK tutorial reflects best practice to manage AEM code - including how to setup it up, how to manage source code, editable templates, and so on, I have asked a few internal ppl to add their thoughts here too.

[Jörg_Hoh]

I don't know what you mean with "sites". Are they sites (as in websites) sharing the same application or do you mean sites with different applications? In the first case you have only a single uniform application (maybe the sites have a different focus on certain components), while in the second you are likely to have multiple teams.

I would always prefer to have multiple (smaller) project bundles instead of a single big one. It allows you work more independently of each other (if the other factors like project organisation allow this).

Regaring 2: You should be consistent in your application and never should have a component in both version1 and version2 available. Instead you inherit from WCM Core Component v1 and at one point of switch the resourceSuperType to inherit from v2. This is done by the developers of your components and should be a single change per component; it's not a change on the content itself performed by authors.

[gary_gandy]

Hi Jörg,

I'm a developer working with Mark. He's asked me to expand on this.

We have three main sites, with more to likely come in the future:

1. A core website with 10+ language translations, edited across multiple regional author teams
2. a blog site, still in development
3. a venture capital site with a very different look and feel from the core website

There is a lot of common custom component reuse across the sites, with the majority of look and feel differences implemented in CSS/JS. However, there are a select number of components that have different behavior from the core site. In these cases, we have extended our components from the ones used in the core site, along with any extension of their WCMUse classes as well to implement any different behavior.

The issue we have with swapping the super type, or any other modification to functionality. is that we are not always aware how the other teams have authored their pages. They are not in lock step with our English language site authors. We, the developers, may wish to push out new features with our V2 of a component, but we have often found that this introduces unwanted layout changes in other regions translations or the VC site. In some cases, it has even introduced regression bugs regarding their local analytics javascript functionality.

Optimally, we would QA all the various pages ourselves. But with the number of localized edits we often see in other regions on the core site alone, this is not feasible for our development team. We want to minimize these layout changes or regression bugs until the teams in the other regions are prepared to QA and test the new components on their pages themselves, and we are looking for ways that other clients may have succeeded at this.

[Jörg_Hoh · Accepted solution]

Hi Gary,

thanks for providing more insight into your case. Let me elaborate on my idea:

1. You as platform team provide components in /apps/platform, another team (which is consuming your components and adapting them to their needs) is using /apps/team1, another team is using /apps/team2
2. You create an initial page component in /apps/platform/components/page/v1.
3. Team 1 and 2 are then reusing your page component; so team 1 creates /apps/team1/components/page and sets the supertype for this component to platform/components/page/v1. Team 2 does the same.
4. At one point you build a version 2 of this page component, and you place it in /apps/platform/components/page/v2.
5. Later team 2 decides to adopt your page component v2 and sets the supertype of their page component to platform/components/page/v2.

Till step 3 everything is fine and not different from a "standard approach". But with step 4 you as platform team deploy a new version of your page component without breaking the page components of team 1 and 2.

At step 5 team 2 decides to update their page component; completely on their own and with their own schedule. They adopt the v2 version of the page and check that their local overlays are still working. At the same time team 1 is still using the old page v1 component.

That's the approach which is the foundation of the AEM Core Components. And the thing is, that it does not require any new technology or foundation, but you can easily apply it to your own components.

Does this help?

kind regards,

Jörg

[gary_gandy]

Hi Jörg, we'll look into restructuring our components in this manner.

Thank you,
Gary

[smacdonald2008]

When you move to 6.4 - using Editable Templates will be one difference. The use of Static Templates in AEM 6.4 is no longer considered best practice. So in your 6.4 editable templates - you will be able to select which components can be used in which template. Just another thing to consider as you move to 6.4.