Best Practices: Project Organization & Managing Changes

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.

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

Thank you,
Gary

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.

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.

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.

Currently on 6.2 and getting ready to move to 6.4

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

What Experience Manager version are you using?