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