Automation 360 软件生命周期政策

Automation Anywhere 软件生命周期政策旨在为您快速提供创新和增强功能。 通过此政策,我们为您提供可预测性、质量,更重要的是,您可以不受干扰地获得最新的创新和增强功能,从而控制采用这些增强功能的时间和方式。

注: 本页提到的政策适用于 Automation 360 CloudOn-Premises 部署,除非明确指出两者的不同之处。

概述

软件生命周期策略可帮助您进行变更管理,同时通过 Control RoomBot Agentpackages 中的增强功能为您提供最新的软件更新。

我们的政策旨在提供更快的功能访问、错误修复和其他增强功能,以获得更好的客户体验。
  • 可预测性: 通过频繁、定期的部署周期,您可以比以前更快地获得新的和增强的 packages,并且可预测发布节奏。
  • 部署新增功能: 通过控制对您的 bots 进行更改,您可以按照自己的节奏测试新功能并进行部署。
  • 质量: 通过来自 Automation 360 Cloud 的自动化部署,可以使用包含关键错误和安全修复的新 packages
  • 非破坏性访问: 可以在不影响现有配置的情况下更新软件包。
  • 向后兼容性: 现在可以安全地更新 bots,同时仍可以选择切换回 package 的先前版本。

以下图像显示了此生命周期策略的优点:

图像显示了在 Automation 360 中使用软件包的优势

Control Room

Automation 360 利用最新的最佳实践,通过持续开发和部署管道在所有部署模型中开发和推出增量软件更新。Automation 360 Control Room 软件更新大约每 3 个月发布一次。

通常按以下顺序推出更新:

  • Community EditionCloud-Sandbox: 这些 Cloud 环境会自动更新,并且事先在 Automation 360 Cloud Service Status site 上发布通知。 作为客户,您可以使用 Cloud-Sandbox Control Room 环境,在主要开发 (Dev)、测试(Test 或 UAT)和实际正式 (Prod) Cloud 环境更新之前,至少提前 3 周试用下一个更新。
  • Automation 360 On-Premises Control Room: 在 A-People Downloads page (Login required) 上,On-Premises 环境于 Community EditionCloud-Sandbox 之后发布。 客户需要从下载页面手动下载更新并更新 Control Room 实例。
  • Automation 360 Cloud: Cloud 环境会在提前通知的情况下自动更新。 这些更新通常在 Cloud-Sandbox 更新后三到四周部署。 这些云更新计划在非工作时间进行,并且不会在月初或月末进行。Cloud 更新通知会在更新前 2 周在 Automation 360 Cloud Service Status site 上发布。

Automation 360 软件更新包含所有新功能的累积。 根据我们的软件更新政策,只有在最新版本的软件更新中才会修复漏洞。 尽管我们支持 n-2 版本(其中 n 指的是最新版本)用于 On-Premises 部署,但我们建议 On-Premises 客户更新到最新版本,以便从最新功能和错误修复中受益。

Bot Agent 更新

当新版本的 Bot Agent 可用时,默认情况下,Bot Agent 会自动部署到客户的设备池中,而不会影响现有的 bot 功能。 然而,Control Room 管理员可以禁用此默认更新功能,并选择手动更新 Bot Agent。 在手动更新和强制更新的情况下,用户将被通知必须更新 Bot Agent,并且将停止这些设备上的所有 bot 的执行直到 Bot Agent 更新为止。

对于较大规模的部署,其中设备池使用标准设备 Amazon Machine Images (AMI) 按单独计划进行部署,这些更新将在客户环境中需要协调、更改管理流程和批准。 因此,Automation 360 将支持向后兼容 Bot Agent,每 6 个月发布一次。

Automation 360 v.24 版本开始,每年将发布 4Bot Agent 更新,其中包括 2 个可选2 个可能被宣布为强制性的更新。 您可以跳过可选更新,直接更新到下一个强制性 Bot Agent 更新。

我们的第二季度和第四季度发布将提供可选的 Bot Agent 更新,您可以选择跳过 Bot Agent 更新。 然而,第一季度和第三季度的更新可能包含强制性的 Bot Agent 更新。 我们将在需要使用 Control Room 版本进行强制性的 Bot Agent 更新时提前 3 个月通知客户。 有关更多信息,请参阅 Bot Agent compatibility

注: 我们强烈建议客户每 6 个月更新一次 Bot Agent 实例,以确保兼容性并从最新的创新中受益。

Package 更新

Automation 360 v.24 版本开始,packages 的交付将与主平台更新分开进行开发。 这将有助于我们对所需的更改和修复做出快速反应,并为今后以 packages 形式提供更新提供灵活性。

借助此功能,当新的 packages 和新的 package 版本按照季度发布节奏有规律地发布时,现在可以从 Automation Anywhere Cloud 自动下载。 下载的 packages 将成为默认 package,以便在 package 版本可用时客户可以开始持续使用这些版本。

此功能在 CloudOn-Premises Control Room 实例中启用的方式不同,如下表所示:

