Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn more

View all

Sign in to view all badges

SOLVED

AEM project release managment

mitadiana
Level 1
Level 1
I am interested to see how people are doing release builds for an AEM project:
  • using the maven release plugin that is in pom.xml OOTB for this archtype
  • custom process using other maven plugins (build-helper plugin, version plugin)

Pros/cons for each option? what is the release numbering mechanism that you use? how is the patching done? do you use a release branching mechanism?

Thanks

1 Accepted Solution
markus_bulla_adobe
Correct answer by
Employee
Employee

Hi @mitadiana!

Release Management is a very broad topic and there is no one-size-fits-all approach here. Every AEM project has different prerequisites, dependencies, requirements, etc.

 

While there are some smaller projects that do release builds manually, most projects have some kind of CI/CD chain in place that helps them automate this task. Often this is based on an already established tool set. So the bottom line here is: use what you already have in place and/or are comfortable to work with. Usually, the maven release plugin works totally fine and has good support by various CI/CD tools. I would restrain from manual (especially local) release builds as this always comes with certain risks for unexpected side effects.

 

When it comes to release numbering, AEM follows the Semantic Versioning guidelines as outlined here [1], see also [2]. This blog post [3] explains the behaviours of AEM/JCR with regards to different versions of a package/bundle being installed.

For branching and patching there are - again - different approaches based on your projects specific requirements. Some very agile projects follow a forward-only approach and don't really do patches, just new releases. Others clients (usually with longer release cycles) follow a more conservative approach. A common pattern I've seen is to leverage GitFlow [4]. It is a rather complex branching model but covers most, if not all,  use cases with regards to branching, patching, etc.

 

If you are an Adobe Managed Services (AMS) or AEM as a Cloud Service (AEMaCS) customer, you may also want to look at Adobe Cloud Manager [5] in this context.

 

Hope that helps!

 

[1] https://github.com/adobe/aem-core-wcm-components/wiki/Versioning-policies

[2] https://semver.org/

[3] https://aemproblog.wordpress.com/2016/12/29/aem-bundle-versioning-best-practices/

[4] http://datasift.github.io/gitflow/IntroducingGitFlow.html

[5] https://experienceleague.adobe.com/docs/experience-manager-cloud-manager/using/introduction-to-cloud...

View solution in original post

1 Reply
markus_bulla_adobe
Correct answer by
Employee
Employee

Hi @mitadiana!

Release Management is a very broad topic and there is no one-size-fits-all approach here. Every AEM project has different prerequisites, dependencies, requirements, etc.

 

While there are some smaller projects that do release builds manually, most projects have some kind of CI/CD chain in place that helps them automate this task. Often this is based on an already established tool set. So the bottom line here is: use what you already have in place and/or are comfortable to work with. Usually, the maven release plugin works totally fine and has good support by various CI/CD tools. I would restrain from manual (especially local) release builds as this always comes with certain risks for unexpected side effects.

 

When it comes to release numbering, AEM follows the Semantic Versioning guidelines as outlined here [1], see also [2]. This blog post [3] explains the behaviours of AEM/JCR with regards to different versions of a package/bundle being installed.

For branching and patching there are - again - different approaches based on your projects specific requirements. Some very agile projects follow a forward-only approach and don't really do patches, just new releases. Others clients (usually with longer release cycles) follow a more conservative approach. A common pattern I've seen is to leverage GitFlow [4]. It is a rather complex branching model but covers most, if not all,  use cases with regards to branching, patching, etc.

 

If you are an Adobe Managed Services (AMS) or AEM as a Cloud Service (AEMaCS) customer, you may also want to look at Adobe Cloud Manager [5] in this context.

 

Hope that helps!

 

[1] https://github.com/adobe/aem-core-wcm-components/wiki/Versioning-policies

[2] https://semver.org/

[3] https://aemproblog.wordpress.com/2016/12/29/aem-bundle-versioning-best-practices/

[4] http://datasift.github.io/gitflow/IntroducingGitFlow.html

[5] https://experienceleague.adobe.com/docs/experience-manager-cloud-manager/using/introduction-to-cloud...

View solution in original post