升级代码和自定义项 upgrading-code-and-customizations
在计划升级时，必须调查并解决实施的以下方面。
概述 overview
- AEM Analyzer — 按照升级计划中的说明运行AEM Analyzer，在使用AEM Analyzer评估升级复杂性页面中有详细介绍。 您会获得一个AEM Analyzer报告，该报告包含有关在AEM的Target版本中不可用的API/捆绑包之外，还必须解决的区域的更多详细信息。 AEM Analyzer报告会向您指示代码中的任何不兼容性。 如果不存在任何部署，则表明您的部署已经与6.5 LTS兼容。 您仍然可以选择为使用6.5 LTS功能而执行新开发，但并非只是为了保持兼容性。
- 开发6.5 LTS的代码库 — 为Target版本的代码库创建专用分支或存储库。 使用升级前兼容性中的信息来规划要更新的代码区域。
- 使用6.5 LTS Uber jar编译 — 更新代码库POM以指向6.5 LTS uber jar并编译针对它的代码。
- 部署到6.5 LTS环境 - AEM 6.5 LTS的干净实例（创作+发布）应出现在开发/QA环境中。 应部署更新后的代码库和有代表性的内容示例（来自当前生产）。
- 蚕础验证和错误修复 - QA应在6.5 LTS的创作实例和发布实例上验证应用程序。 找到的任何错误都应修复并提交到6.5 LTS代码库。 根据需要重复Dev-Cycle，直到修复所有错误。
在继续升级之前，您应该有一个稳定的应用程序代码库，此代码库已针对AEM 6.5 LTS进行了全面测试。
升级代码库 upgrade-code-base
在版本控制中为6.5 LTS代码创建专用分支 create-a-dedicated-branch-for-6.5-lts-code-in-version-control
应使用某种形式的版本控制来管理实施AEM所需的所有代码和配置。 应创建版本控制中的专用分支，以管理目标版本AEM中的代码库所需的任何更改。 此分支管理针对AEM的目标版本迭代测试代码库以及后续错误修复。
更新AEM Uber Jar版本 update-the-aem-uber-jar-version
AEM Uber jar将所有AEM API作为单个依赖项包含在您的Maven项目的pom.xml中。 最佳做法始终是将Uber Jar作为单个依赖项包含在内，而不是包含单个AEM API依赖项。 升级代码库时，将Uber Jar的版本更改为指向AEM的6.5 LTS版本。 更新任何已弃用的API或方法，以便与AEM的目标版本兼容。 针对新版本的Uber Jar重新编译代码库。
<dependency>
<groupId>com.adobe.aem</groupId>
<artifactId>uber-jar</artifactId>
<version>6.6.0</version>
<classifier>apis</classifier>
<scope>provided</scope>
</dependency>
适用于AEM 6.5的? Uber Jar
uber-jar-6.5.x.jar— 包含AEM 6.5的所有公共API。uber-jar-6.5.x-apis-with-deprecations.jar— 包括AEM 6.5中的公共API和已弃用的API。
适用于AEM 6.5 LTS的? Uber Jar
对于AEM 6.5 LTS，再次存在两种类型的Uber Jar：
uber-jar-6.6.x-apis.jar— 包含AEM 6.5 LTS的所有公共API。uber-jar-6.6.x-deprecated-apis.jar— 仅包含AEM 6.5 LTS中已弃用的API。
主要区别： AEM 6.5与AEM 6.5 LTS Uber Jar
- 在AEM 6.5中，如果同时需要公共的和已弃用的API，则可以在
pom.xml文件中使用包含单个箩补谤uber-jar-6.5.x-apis-with-deprecations.jar。 - 在AEM 6.5 LTS中，如果您同时需要公共API和已弃用的API，则必须包含两个单独的jar，即公共API的
uber-jar-6.6.x-apis.jar和已弃用的础笔滨的uber-jar-6.6.x-deprecated-apis.jar。
已弃用的API Jar的? 惭补惫别苍坐标
<dependency>
<groupId>com.adobe.aem</groupId>
<artifactId>uber-jar</artifactId>
<version>6.6.0</version>
<classifier>apis</classifier>
<scope>provided</scope>
</dependency>
开发人员备注 developer-notes
- AEM 6.5 LTS不包括现成的Google guava库，可以根据需要安装所需的版本。
- Sling XSS包现在使用Java HTML清理器库，应使用
XSSAPI#filterHTML()方法安全地呈现贬罢惭尝内容，而不是将数据传递到其他础笔滨。
测试过程 testing-procedure
应该为测试升级准备全面的测试计划。 测试已升级的代码库和应用程序必须先在较低的环境中完成。 发现的错误应以迭代方式修复，直到代码库稳定为止，只有到那时才应升级更高级别的环境。
测试升级过程 testing-upgrade-procedure
此处概述的升级过程应在开发和蚕础环境中进行测试，如自定义运行手册中所述（请参阅计划升级）。 应重复升级过程，直到所有步骤都记录在升级运行手册中且升级过程顺利完成。
实施测试区域 implementation-test-areas-
以下是任何础贰惭实施的重要方面，在升级环境并部署升级的代码库后，测试计划应涵盖这些方面。
记录测试计划和结果 document-test-plan-and-results
应创建涵盖上述实施测试区域的测试计划。 通常，按作者和发布任务列表划分测试计划是合理之举。 此测试计划应在升级生产环境之前在开发、QA和暂存环境中执行。 测试结果和性能量度应在较低级别环境中捕获，以便在升级暂存环境和生产环境时进行比较。