I have started a new project with AEM 6.5.18 on-premise solution, created with Maven archetype 41.
Deployed is always the .all package which contains the ui.apps, ui.config and ui.content packages.
The ui.content module includes source content and configurations under /content and /conf that are rolled out with each deployment.
These nodes are set to mode="merge" in the associated filter.xml so that no editorially created content is overwritten on the instances.
Works so far.
In an old project based on CQ 5.6 there was only one package that was deployed, and it contained only /apps and /etc nodes.
Unfortunately the jar files contained in it were not always replaced correctly in the AEM or the updated JARs were used.
That's why it was decided to work only with the package version 1.0.0-SNAPSHOT and to uninstall the old one
and reboot the instance before reinstalling the package. This worked very well for a long time.
However, since we now have a ui.content package in the new project that also writes to /content,
if we uninstall the package, it will also restore the edited content below /content at the time of installation using the package manager snapshot.
I've read a lot of documentation from Adobe on this topic, but I'm still not sure if I've got the best deployment procedure right now:
1. the package is versioned/incremented correctly for each deployment according to Maven standard.
2. the previously installed packages do not need to be uninstalled because the package with the higher version number is automatically used.
Are these statements correct?
Have I forgotten anything?
I would also like to know if it makes sense to reboot the AEM instance after a package deployment.
Thanks in advance
Thorsten
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
Hi,
Here are my two cents, I think you are doing well, although you should be aware of the SNAPSHOT and RELEASE functionality. This can help to clarify any doubt: https://sling.apache.org/documentation/bundles/osgi-installer.html#versions-and-snapshots. Ideally, you would have your artifact in a lower environment (dev, local) using the SNAPSHOT suffix and in a production environment, you would use the RELEASE suffix. This way, you would increment with each new release and not necessarily with each small code change as part of regular development work.
Regarding rebooting the instance, it is not necessary, however, depending on which processes are being updated through your packages, it can take some time to stabilize your instance. If you encounter an issue with something not being installed via the package manager, my recommendation would be to install it using CURL. This way, you can get a better log of what could be causing the issue.
Hope this helps
Hi,
Here are my two cents, I think you are doing well, although you should be aware of the SNAPSHOT and RELEASE functionality. This can help to clarify any doubt: https://sling.apache.org/documentation/bundles/osgi-installer.html#versions-and-snapshots. Ideally, you would have your artifact in a lower environment (dev, local) using the SNAPSHOT suffix and in a production environment, you would use the RELEASE suffix. This way, you would increment with each new release and not necessarily with each small code change as part of regular development work.
Regarding rebooting the instance, it is not necessary, however, depending on which processes are being updated through your packages, it can take some time to stabilize your instance. If you encounter an issue with something not being installed via the package manager, my recommendation would be to install it using CURL. This way, you can get a better log of what could be causing the issue.
Hope this helps
Hi @thorstenk188041 ,
1. the package is versioned/incremented correctly for each deployment according to Maven standard.
Yes, the package number is auto-incremented after every deployment.
2. the previously installed packages do not need to be uninstalled because the package with the higher version number is automatically used.
Correct. Also, you are using mode=merge this is the correct approach to go ahead with the code packages ( ui.apps, ui.config ).
For the ui.content I am assuming you don't make changes to content through ui.content packages, instead authors are editing content, and you just add new pages. then mode="merge" works. But, if you are editing content through ui.content then mode=merge may not update content.
I would also like to know if it makes sense to reboot the AEM instance after a package deployment.
Nope, no need for that.
The best practice here is to establish a stratergy , like a blue-green deployment.
https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html
Thank you both for the quick and helpful information,
they help me in any case.
Regarding the ui.content package, no authored content is stored here.
We currently use it to add new/adapted experience fragments (/content/experience-fragments)
and new/adapted templates/policies (/conf/client/settings/wcm).
Here I'm also unsure if it wouldn't be a better way to create experience fragments and new templates
editorially and then distribute them to the instances using content packages.
Many thanks
Thorsten
Yes, distributing them through the package manager is the best way.
Making content independent of code is one of the main reasons people use AEM, so sharing through content packages is the best practice.
Happy to help!
Views
Likes
Replies
Views
Likes
Replies