升级代码和自定义

注意

AEM 6.4已结束扩展支持，本文档将不再更新。 有关更多详细信息，请参阅 技术支助期. 查找支持的版本 此处.

在规划升级时，需要调查和解决实施的以下方面。

概述

  1. 图案检测器 — 运行模式检测器（如升级计划中所述），详见 本页 要获取模式检测器报表，该报表包含有关除Target版本的AEM中不可用的API/包之外，还需要解决的区域的更多详细信息。 模式检测报告应当指示代码中存在任何不兼容之处，如果不存在不兼容之处，则部署已兼容6.4，您仍可以选择使用6.4功能进行新开发，但您不仅需要它来保持兼容性。 如果报告了不兼容性，则您可以选择a)在兼容性模式下运行，并推迟开发以获得新的6.4功能或兼容性；b)在升级后决定进行开发，然后转到步骤2。 请参见 AEM 6.4中的向后兼容性 以了解更多详细信息。

  2. 开发适用于6.4的代码库 — 为Target版本的代码库创建专用分支或存储库。 使用升级前兼容性中的信息来规划要更新的代码区域。

  3. 使用6.4 Uber jar编译 — 更新代码库POM以指向6.4 uber jar，并针对此编译代码。

  4. 更新AEM自定义 — 应更新/验证对AEM的任何自定义或扩展，以便在6.4中正常工作，并将其添加到6.4代码库中。 包括UI搜索Forms、资产自定义，以及使用/mnt/overlay的任何内容

  5. 部署到6.4环境 — 在开发/QA环境中，应当停用AEM 6.4（创作+发布）的干净实例。 应该部署更新的代码库和具有代表性的内容示例（来自当前生产环境）。

  6. QA验证和错误修复 - QA应在6.4的创作实例和发布实例上验证应用程序。发现的任何错误都应修复并提交到6.4代码库。 根据需要重复开发周期，直到修复所有错误。

在继续升级之前，您应该拥有一个稳定的应用程序代码库，该代码库已针对目标版本的AEM进行了彻底测试。 根据测试中的观察，可以使用各种方法来优化自定义代码。 这可能包括重构代码以避免遍历存储库、自定义索引以优化搜索，或在JCR中使用未排序的节点等。

除了升级代码库和自定义以与新AEM版本配合使用的选项外， 6.4还有助于使用向后兼容性功能更高效地管理自定义，如 本页.

如上图所示，运行 图案检测器 在第一步中，您将帮助您评估升级的整体复杂性，以及您是要在兼容模式下运行，还是要更新自定义以使用所有新的AEM 6.4功能。 请参阅 AEM 6.4中的向后兼容性 页面以了解更多详细信息。
screen_shot_2018-03-30at175257

升级代码库

在版本控制中为6.4代码创建专用分支

您的AEM实施所需的所有代码和配置都应使用某种形式的版本控制进行管理。 应在版本控制中创建专用分支，以管理目标版本AEM中代码库所需的任何更改。 此分支将管理针对AEM目标版本对代码库进行的迭代测试和后续错误修复。

更新AEM Uber Jar版本

AEM Uber Jar将所有AEM API作为单个依赖项包含在您Maven项目的 pom.xml. 最好将Uber Jar作为单个依赖项包含在内，而不是包含单个AEM API依赖项。 在升级代码库时，应更改Uber Jar的版本，以指向目标版本的AEM。 如果您的项目是在AEM Jar存在之前基于Uber版本开发的，则所有单独的AEM API依赖项都应删除，并替换为目标版本AEM的Uber Jar中的单一包含。 然后，应根据新版Uber Jar重新编译代码库。 任何已弃用的API或方法都应进行更新，以与AEM的目标版本兼容。

<dependency>
    <groupId>com.adobe.aem</groupId>
    <artifactId>uber-jar</artifactId>
    <version>6.4.0</version>
    <classifier>apis</classifier>
    <scope>provided</scope>
</dependency>