无缝 package 更新功能 Cloud Control Room On-Premises Control Room
Automation Anywhere Cloud 下载 packages 默认启用且无法禁用。 默认禁用,可以启用。
将已下载的 package 设置为默认版本 默认启用,可以禁用。 默认启用,可以禁用。
  • Cloud 用户: 现在,所有区域的所有 Control Room 实例都已启用自动 package 下载功能。

    在您的地区提供 Control Room 更新之前,您可以在当前 Control Room 版本上开始使用最新的 packages

  • On-Premises 用户: 此功能默认禁用,但可以由 package 管理员启用。

我们建议 bot 开发人员始终使用最新版本的 packages,因为该版本提供了最新的创新以及之前版本的所有代码和安全修复。 然而,管理员可以随时更改此默认行为,并在验证后将 packages 发布给开发人员。 这些新的 package 版本也向后兼容现有平台版本。

请注意,此功能不会影响现有的 bots,其将继续运行,不会有任何变化。使用特定 package 版本开发的 Bots 将继续保持此状态,除非由 bot 开发人员明确更改。 这为 bot 开发人员提供了在准备妥当时采用新 package 版本的灵活性。Bot 开发人员必须在 Bot editor 视图中明确编辑 bots 并使用新 package 版本。

packages 的支持和弃用政策

packages 的支持和弃用政策旨在提供 bot 的长期使用性,并减少整体维护工作以保持 bots 更新。 设计考虑是尽量减少保持机器人正常运行所需的 bot 更改。
注: 此政策自 Control Room 版本 v.23 起生效。
Package 版本支持至少 2 年
发布的 Package 版本将在发布后至少支持 2 年。 即使在 2 年后,package 版本仍将继续得到支持,除非被弃用。

通常,如果 package 弃用,将会提供新版本的 package。 所有报告的 package 问题和安全修复将在最新版本中解决,不会向后移植。

当计划弃用 package 版本时,您将提前 3 个月收到通知。 如果存在严重的安全漏洞,我们将尽最大努力提前发送通知。

Packages 版本与 Bot AgentControl Room 的兼容性
使用这些版本的软件包版本和 bots 未来将与 package 版本发布后 2 年内发布的所有 Control RoomBot Agent 版本兼容。使用这些受支持的软件包版本的 Bots 无需配置即可与 Control RoomBot Agent 版本兼容。
关于 package 版本的弃用政策
Package 版本在发布后的 2 年内不会被弃用,除非存在必须修复的严重安全漏洞。 在这种情况下,将提供一个包含修复程序的新 package 版本。
最小化的 bot 更改
package 版本支持政策的目标是尽量减少更改现有 bots 所需的工作,并保持其正常运行。

如果支持现有的 package 版本,使用特定 package 版本的 Bots 无需更新即可使用 package 版本。 然而,我们建议您在开发 bot 时使用最新版本的 package,以延长 bot 的使用寿命。 在 bot 中使用的 package 版本必须在弃用之前更新,以便持续支持 bot

API 弃用策略

API 弃用 表示不再推荐使用该 API,但它仍然是可用的。 鼓励开发人员迁移到更新的、受支持的 API 版本。 该 API 将可用至生命周期结束 (EoL) 日期和发布版本,以确保平稳过渡。

API 生命周期结束 (EoL) 表示 API 停止运行并不再可用的日期和发行版本。 开发人员应在此日期之前完成向较新、受支持的 API 版本的迁移。

以下情形可能需要弃用 API:

  • 安全漏洞: 旧版本的 API 包含已在新版本中修复的已知安全漏洞。
  • 技术债务: 旧的 API 版本可能基于不再受支持的过时技术、方法或框架,因此很难进行维护或增强。
  • 性能: 较旧的 API 版本没有针对现代场景或规模的扩大进行优化,导致性能低下和响应时间变慢。
  • 用户体验: 已弃用的 API 版本包含令人困惑或冗余的端点,可能会使用户难以导航。

API 的支持期至少为 2 年。 2 年后,可能会宣布某个 API 弃用,该 API 将至少再提供一年(四个版本),以便为您提供足够的时间迁移到更新的版本。

注: 上述策略不适用于因公共 API 的安全漏洞而导致的弃用。 在这种情况下,需要立即采取行动以降低风险,我们将尽一切努力尽快将这一变更通知您。

Bot 生命周期

bots 的设计假设是,bots 中使用的 package 版本用于运行 botsControl Room 中存在。 在开发人员推广 bots 之前,我们建议开发人员验证 bots 中使用的 package 版本是否与更高环境中的 package 版本匹配。

在将 bots 推广到较低软件版本的更高环境(例如,测试和实际正式)时,确保包含 bots 的依赖 packages。 这将确保目标环境具备 bot 所需的所有 package 版本。
注: 某些 package 版本不会向后兼容 Control RoomBot Agent 的早期版本。 因此,请避免在 Control Room 环境更新阶段使用此类不兼容的 package 版本。