Optimal way to upgrade local AEM SDK version

[shehjadk07]

Hi All,

I am looking for best process to upgrade local cloud sdk for AEM, currently locally I have lot of content and thus every time I am blowing away the whole content and then install the latest SDK but this is very time taking. Below are approaches I am thinking might be more optimal, please suggest any new if I have not listed

1. Just replace the jar and keep the crx-quickstart and just double click the jar file, is this method safe and will it keep the existing content as it is?

2. Separate out the data store and node store as described in this document but is this supported on the cloud version of AEM? https://experienceleague.adobe.com/docs/experience-manager-65/deploying/deploying/data-store-config....

3. Delete the whole crx-quickstart folder install new sdk and content again ( this what currently my team is doing)

Any other optimal approach?

Thanks,

Shehjad

[Kishore_Kumar_]

Please let me know if you have tried the below approach as mentioned in this document.

"Use oak-upgrade with the includepaths directive, to copy content from the prior AEM SDK repository to the new AEM SDK repository."

[Bimmi_Soi]

Hi @shehjadk07 ,

Please go through below documentation's How to avoid content loss when upgrading the AEM SDK topic

Set up Local AEM Runtime for AEM as a Cloud Service Development | Adobe Experience Manager

How to avoid content loss when upgrading the AEM SDK
Upgrading the AEM SDK is effectively creating a brand new AEM runtime, including a new repository, meaning any changes made to a prior AEM SDK’s repository are lost. The following are viable strategies for aiding in persisting content between AEM SDK upgrades, and can be used discretely or in concert:

1. Create a content package dedicated to containing “sample” content to aid in development, and maintain it in Git. Any content that should be persisted through AEM SDK upgrades would be persisted into this package, and re-deployed after upgrading the AEM SDK.
2. Use oak-upgrade with the includepaths directive, to copy content from the prior AEM SDK repository to the new AEM SDK repository.
3. Backup any content using AEM Package Manager and content packages on the prior AEM SDK, and re-install them on the new AEM SDK.
Remember, using the above approaches to maintain code between AEM SDK upgrades, indicates a development anti-pattern. Non-disposable code should originate in your Development IDE and flow into AEM SDK via deployments.

Hope this helps!!

Thanks

[markus_bulla_adobe · Accepted solution]

Hi @shehjadk07!

As @Kishore_Kumar_ and @Bimmi_Soi have already mentioned, the official recommended way for this is either content packages or via oak-upgrade tool as outlined in this documentation.

Personally, I would prefer the content package based approach.

Another thing that you should think about is: What kind of content are you talking about?

Usually, the most common classifications would be:

• Sample content for development purposes
  This is created by the developers and provided, e. g. to demonstrate the behavior of a component or to show component variations based on their configurations. It can also be used for automated testing, sometimes even as a kind of documentation or user manual for content editors to refer to.
  This kind of content should be maintained as a dedicated Maven module in your source code repository and can easily be redeployed to any new instance.
• Real production(-like) content
  In some projects, there are processes in place for a content backflow from higher environments (e. g. staging or even production) to lower development environments. This is usually used for testing purposes to and to be able to work with production-like content during the development cycle.
  In this case, there will already be a process to get content from other environments to your local one and you may leverage the very same process whenever you deploy a new local SDK instance.

For anything else, I would suggest to create a dedicated CRX Package, update/built and download it before you want to switch the SDK version and install it to your new SDK instance.

Looking at your suggestions:

1. Will definitely work for "classic" AEM, e. g. when moving from 6.4 to 6.5 or similar. I'm not sure if it will also work for the cloud SDK. As it is not mentioned in the above linked documentation, I doubt that it is supported and would not follow this approach.

2. Separating the datastore won't help here. You would need to separate the whole repository which is not possible with the SDK as far as I know.

3. Sounds like the outlined approach using packages and is my recommendation.

Focusing on approach #3 and trying to optimize/automate the process as far as possible would be my preferred way to go.

Hope that helps!