逐步停用管理资源解析程序

通过 SlingRepository.loginAdministrative() 和 ResourceResolverFactory.getAdministrativeResourceResolver() 在AEM 6.0之前的代码库中非常普遍。这些方法由于安全原因而被弃用，因为它们提供的访问级别过于广泛。 在Sling的未来版本中，将删除这些方法. 强烈建议重构任何代码以改用服务用户。 有关服务用户和 如何逐步停用管理会话，可在此处找到.

查询和Oak索引

在升级代码库时，需要对代码库中查询的任何使用进行全面测试。 对于从Jackrabbit 2(AEM 6.0以上版本)升级的客户，这一点尤其重要，因为Oak不会自动为内容编入索引，并且可能需要创建自定义索引。 如果从AEM 6.x版本升级，则开箱即用的Oak索引定义可能已发生更改，并且可能会影响现有查询。

有几种工具可用于分析和检查查询性能：

经典UI创作

经典UI创作在AEM 6.4中仍可用，但现已弃用。 可以找到更多信息 此处. 如果您的应用程序当前在经典UI创作环境中运行，则建议升级到AEM 6.4并继续使用经典UI。 然后，可以将迁移到触屏UI作为单独的项目进行规划，以在多个开发周期内完成。 要在AEM 6.4中使用经典UI，需要将多个OSGi配置提交到代码库。 有关如何配置此选项的更多详细信息，请参阅 此处.

注意

要帮助您从经典UI转移到其他位置并利用最新的AEM技术，请考虑利用 AEM现代化工具 以便更轻松地进行迁移。

与6.4存储库结构保持一致

为了简化升级过程并确保配置在升级期间不被覆盖，在6.4中重组了存储库，以将内容与配置分离。

因此，必须将许多设置移动到下方，以便不再驻留 /etc 和过去一样。 要查看完整的、必须在更新到AEM 6.4的过程中审查和修正的存储库重组问题，请参阅 AEM 6.4中的存储库重组.

AEM自定义

需要识别AEM源版本中对AEM创作环境的所有自定义设置。 确定后，建议将每个自定义都存储在版本控制中，或作为内容包的一部分至少备份一次。 在生产升级之前，应在运行AEM目标版本的QA或暂存环境中部署和验证所有自定义设置。

一般情况下叠加

通常的做法是，通过在/libs下的节点和/或文件上叠加/apps下的其他节点，来扩展AEM的开箱即用功能。 应在版本控制中跟踪这些叠加，并针对AEM的目标版本进行测试。 如果文件（无论是JS、JSP、HTL）被覆盖，建议对已增强的功能留下注释，以便在AEM的目标版本上更轻松地进行回归测试。 有关一般叠加的详细信息，请参阅 此处. 有关特定AEM叠加的说明，请参阅下文。

升级自定义搜索Forms

自定义搜索彩块化需要在升级后进行一些手动调整，才能正常运行。 有关更多详细信息，请参阅 升级自定义搜索Forms.

资产UI自定义

注意

只有从AEM 6.2以前的版本升级时，才需要执行此过程。

需要为具有自定义资产部署的实例准备升级。 需要此功能才能确保所有自定义内容与新的6.4节点结构兼容。

您可以通过执行以下操作，为资产UI准备自定义设置：

  1. 在需要升级的实例上，通过转到 https://server:port/crx/de/index.jsp

  2. 转到以下节点：

    • /apps/dam/content

  3. 将内容节点重命名为 content_backup. 要执行此操作，请右键单击窗口左侧的资源管理器窗格，然后选择 重命名.

  4. 重命名节点后，在 /apps/dam 已命名 内容 将其节点类型设置为 sling:Folder.

  5. 移动的所有子节点 content_backup 到新创建的内容节点。 要执行此操作，请右键单击资源管理器窗格中的每个子节点，然后选择 移动.

  6. 删除 content_backup 节点。

  7. 下方更新的节点 /apps/dam 的节点类型正确 sling:Folder 理想情况下，应将其保存到版本控制中，并使用代码库进行部署，或至少作为内容包进行备份。

