规划升级
创建对象：
- 开发人员
AEM项目概述
AEM通常用于可能为数百万用户提供高影响力的部署。 在大多数情况下，实例上部署了自定义应用程序，这增加了复杂性。 升级此类部署的任何努力都需要有条不紊地加以处理。
本指南可帮助在规划升级时建立明确的目标、阶段和交付项。 它侧重于项目的整体执行和准则。 虽然它提供了实际升级步骤的概述，但是它参考了适当的可用技术资源。 它应与文件中提到的可用技术资源结合使用。
AEM升级过程需要谨慎处理规划、分析和执行阶段，并为每个阶段定义关键交付项。
请注意，可以直接从AEM 6.0版和最高6.4版升级。运行5.6.x及以下版本的客户需要先升级到6.0或更高版本，并推荐使用6.0(SP3)。 此外，自6.3起，新的OAK区段Tar格式现在用于区段节点存储，而且即使对于6.0、6.1和6.2，存储库也必须迁移到这种新格式。
CAUTION升级范围和要求
在下面，您会找到一个典型AEM升级项目中受影响的区域列表：
磁盘空间等于存储库大小的25%，可用堆空间为15%
成功完成。 您可能需要将硬件升级到
确保有足够的资源进行在线修订清理，以充分
执行。 此外，如果从AEM 6之前的版本升级，则
可能是其他存储要求。
从旧版本升级时，需要使用Oak(CRX3)。 AEM 6.3已
实施了新的区段节点存储，该存储区也需要迁移。 的
crx2oak工具用于此目的。
/libs 和 /apps 通过升级可轻松处理，但 /etc 通常需要手动重新应用一些自定义设置。对JVM、操作系统版本和某些与索引相关的依赖
更改，因为索引不会在Oak中自动生成。
升级之前，将其移回存储库。
大多数内容都可以通过迁移工具进行处理。
请务必确保您运行的是受支持的操作系统、Java运行时、httpd和Dispatcher版本。 有关更多信息，请参阅 AEM 6.4技术要求页. 升级这些组件需要在您的项目计划中进行说明，并且应在升级AEM之前进行。
项目阶段
规划和执行AEM升级需要做很多工作。 为了澄清这一进程中的不同努力，我们将规划和执行练习分为不同的阶段。 在以下各节中，每个阶段都会生成一个交付项，该项目的未来阶段通常会利用该交付项。
创作培训计划
在任何新版本中，都可能会对UI和用户工作流进行潜在的更改。 此外，新版本还引入了一些新功能，这些功能可能有助于企业利用这些功能。 我们建议您审查已引入的功能更改，并组织一个计划，以培训您的用户如何有效利用这些功能。
AEM 6.4的新增功能可在 adobe.com的AEM部分. 请务必注意对组织中常用的UI或产品功能所做的任何更改。 在您查看新增功能时，还应注意任何对贵组织有价值的功能。 查看AEM 6.4中的更改后，为您的作者制定培训计划。 这可能涉及利用免费提供的资源，例如通过提供的帮助功能视频或正式培训 Adobe数字学习服务.
创建测试计划
每个客户对AEM的实施都是独特的，并且经过自定义以符合其业务要求。 因此，务必确定对系统进行的所有自定义设置，以便将它们包含在测试计划中。 此测试计划将为我们在升级实例上执行的QA过程提供动力。
需要复制确切的生产环境，并在升级后对其执行测试，以确保所有应用程序和自定义代码仍按需要运行。 您需要重新执行所有自定义设置，并执行性能、负载和安全测试。 在组织测试计划时，除了开箱即用的UI和日常操作中利用的工作流之外，还要确保涵盖对系统进行的所有自定义设置。 这些功能包括自定义OSGi服务和Servlet、与Adobe Marketing Cloud的集成、通过AEM连接器与第三方的集成、自定义第三方集成、自定义组件和模板、AEM中的自定义UI叠加以及自定义工作流。 对于从AEM 6之前的版本迁移的客户，应当分析任何自定义查询，因为它们可能需要编入索引。 对于已使用AEM 6.x版本的客户，仍应对这些查询进行测试，以确保其索引在升级后继续有效工作。
确定所需的体系结构和基础架构更改
升级时，您可能还需要升级技术堆栈中的其他组件，如操作系统或JVM。 此外，由于存储库组成中的更改，可能需要额外的硬件。 这通常仅适用于从6.x以前的实例迁移的客户，但务必要考虑这一点。 最后，您的操作实践可能需要做出一些更改，包括监控、维护以及备份和灾难恢复过程。
查看AEM 6.4的技术要求，并确保您当前的硬件和软件都足够。 有关操作流程的潜在更改，请参阅以下文档：
监控和维护：
备份/恢复和灾难恢复：
内容重组注意事项
AEM 6.4对存储库结构进行了更改，有助于使升级更加无缝。 更改涉及根据Adobe或客户是否拥有该内容，将内容从/etc文件夹移出到包括/libs、/apps和/content的文件夹，从而限制在发布期间覆盖内容的可能性。 存储库重组的完成方式是，在6.4升级时，它不应要求进行代码更改，不过建议在 AEM 6.4中的存储库重组 计划升级时。
评估升级复杂性
由于我们的客户在其AEM环境中所应用的自定义项的数量和性质多种多样，因此请务必提前一段时间来确定在升级过程中应该付出的总体工作量。
您可以采用两种方法来评估升级的复杂性，初步阶段只能使用新引入的模式检测器，该检测器可在AEM 6.1、6.2和6.3实例上运行。 模式检测器是使用报告的模式来评估升级的整体复杂性的最简单的方法。 模式检测器报告包含用于识别自定义代码库正在使用的不可用API的模式（这是使用6.3中的升级前兼容性检查来完成的）。
初次评估后，更全面的下一步可能是对测试实例执行升级，并执行一些基本的烟雾测试。 Adobe还提供了一些。 此外， 已弃用和已删除的功能 不仅应对您要升级到的版本进行审核，还应对源版本与目标版本之间的任何版本进行审核。 例如，如果从AEM 6.2升级到6.4，那么除了AEM 6.4的功能之外，还务必要查看已弃用和已删除的AEM 6.3功能。
6.4中引入的模式检测器对于大多数情况，在升级过程中应提供相当准确的估计。 但是，对于更复杂的自定义和部署，如果您有不兼容的更改，则可以按照 执行就地升级. 完成后，在此环境中执行一些高级烟雾测试。 本练习的目标不是详尽地完成测试用例清单并生成缺陷的正式清单，而是粗略地估计升级代码以实现6.4兼容性所需的工作量。 与 模式检测 以及前一节中确定的体系结构变化，可以向项目管理团队提供粗略估计，以规划升级。
构建升级和回滚Runbook
虽然Adobe记录了升级AEM实例的过程，但每位客户的网络布局、部署架构和自定义将需要对此方法进行微调和定制。 因此，我们建议您查看我们提供的所有文档，并使用这些文档来通知特定于项目的Runbook，其中概述了您将在环境中遵循的特定升级和回滚过程。 如果从CRX2升级，请确保评估从CRX2迁移到Oak时内容迁移的时长。 对于大型存储库，其数量可能很大。
我们在 升级过程 以及执行 就地升级. 这些说明应与您的系统架构、自定义和停机时间容限一起审核并加以考虑，以确定在升级期间将执行的适当切换和回滚过程。 在起草自定义Runbook时，应包含对架构或服务器大小的任何更改。 必须指出，这应作为第一稿处理。 当您的团队完成其QA和开发周期并部署到暂存环境的升级时，可能需要执行一些其他步骤。 理想情况下，本文档应包含足够的信息，这样，如果将信息交给您的业务人员，他们将能够完全从中包含的信息完成升级。
制定项目计划
我们可以利用先前练习中的输出，构建一个项目计划，涵盖测试或开发工作、培训以及实际升级执行的预期时间表。
综合项目计划应包括：
-
最后确定发展和测试计划
-
升级开发和QA环境
-
更新AEM 6.4的自定义代码库
-
QA测试和修复周期
-
升级暂存环境
-
集成、性能和负载测试
-
环境认证
-
上线
执行开发和QA
我们为 升级代码和自定义 与AEM 6.4兼容。在执行此迭代过程时，应根据需要对runbook进行更改。 另请参阅 AEM 6.4中的向后兼容性 关于自定义设置在大多数情况下如何保持向后兼容，而无需在升级后立即进行开发的信息。
开发和测试过程通常是一个迭代过程。 由于自定义，升级期间所做的更改可能会使产品的整个部分无法使用。 开发人员解决了问题的根本原因，并且测试团队有权测试这些功能后，便有可能发现其他问题。 由于发现需要调整升级过程的问题，请确保将其添加到您的自定义升级Runbook中。 经过几次测试和修复迭代后，应充分验证代码库并准备好部署到暂存环境。
最终测试
在代码库已通过贵组织的QA团队的认证后，我们建议进行最后一轮测试。 本轮测试将涉及在测试环境中验证您的Runbook，然后进行用户接受、性能和安全测试。
此步骤至关重要，因为这是您能够针对类似生产的环境验证Runbook中的步骤的唯一时间。 升级环境后，请务必让最终用户有时间登录并完成其在日常活动中使用系统时执行的操作。 用户在系统中使用之前未考虑的部分功能的情况并不罕见。 在上线前查找并更正这些区域的问题有助于防止成本高昂的生产中断。 由于新版AEM包含对基础平台的重大更改，因此在系统上执行性能、加载和安全测试也很重要，就像我们首次启动它一样。
执行升级
在从所有利益相关方收到最终签名后，便可以在已定义的Runbook程序上执行。 我们提供了升级和回滚的步骤 升级过程 和安装步骤 就地升级 作为参考点。
我们在环境验证的升级说明中提供了一些步骤。 这些检查包括基本检查，例如扫描升级日志并验证所有OSGi包是否已正确启动，但我们也建议根据您的业务流程使用您自己的测试案例进行验证。 我们还建议检查AEM在线修订清理的计划和相关例程，以确保这些例程将在公司的安静时间发生。 这些例程对于AEM的长期性能至关重要。