Understanding the different release types of AEM, their release cycle and their support period is important to plan upfront for upgrading your AEM instance to higher versions (major, minor and patches). You should probably create an upgrade cycle suitable for your needs to match with the AEM release cycle
Release types
Full release A full release is done every year. This release is often referred to as the main release and could be a major release (version change form 5.x.y to 6.x.y, so on) or a minor release (version change from 6.1.x to 6.2.x, so on).
A full release includes many new features and improvements and is delivered as installable jar file. The migration path from lower versions into this version is defined and recommended for each full release as part of the release notes.
Service pack
For each full release, service pack is released every quarter. Service pack is released for a full release version till it remains in the core support period (more on support period below). Post this period no fixes or enhancements are released for that version. Service packs gets released as AEM package in package share.
A service pack may depend on other feature packs or service packs to be installed before applying it. Please read the release notes and installation instructions carefully before applying it
Feature pack
They typically include enhancements and new features (functionalities that typically are meant for next full release but are made available earlier). There are no defined timelines for feature pack releases.
A feature pack may have dependency on other feature pack and service pack to be installed before applying it.
Hot fix
Released on need basis to address critical issues in the product. Each hot fix package typically addresses a specific issue.
Hot fixes are typically quickly made fix packs based on customer complaint and are not thoroughly QA tested. Be cognizant of this fact when applying a hot fix package.
If the issue addressed by the hot fix package is not applicable for your case, you could choose to wait till the cumulative fix pack (which is better QA tested) including the fix becomes available instead of applying the hot fix immediately.
Cumulative fix pack
The cumulative fix packs or CFPs are released every month and includes all hot fixes applicable. It may also include some feature packs. They are independent and does not depend on other hot fixes or feature packs or previous versions of CFPs for its installation.
But a CFP is released for the latest service pack and its essential to have the dependent service pack installed before installing a cumulative fix pack.
Release Cycle
It is advisable to keep track of the timelines for following releases from Adobe for AEM
- Full Release – Released annually typically in the month of Apr
- Service Pack – Release quarterly in the last month of every quarter (Jun, Sep, Dec, Mar)
- Cumulative Fix Pack – Released monthly for the latest service pack
You could choose to watch out for feature packs and hot fixes based on your needs but keeping a track on full release, service pack and CFP releases and upgrading your AEM instance periodically with these is essential for proper maintenance of AEM instance.
Support Period
AEM support is defined based on the full release version and the support for all service packs, CFPs and feature packs of this version ceases to apply when the support for the full release version ends.
Support for a full release version falls into 3 support periods
- Core support for a period of 3 years from the date of release
- An extended support for an additional 2 years
- An official self-service support for 1 year beyond this (through online self-help mechanism)
An AEM full release goes out of support after 6 years from the date of release of the version (Note: not from the date of your purchase, a reason why you should always start with the latest version) of which only the first 5 years is available with Adobe professional support.
Given that the initial implementation or migration to an AEM release takes anywhere from a month to a year (for a reasonably sized project) and providing for some safe zone before the AEM version goes out of support, we would need to plan for upgrade at least every 3 to 4 years if not more frequently.
Upgrade strategy
Devising an upgrade strategy and putting in place a process for upgrade is essential for maintaining an AEM installation over a long run.
The upgrade strategy for AEM falls under two categories
- Regular upkeep with service packs, CFPs, feature packs and hot fixes
- Repository migration for main release change
Regular upkeep
This does not involve migration of the repository. Device a strategy for dealing with each of type of release packs
Hot fixes
The criticality of applying a hot fix depends on specific scenario. If there is a product bug surfacing in your environment, you would have already got in touch with the Adobe support team and based on their advice plan to install the required hot fixes.
Feature pack
This again depends on your case of how urgently the feature or enhancement addressed in the feature pack is needed for your application. Plan for installing feature packs based on your need.
Service Pack
It is desirable to keep your AEM instance updated of the latest service pack. Apart from brining in the new features, enhancements and bug fixes, it would make sure that your environment is updated and ready for applying future feature packs, CFPs and hot fixes when needed
Cumulative fix pack
Weigh in on the need to apply a CFP depending of the issues it addresses vis-a-vis the overhead of applying it. Remember applying the latest CFP would bring in the fixes addressed in all the previous CFPs applicable.
Device a regular upkeep strategy based on your needs. Define the process and put it in plan.
A general best practice is to keep the AEM environment updated of the latest service pack so that it periodically brings in the benefits of the fixes, features and enhancements made available.
Repository Migration
Apart from many other reasons to migrate to the higher versions, AEM support model forces periodic migration of the repository to newer AEM versions. Depending on your application scenario, you could choose to migrate to
- Every new full release
- Skip ‘x’ no. of full releases before migrating
With every full release, AEM defines the migration path from all the previous versions within the core support period into the current release. So it becomes extra safe to migrate while your AEM version is in the core support period.
Be cautious of the complexities involved in repository migration as applicable to your case. Repository migration most often involves code updates and content migration and is not in any way a trivial exercise.
Best Practices
Some of the best practices to keep in mind when performing upgrades
- Never perform an upgrade directly in production without testing it in lower environments
- When testing in lower environment, sync its content as closely as possible with production
- Always take a backup of the AEM instance before applying the upgrade
- Perform the upgrade both on Author and Publish instances in lower environment and test them
- Rebuild the application with the new uber.jar version and other dependencies as applicable and deploy it to the upgraded environment for testing
- Finally, thoroughly test the application to make sure that the application meets the functional and non-functional criteria with the upgrades applied
No comments:
Post a Comment
If you have any doubts or questions, please let us know.