AEM 版本更新 aem-version-updates

了解Adobe Experience Manager (AEM) as a Cloud Service如何使用持续集成和交付(CI/CD)将您的项目保持在最新版本上。

CI/CD ci-cd

AEM as a Cloud Service使用持续集成和持续交付(CI/CD)，以确保您的项目使用的是最新的AEM版本。 此过程可无缝更新您的生产、暂存和开发实例，而不会造成任何用户中断。

在自动更新实例之前，将提前3-5天发布新的AEM维护版本。 在此期间，您的开发实例可能会自动更新，如果该实例可用，您可以选择触发开发实例的更新。 版本更新首先自动应用于您的开发环境。 如果更新成功，则更新流程将继续到暂存和生产实例。 开发和暂存实例充当自动化的质量关卡，在生产环境应用更新之前，可在其中运行自定义编写的测试。

NIMU（非侵入式维护更新） nimu

非侵入式维护更新是自动更新，应用时不会涉及客户管道。
通过NIMU，客户随时可以使用管道，即使已计划或正在进行AEM版本更新，并且维护更新将不再出现在客户管道执行历史记录中，从而更容易遵循代码部署历史记录。

更新活动

与之前一样，使用Cloud Manager UI环境面板仍然可以检查每个环境的当前AEM版本。 非侵入式维护更新（包括客户编写的测试）使用管道中使用的相同质量审核。
每当对程序的环境应用非侵入式维护更新时，将发送Cloud Manager UI通知。 您可以将其配置为也发送到您的电子邮件。

更新类型 update-types

有两种类型的 AEM 版本更新：

更新失败 update-failure

AEM更新需要执行大量且完全自动化的产品验证管道，该管道包含多个步骤，可确保生产中的任何系统都不会出现服务中断。 运行状况检查用于监视应用程序的运行状况。 如果这些检查在AEM as a Cloud Service更新期间失败，则发布不会继续，并且Adobe会调查更新导致此意外行为的原因。

当您在环境中部署新版本的自定义代码时，产品和自定义功能测试将发挥关键作用。 它们可确保生产系统在应用更改后仍保持稳定和正常运行。 这些测试还应用于AEM版本更新过程。

如果对生产环境的更新失败，Cloud Manager会自动回滚到暂存环境。 此操作将自动完成，以确保在更新完成后，暂存环境和生产环境均采用同一个AEM版本。
同样，如果自动更新开发环境失败，则不更新暂存环境和生产环境。

最佳实践 best-practices

回归 regression

如果您遇到与回归相关的问题，请通过Admin Console提交支持案例。 如果问题为阻止程序且影响生产，则应引发P1。 提供重现回归问题所需的所有详细信息。

复合节点存储 composite-node-store

通常，更新会产生零停机时间，包括创作实例（节点集群）的停机时间。 由于Oak中的复合节点存储功能，可能会进行滚动更新。

此功能允许AEM同时引用多个存储库。 在滚动部署中，新AEM版本包含其自己的/libs （基于TarMK的不可变存储库）。 它与旧版AEM不同，不过两者都引用基于DocumentMK的共享可变存储库，该存储库包含/content、/conf、/etc等区域。

由于旧版本和新版本都有各自的/libs版本，因此在滚动更新期间它们都可以处于活动状态。 而且，在旧设备完全被新设备取代之前，这两种设备都可以承受流量。