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.
Top comments (0)