I have a question for the community regarding best practices for handling project organization, changes and regression.
Project organization
Managing changes and regression bugs
thanks
Mark
Solved! Go to Solution.
Hi Gary,
thanks for providing more insight into your case. Let me elaborate on my idea:
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
Views
Replies
Total Likes
What Experience Manager version are you using?
Views
Replies
Total Likes
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...
Views
Replies
Total Likes
Currently on 6.2 and getting ready to move to 6.4
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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:
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.
Views
Replies
Total Likes
Hi Gary,
thanks for providing more insight into your case. Let me elaborate on my idea:
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
Views
Replies
Total Likes
Hi Jörg, we'll look into restructuring our components in this manner.
Thank you,
Gary
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies