DEV Community: Carlos Araujo

Dev & QA (AEM 6.5 Upgrade)

Carlos Araujo — Fri, 28 Aug 2020 16:54:24 +0000

This phase of the process involves code related task efforts. You will need to analyze the libraries and dependencies that you need to update, and of course, all the coding refactor needed because of the upgrade.

Something that worked for me is to upgrade my local to 6.5 and then upgrade the code. Doing this I was able to identify dependencies that I was missing from my initial assessment.

Keep in mind that (at least in my scenario) there were many changes at AEM libraries, methods were deprecated, how to access the repository through code changed to have stronger security, which means that having a good idea of what your solution does, and doing pretty good testing is a key factor that will allow you to have a better outcome of this process phase.

The substeps within this process are:

Create a dedicated code branch
Cleanup content in production
Backup and roll down content from production to lower environments.
Update codebase
Align repository structure with 6.5

Create a dedicated code branch

While you are working on the upgrade, it is always important to not mix your code from what is working on production (master branch) with the upgrade code. Created a dedicated branch that will help you and the other engineers perform the upgrade tasks without interfering with the production code.

An ideal scenario is to have a code freeze while the upgrade happens.

Code freeze date

Having a code freeze period of time when the upgrade tasks are being executed is a best practice. I understand that this might not be possible in every scenario, although I do recommend doing your best to try to achieve this freeze date for your upgrade project.

Having a code freeze, while allowing the development team has peace of mind about future code merging conflicts and issues. It could be terrible for the upgrade effort to be complete but then having to merge and resolve conflicts or issues again and again.

This is not only a best practice for the development team, but this is also a best practice for the client. This way the client is also confident that things are properly tested and that no new issues or bugs will be generated on the existing functionality.

Clean up content in production

This is overall is a good practice. Content repository migrations take time and have the option of cleaning up content will be a good strategy for the upgrade effort.

In my scenario I had several sites that were not being used anymore, they were only present in authoring and removed from publish instances a couple of years ago.

The DAM is also a good place to clean up. Getting reports of what assets are really being used will allow the content authors to take an educated decision of deleting or keeping assets. For this effort, I used groovy scripts that helped me generate an important list of assets.

Backup content and roll it down to lower environments

Now that we have a cleaner content, it is time to roll down content from production to lower environments before any upgrade happens.

Having the latest content on each environment will allow you to capture upgrade functionality inconsistencies or issues before you are too late in the process.

There are many approaches to backup and move content from one environment to another. I really like using grabbit since it is very flexible, fast, and reliable. If you have any other suggestions please leave it in the comments section.

Update code base

This section is mostly covered in two phases. The first one is before your local is upgraded to 6.5, the second phase is after your local is under 6.5. and after you have deployed the updated code to your instance.

First phase

Updating dependencies on your maven solution is the place where you need to start. Identify issues while triggering a build. Keep updating other dependencies, do this as a cycle until the solution builds correctly.

Second phase

After doing the above, I accessed OSGI and went directly to bundles. In there I was able to determine if the bundles that I was deploying were active, or installed. This helped me to determine which other dependencies I needed to update before continuing.

Something that I recommend as well is to take a close look at the log files. In there you will be able to identify a few things that will call your attention that need to be addressed for the upgrade.

Align with 6.5 Repository structure

Since 6.2 there was been many changes at repository structure. Not only at the level of how OAK works, but also on where several OOTB and Custom features are stored.

Some of this list are: blueprints, rolloutconfigs, tags, workflows, designs, contexthub, segments.

The thumb rule is: AEM product code will always be placed in /libs, which must not be overwritten by custom code. Custom code should be placed in /apps, /content, and /conf. The /etc folder should be used no more.

Once I complete this post series I am planning on creating a post that talks about completely of the repository content structure changes that I had to go for AEM 6.5 upgrade.

Parent Post

Process Breakdown (AEM 6.5 Upgrade)

Carlos Araujo — Wed, 26 Aug 2020 22:25:11 +0000

A good process is a key part of the upgrade, being able to create a very good breakdown of general activities, being able to identify inner activities helped me build and determine the different steps that I needed to follow for each instance, for each environment.