为现有资产生成资产ID

要为现有资产生成资产ID，请在升级AEM实例以运行AEM 6.4时升级资产。要启用 资产分析功能. 有关更多详细信息，请参阅 添加嵌入代码.

要升级资产，请在JMX控制台中配置关联资产ID包。 根据存储库中的资产数量， migrateAllAssets 可能需要很长时间。 我们的内部测试估计TarMK上的12.5万个资产大约需要1小时。

1487758945977

如果您需要为整个资产的子集使用资产ID，请使用 migrateAssetsAtPath API。

对于所有其他目的，请使用 migrateAllAssets() API。

InDesign脚本自定义

Adobe建议在 /apps/settings/dam/indesign/scripts 位置。 有关InDesign脚本自定义的更多信息，请参阅 此处.

恢复ContextHub配置

ContextHub配置会受升级的影响。 有关如何恢复现有ContextHub配置的说明可以找到 此处.

工作流自定义

通常做法是，更新开箱即用的修改工作流，以添加或删除不需要的功能。 自定义的常见工作流是DAM更新资产工作流。 自定义实施所需的所有工作流都应进行备份并存储在版本控制中，因为升级期间可能会覆盖这些工作流。

可编辑模板

注意

只有使用AEM 6.2中的可编辑模板进行站点升级时，才需要执行此过程

可编辑模板的结构在AEM 6.2和6.3之间发生了更改。如果您从6.2或更早版本进行升级，并且如果您的网站内容是使用可编辑的模板构建的，则需要使用 响应式节点清理工具. 该工具用于运行 after 升级以清理内容。 它需要同时在创作层和发布层上运行。

CUG实施更改

已关闭的用户组的实施已发生重大更改，以解决以前版本的AEM中存在的性能和可扩展性限制。 6.3中已弃用CUG的先前版本，并且仅触屏UI支持新实施。 如果您从6.2或更低版本升级，则可以找到迁移到新CUG实施的说明 此处.

测试过程

应为测试升级准备全面的测试计划。 首先，需要在较低的环境中测试已升级的代码库和应用程序。 发现的任何错误都应以迭代方式修复，直到代码库稳定为止，只有这样才应升级更高级别的环境。

测试升级过程

应按照自定义运行手册中的说明，在开发和QA环境中对此处概述的升级过程进行测试(请参阅 规划升级)。 应重复升级过程，直到升级运行手册中记录了所有步骤，并且升级过程顺利。

实施测试区域

以下是任何AEM实施的关键区域，在升级环境并部署升级的代码库后，测试计划应涵盖这些区域。

功能测试区 描述
已发布的站点 在发布层测试AEM实施和关联代码
通过调度程序。 应包括页面更新标准和
缓存失效。
创作 在创作层测试AEM实施和关联代码。 应包括页面、组件创作和对话框。
与Marketing Cloud解决方案集成 验证与Analytics、DTM和Target等产品的集成。
与第三方系统集成 应在创作层和发布层上验证任何第三方集成。
身份验证、安全性和权限 应验证任何身份验证机制，如LDAP/SAML。
应在“创作”和“发布”两个页面上测试权限和组
层。
查询 自定义索引和查询应与查询性能一起进行测试。
UI自定义 创作环境中对AEM UI的任何扩展或自定义设置。
工作流 自定义和/或开箱即用的工作流和功能。
性能测试 应对模拟真实情景的创作层和发布层执行负载测试。

文档测试计划和结果

应创建涵盖上述实施测试区域的测试计划。 在很多情况下，可以按“创作”和“发布”任务列表来分隔测试计划。 在升级生产环境之前，应在开发、QA和暂存环境中执行此测试计划。 应在较低的环境中捕获测试结果和性能量度，以便在升级暂存环境和生产环境时进行比较。

在此页面上