Understanding & Aligning with AEM Release Cycle
Planning for the different release types, release cycles and support period
Ashokkumar T A | 09-Dec-2019
Why bother about AEM releases?
Just pushed your AEM application live…
You have all the maintenance processes defined and scheduled…
Time to relax…
Not really… Adobe is at work
• Your AEM version is going out of core support shortly
• You face a critical issue, Adobe has released a hot fix for that, but you cannot apply it as you have not
applied the latest service pack in your environment
• Your application team wants to build on a new feature made available by Adobe, but you have not yet
applied that in your environment
As you can see, there are different types of releases for AEM happening periodically. Keeping track of them
and planning for which ones to apply and when is essential to maintaining your AEM environment healthy
and in a ready state to respond to any situation
2
Release Types
The different release types of AEM
Full release – The main release that contains many new features and improvements. Older versions can
only be migrated in the a new full release
Service pack – An AEM package that can be installed on your installation, recommended to keep your AEM
updated with the latest service pack
Feature pack – An AEM package that includes enhancements and new features. There is no defined
timeline for a feature pack release and typically would have dependency on other feature packs and service
pack to be installed.
Hot fix – An AEM package released on need basis to address critical issues in the product. These are quick
fixes from Adobe. You could skip applying it if the issue addressed is not of concern for your case
Cumulative fix pack – An AEM package that includes all the hot fixes and may also include some feature
pack items.
3
Release Cycle
Keep track of the following releases from Adobe
• Full release – Released one a year typically in the month of April.
• Service pack – Released quarterly, made available in the last month of every quarter
• Cumulative fix pack – Released monthly containing all the hot fixes for the month. May also include some
new features.
• Hot fix – Released ad-hoc based on need
• Feature pack – No defined cycle for feature pack releases.
4
Support Period
Beware – you might be having an unsupported AEM version
• Core support period for a version is 3 years from the date of its release (not the date of your purchase or
your go-live)
• Extended support available for additional 2 years
• Self service support for 1 year beyond this period (through on-line self help mechanism)
• Prudent to be in safe zone and migrate before your version goes out of support
A lot of details goes into your specific contract with Adobe, but generally its safe to
• Keep your version of AEM within the core support period – for critical, frequently changing application. This
requires a minimum migration cycle of once in 2 to 2.5 years
• For non-critical applications – have migration cycles in the range of 3 to 4 years to maintain your installation
with-in the Adobe professional support cycle
5
Regular up-keep
Maintain your AEM setup Strong & Sound
• Hot fixes – Keep track of all hot fixes, evaluate if a hot fix is applicable for your setup, confirm with Adobe
support team before installing the hot fix
• Feature packs – Evaluate the need of the new feature or enhancement addressed in the feature pack for
your application, install it if needed
• Service packs – Desirable to keep the AEM instance updated with latest service pack. It makes sure that
you have a platform on which future hot fixes and feature packs can be quickly applied
• Cumulative fix pack – Weigh in on the need vs. overhead to decide if a CFP needs to be applied.
A general best practice is to keep your environment updated of the latest service pack periodically so that
brings in the benefits of all the fixes, features and enhancements done so far and also keep the environment
ready to apply any emergency fixes in the future.
6
Repository migration
Essential for maintaining your AEM setup over long run
• AEM support model forces repository migration to newer versions
• Prudent to be in the core support period of your AEM version
• Upgrade on every full release (on the latest always) or choose to skip ‘x’ releases (less frequent migration)
and migrate
• AEM’s release notes defines migration path from previous versions (in core support period)
• Never underestimate the complexity of repository migration. The migration might require code changes and
content migration as well
7
Some golden rules – we have always known
• Do not do any change directly in production. Make sure its tested in a lower environment, however trivial
the change may be
• Include both Author and Publish instances while testing
• Keep the content in the test environment as close to production as possible
• Take backup before any change
• In case of upgrade, rebuild the application with new uber.jar version
• Test thoroughly – both for functional and non-functional requirements
8
Detailed write-up on this topic at
https://aem-musings.blogspot.com/2019/06/understanding-aem-release-types-release.html
Thank You
9
Feedback and suggestions welcome. Please write to
ashokkumar_ta / ashokkumar.ta@gmail.com