This process is always a living document, my recommendation would be to draft an initial breakdown and keep removing/adding details as you move forward with the upgrade.

The general steps that I came up with are:

Upgrade Planning
Development & QA
Pre-upgrade Maintenance
Upgrade Procedure
Post Upgrade Checks

Upgrade Planning

For me, this section covers tasks that will allow me to understand the development effort for the upgrade.
I have listed within it current versions of everything. This allowed me to identify if versions of different platforms will work with 6.5 or if they also need to be updated.

Run pattern detector.
Create a test plan.
Components inventory.
Platforms version inventory.

Run pattern detector

Download and install package pd-all-aem65-1.0.zip this package. After install go to /system/console/status-pattern-detector and analyze the results. This will allow you to assess the level of complexity of your upgrade.

You will get a list of components that might be violating certain rules, features that are not compatible with 6.5. For more information on this go here.

Create a test plan

This test plan will allow you to test core AEM functionalities after each environment upgrade and also will allow you to test site components that are critical or could be prone to fail after the upgrade.

For us, it was very useful to build three sets of test plans

Core AEM functionality tests (i.e. blueprints, rolloutconfigs, i18n, tags, contexthub, etc)
Test cases from a site visitor perspective.
Test cases from an authoring perspective.

Components inventory

We generated a dictionary of components and the number of instances within the site. This helped me understand which are key components that we need to test carefully while doing the upgrade, mainly if any of those components are using third party integrations.

Platforms version inventory

This is an important step within the upgrade planning. This allowed me to identify if there was any inconsistency between environments, and it helped me identify and assess if apache and dispatcher needed an upgrade or not.

The platforms/tools that I listed in the inventory are:

Java
AEM
Dispatcher
Apache

The above was listed for every environment, in my case Local, Dev, QA, UAT, Prod.

This step allowed me to identify that I needed to include a dispatcher upgrade in my process.

Next Post

Parent Post

Where to Start (AEM 6.5 Upgrade)

Carlos Araujo — Wed, 26 Aug 2020 22:24:54 +0000

Now while looking back to the process I followed for the upgrade, I can say that the first thing to do is to identify the approach to follow. Plain and simple, there are two approaches. In-place upgrade, fresh instance upgrade. There are many posts that talk about the advantages and disadvantages of each approach (I won't go into those details here). Please read about it and take an educated decision on which one to follow based on your project.

When I was going to make my decision, an architect told me that it depends on the repository, code, integrations, time. A lot of times, doing a small POC of the approach that will be taken is the best way to identify which one is the right one for your solution.

This is how I ended up making the decision to go with an In-Place upgrade, it suited the solution needs plus it is the recommended approach by Adobe.

Once I had the approach, I had the 6.5 jar file/license, I was ready to build the team to perform it.
Upgrades take time, although it is not at all a project where you can put several engineers to make it go faster, upgrades are 1-2 men job at most.

Now that we have identified the approach, that we have the files ready for us, and that we have the team that will do it, is time for the planning around it.

Next Post - Process Breakdown
Parent Post

Upgrading AEM to 6.5

Carlos Araujo — Wed, 26 Aug 2020 22:24:25 +0000

Recently I was involved in a project to upgrade AEM from version 6.2 to 6.5.

As you can imagine there were several things to be considered for the upgrade. AEM has updated a lot of their features and libraries since 6.2, OAK repository changes, a bunch of /etc functionality relocations (blueprints, rolloutconfigs, contexthub, segments, tags, designs, among others).

On this series of posts, I want to describe the steps I followed to perform the In-Place upgrade.

The first thing that I would like to say is: this is not a recipe, this is just information on the approach I took.

First takeaway: if you are in a similar upgrade situation, these posts might help you identify the approach that you could take to perform yours. I read a bunch of documentation, posts, and information, in my case I used different ideas from different sources to accomplish the goal.

List of related posts: (Updated on August 28, 2020)

Where to Start (AEM 6.5 Upgrade)?
Process Breakdown (AEM 6.5 Upgrade)
Development & QA (AEM 6.5 Upgrade)
Pre-upgrade Maintenance (Post in progress)
Upgrade Procedure (Post in progress)
Post-upgrade Checks (Post in progress)