规划升级

AEM项目概述

AEM通常用于高影响力的部署，这些部署可能会为数百万用户提供服务。 通常，实例上会部署自定义应用程序，这会增加复杂性。 任何升级此类部署的工作都需要有条不紊地处理。

本指南有助于在规划升级时制定明确的目标、阶段和交付项。 它侧重于项目的整体执行和指南。 虽然提供了实际升级步骤的概述，但它会根据需要参考可用的技术资源。 它应当与本文件提及的可用技术资源一起使用。

AEM升级过程需要仔细处理规划、分析和执行阶段，并为每个阶段定义关键交付项。

可以直接从AEM版本6.0升级到6.5。运行5.6.x及更低版本的客户需要首先升级到版本6.0或更高版本，推荐使用6.0 (SP3)。 此外，从6.3开始，新的Oak区段Tar格式现在用于区段节点存储，即使对于6.0、6.1和6.2，存储库迁移到此新格式也是强制性的。

升级范围和要求

在下方，您将找到在典型的AEM升级项目中受影响的区域列表：

务必确保您运行的是受支持的操作系统、Java™运行时、httpd和Dispatcher版本。 欲了解更多信息，请参见 AEM 6.5技术要求页面. 必须在项目计划中考虑升级这些组件，并且应在升级AEM之前进行升级。

项目阶段

规划和运行AEM升级需要完成大量工作。 为了澄清在此过程中所做的各种工作，Adobe将规划和执行活动划分为不同的阶段。 在以下部分中，每个阶段都会生成一个交付项，通常用于项目的未来阶段。

规划作者培训

对于任何新版本，可能会对UI和用户工作流引入潜在更改。 此外，新版本引入了可能对企业有利的新功能。 Adobe建议审查已引入的功能更改，并组织计划以培训用户有效使用这些更改。

AEM 6.5中的新增功能位于 adobe.com的AEM部分. 请务必注意对组织中常用的UI或产品功能所做的任何更改。 浏览新功能时，请注意对您的组织有价值的任何功能。 查看AEM 6.5中的更改后，为作者制定培训计划。 这可能涉及使用免费提供的资源，例如帮助功能视频或提供的正式培训 Adobe数字学习服务.

创建测试计划

每个客户的AEM实施都是独一无二的，并且已经过自定义以满足其业务需求。 因此，必须确定已对系统所做的所有自定义设置，以便将其包含在测试计划中。 此测试计划将支持Adobe在升级后的实例上执行的QA过程。

需要复制确切的生产环境，并且应在升级后对其执行测试，以确保所有应用程序和自定义代码仍按需运行。 回退所有自定义设置并运行性能、负载和安全测试。 在组织测试计划时，除了开箱即用的UI和日常操作中使用的工作流之外，还要确保涵盖针对系统所做的所有自定义设置。 这些集成包括自定义OSGI服务和Servlet、与Adobe Experience Cloud的集成、通过AEM连接器与第三方的集成、自定义第三方集成、自定义组件和模板、AEM中的自定义UI叠加以及自定义工作流。 对于从AEM 6之前的版本迁移的客户，应分析任何自定义查询，因为这些查询可能需要编制索引。 对于已使用AEM 6.x版本的客户，仍应测试这些查询，以确保其索引在升级后继续有效工作。

确定所需的架构和基础架构更改

升级时，可能还需要升级技术栈栈中的其他组件，例如操作系统或JVM。 此外，由于存储库中的更改，可能需要额外的硬件。 这仅适用于从6.x以前的实例迁移的客户，但必须考虑。 最后，您的操作做法可能需要改变，包括监控、维护以及备份和灾难恢复过程。

查看AEM 6.5的技术要求，并确保您当前的硬件和软件足以满足要求。 有关操作流程的潜在更改，请参阅以下文档：

监控和维护：

操作功能板

Assets 监控最佳实践

使用JMX控制台监控服务器资源

修订版清理

备份/恢复和灾难恢复：

备份和恢复

性能和可扩展性

如何在TarMK冷待机状态下运行AEM

内容重构注意事项

AEM已对存储库结构进行了更改，这有助于使升级更加顺畅。 这些更改涉及根据Adobe或客户是否拥有内容，将内容从/etc文件夹移出到/libs、/apps和/content等文件夹，从而限制在发布期间覆盖内容的机会。 存储库重组已经完成，因此在6.5版升级时不需要更改代码，但建议查看详细信息： AEM中的存储库重组 在计划升级时。

评估升级复杂性

由于Adobe客户在其AEM环境中应用的自定义设置的数量和性质多种多样，因此请务必提前一些时间来确定在您的升级中应需要的总体工作量。

您可以使用两种方法来评估升级的复杂性，一种是初步阶段可以使用新引入的模式检测器，该检测器可在AEM 6.1、6.2和6.3实例上运行。 模式检测器是使用报告的模式来评估预期升级的整体复杂性的最简单方法。 模式检测器报表包含用于识别自定义代码库正在使用的不可用API的模式（这是使用6.3中的升级前兼容性检查完成的）。

