升级代码和自定义

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

概述

  1. 模式检测器 — 运行模式检测器(如升级计划中所述,详见本 🔗 页),以获取模式检测器报告,该报告包含有关除AEM Target版本中不可用的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打开CRXDE Lite

  2. 转到以下节点:

    • /apps/dam/content
  3. 将内容节点重命名为​content_backup。 为此,可以右键单击窗口左侧的资源管理器窗格并选择​重命名

  4. 重命名节点后,在名为​content​的/apps/dam下创建一个名为content的新节点,并将其节点类型设置为​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或更早版本进行升级,并且如果您的网站内容是使用可编辑模板构建的,则需要使用响应式节点清理工具。 该工具用于在​升级后运行​以清理内容。 它需要同时在创作层和发布层上运行。

CUG实施更改

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

测试过程

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

测试升级过程

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

实施测试区域

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

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

文档测试计划和结果

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

在此页面上