Aligning to AEMs Release Cycle

  • 1.
    Understanding & Aligningwith AEM Release Cycle Planning for the different release types, release cycles and support period Ashokkumar T A | 09-Dec-2019
  • 2.
    Why bother aboutAEM releases? Just pushed your AEM application live… You have all the maintenance processes defined and scheduled… Time to relax… Not really… Adobe is at work • Your AEM version is going out of core support shortly • You face a critical issue, Adobe has released a hot fix for that, but you cannot apply it as you have not applied the latest service pack in your environment • Your application team wants to build on a new feature made available by Adobe, but you have not yet applied that in your environment As you can see, there are different types of releases for AEM happening periodically. Keeping track of them and planning for which ones to apply and when is essential to maintaining your AEM environment healthy and in a ready state to respond to any situation 2
  • 3.
    Release Types The differentrelease types of AEM Full release – The main release that contains many new features and improvements. Older versions can only be migrated in the a new full release Service pack – An AEM package that can be installed on your installation, recommended to keep your AEM updated with the latest service pack Feature pack – An AEM package that includes enhancements and new features. There is no defined timeline for a feature pack release and typically would have dependency on other feature packs and service pack to be installed. Hot fix – An AEM package released on need basis to address critical issues in the product. These are quick fixes from Adobe. You could skip applying it if the issue addressed is not of concern for your case Cumulative fix pack – An AEM package that includes all the hot fixes and may also include some feature pack items. 3
  • 4.
    Release Cycle Keep trackof the following releases from Adobe • Full release – Released one a year typically in the month of April. • Service pack – Released quarterly, made available in the last month of every quarter • Cumulative fix pack – Released monthly containing all the hot fixes for the month. May also include some new features. • Hot fix – Released ad-hoc based on need • Feature pack – No defined cycle for feature pack releases. 4
  • 5.
    Support Period Beware –you might be having an unsupported AEM version • Core support period for a version is 3 years from the date of its release (not the date of your purchase or your go-live) • Extended support available for additional 2 years • Self service support for 1 year beyond this period (through on-line self help mechanism) • Prudent to be in safe zone and migrate before your version goes out of support A lot of details goes into your specific contract with Adobe, but generally its safe to • Keep your version of AEM within the core support period – for critical, frequently changing application. This requires a minimum migration cycle of once in 2 to 2.5 years • For non-critical applications – have migration cycles in the range of 3 to 4 years to maintain your installation with-in the Adobe professional support cycle 5
  • 6.
    Regular up-keep Maintain yourAEM setup Strong & Sound • Hot fixes – Keep track of all hot fixes, evaluate if a hot fix is applicable for your setup, confirm with Adobe support team before installing the hot fix • Feature packs – Evaluate the need of the new feature or enhancement addressed in the feature pack for your application, install it if needed • Service packs – Desirable to keep the AEM instance updated with latest service pack. It makes sure that you have a platform on which future hot fixes and feature packs can be quickly applied • Cumulative fix pack – Weigh in on the need vs. overhead to decide if a CFP needs to be applied. A general best practice is to keep your environment updated of the latest service pack periodically so that brings in the benefits of all the fixes, features and enhancements done so far and also keep the environment ready to apply any emergency fixes in the future. 6
  • 7.
    Repository migration Essential formaintaining your AEM setup over long run • AEM support model forces repository migration to newer versions • Prudent to be in the core support period of your AEM version • Upgrade on every full release (on the latest always) or choose to skip ‘x’ releases (less frequent migration) and migrate • AEM’s release notes defines migration path from previous versions (in core support period) • Never underestimate the complexity of repository migration. The migration might require code changes and content migration as well 7
  • 8.
    Some golden rules– we have always known • Do not do any change directly in production. Make sure its tested in a lower environment, however trivial the change may be • Include both Author and Publish instances while testing • Keep the content in the test environment as close to production as possible • Take backup before any change • In case of upgrade, rebuild the application with new uber.jar version • Test thoroughly – both for functional and non-functional requirements 8 Detailed write-up on this topic at https://aem-musings.blogspot.com/2019/06/understanding-aem-release-types-release.html
  • 9.
    Thank You 9 Feedback andsuggestions welcome. Please write to ashokkumar_ta / ashokkumar.ta@gmail.com