在初始评估后，更全面的下一步可能是对测试实例执行升级并执行一些基本的烟雾测试。 Adobe也提供了一些。 另外， 已弃用和已删除的功能 不仅要检查要升级到的版本，还要检查源版本和目标版本之间的任何版本。 例如，如果从AEM 6.2升级到6.5，则除了那些用于AEM 6.5的功能之外，查看AEM 6.3已弃用和已删除的功能也非常重要。

最近推出的模式检测器应该可以非常准确地估计在大多数情况下升级过程中会出现的情况。 但是，对于具有不兼容更改的更复杂的自定义和部署，您可以按照中的说明将开发实例升级到AEM 6.5 执行就地升级. 完成后，在此环境中执行一些高级烟雾测试。 本练习的目标不是详尽地完成测试用例清单并生成正式的缺陷清单，而是粗略估计升级代码以实现6.5兼容性所需的工作量。 当与 模式检测 以及上节确定的架构变化，可向项目管理小组提供粗略的估计，以规划升级。

构建升级和回滚Runbook

虽然Adobe已记录升级AEM实例的流程，但每个客户的网络布局、部署架构和自定义都需要对此方法进行微调和定制。 因此，Adobe建议您查看提供的所有文档，并将其用于通知特定于项目的Runbook，其中概述了将在环境中遵循的特定升级和回滚过程。 如果从CRX2升级，请确保评估从CRX2迁移到Oak时内容迁移将花费的时长。 对于大型存储库而言，这可能非常庞大。

Adobe在中提供了升级和回滚过程 升级过程 以及执行中的应用升级的分步说明 就地升级. 您应该查看这些说明并与您的系统体系结构、定制和停机时间容差一起考虑，以确定在升级期间将执行的适当的切换和回滚过程。 在起草您的自定义Runbook时，应包括对架构或服务器大小所做的任何更改。 必须指出，这应作为第一稿处理。 当您的团队完成QA和开发周期并将升级部署到暂存环境时，可能需要执行一些其他步骤。 理想情况下，此文档应包含足够的信息，以便交给您的操作人员后，他们就可以完全根据文档中包含的信息完成升级。

制定项目计划

先前练习的输出可用于构建项目计划，涵盖测试或开发工作、培训和实际升级执行的预期时间线。

全面的项目计划应包括：

• 最终确定开发和测试计划
• 升级开发和QA环境
• 更新AEM 6.5的自定义代码库
• QA测试和修复周期
• 升级暂存环境
• 集成、性能和负载测试
• 环境认证
• 上线

执行开发和QA

Adobe为以下方面提供了程序 升级代码和自定义项 以与AEM 6.5兼容。在运行此迭代过程时，应根据需要对Runbook进行更改。 另请参阅 AEM 6.5中的向后兼容性 此信息介绍了自定义项如何保持向后兼容，通常在升级后无需立即开发。

开发和测试过程通常是迭代过程。 由于进行自定义设置，在升级期间进行的更改可能会导致产品的整个部分不可用。 一旦开发人员解决了问题的根本原因，并且测试团队有权测试这些功能，就有可能发现其他问题。 在发现需要调整升级过程的问题后，请确保将它们添加到您的自定义升级Runbook中。 在反复测试和修复之后，代码库应该经过完全验证并准备好部署到暂存环境。

最终测试

Adobe建议在代码库获得贵组织的QA团队认证后进行最后一轮测试。 此轮测试将涉及在暂存环境中验证您的Runbook，然后进行多轮用户验收、性能和安全性测试。

此步骤至关重要，因为这是您唯一一次能够针对类似生产的环境验证Runbook中的步骤。 升级环境后，请务必留出一些时间让最终用户登录，并完成他们在日常活动中使用系统时执行的活动。 用户使用系统中以前未考虑过的部分的情况并不少见。 在上线之前发现并纠正这些区域的问题，有助于防止代价高昂的生产中断。 由于AEM的新版本包含对基础平台的重大更改，因此，在系统上执行性能、负载和安全测试也很重要，就好像您是首次启动它一样。

执行升级

一旦从所有利益相关者那里收到最终签发，就应该按照定义的Runbook过程执行。 Adobe提供了升级和回滚的步骤 升级过程 和安装步骤执行 就地升级 作为参考点。

Adobe在环境验证的升级说明中提供了一些步骤。 这些功能包括一些基本检查，如扫描升级日志和验证所有OSGi捆绑包是否已正确启动，但Adobe建议也根据您的业务流程使用您自己的测试用例进行验证。 Adobe还建议检查AEM联机修订清理及相关例程的时间表，以确保在您的公司安静时间执行这些操作。 这些例程对于AEM的长期性能至关重要。