单击此处阅读英语博客

Bot Lifecycle Management – Bring Calm to Your Bot Development Chaos

写的 Kashif Mahbub 通过自动化为世界带来改变 上 September 26, 2018

DevOps 软件工程方法将开发与运营合为一体,大大提高了软件发布速度。很有可能,如今的 DevOps 原理通过提供一个执行持续集成和部署的框架,为开发团队提供流程指导。采用 DevOps 方法开发软件时,会遵循开发、测试、验收和实际部署的生命周期 (DTAP)。拥有大规模(尤其是分散式)开发团队的组织采用 DevOps 方法后,在软件开发生命周期 (SDLC) 流程中已经看到了显著改进。因此,采用相同的 DevOps 方法开发企业级的机器人流程自动化 (RPA) 机器人是完全合理的。

目前的大部分 RPA 解决方案所提供的能力能帮助用户将机器人从开发生命周期的一个阶段转移到下一个阶段。这是否意味着它们支持采用 DevOps 方法实现机器人生命周期管理 (BLM)?不。简单地推动机器人在 DevOps 生命周期中移动便构成 BLM 的想法是一种误解。但同许多其他误解一样,如果不仔细推敲,它听上去似乎很有道理。

DevOps 和 BLM 不是一回事

DevOps 生命周期中的每一个环节都在单独的环境中发生。开发和测试在各自不同的环境中进行。实际部署也是一样。因此,要管理一个机器人的生命周期,则需根据机器人在生命周期中所处的具体阶段,维护相应的机器人环境。而且还需将整个机器人包在不同阶段之间转移。

比如您要创建机器人 A。机器人 A 要依赖于单独的流程 A.1、A.2 和 A.3 才能有效运行。机器人及其依赖项需作为一个完整的包进行管理,并经历机器人生命周期。“那还用说。”您道。但大部分 RPA 解决方案并非如此。它们只能在您提供的环境之间导入和导出机器人。您需要单独管理机器人依赖项。“真的?听上去很麻烦。”您或许会这样说。是真的。的确,任何一个 RPA 程序管理员都会这样说,这的确很麻烦。

Automation Anywhere Enterprise

DevOps 在机器人开发环境中

如果缺少一个真正的 BLM 框架,您必须建立并管理自己的开发和测试环境。还必须单独管理和移动依赖项。这可能适合 RPA 概念验证,但它无法扩展。您使用打断的流程管理的机器人越多,实际部署机器人所需的时间就越长。而且,如果缺少依赖项,还可能会出现更多错误,耽误持续集成和部署。

合规性也会成为问题。如果机器人参与的流程涉及到合规要求,例如受萨班斯-奥克斯利 (SOX) 法案约束的财务流程,若缺少真正的 BLM 框架,您将不得不单独开发和管理对机器人的控制权。

BLM 支持扩展

Automation Anywhere Enterprise 中所纳入的 BLM 框架不仅仅是导入和导出机器人这么简单,它可以即时与 DevOps 工作流集成。内在地支持单独的开发、测试、验收和实际部署环境,包括完整的版本控制和撤回功能。

高度精细的基于角色的访问控制 (RBAC) 也是企业保证 Enterprise RPA 平台安全性所必须配置的功能。凭借精细的 RBAC,机器人可以在 DevOps 生命周期的不同阶段之间无缝转移。那么依赖项呢?依赖项随机器人一起转移。因此,Automation Anywhere Enterprise 才能在机器人生命周期中管理整个机器人包。实现了对版本、角色和机器人包的控制,即使合规要求再严格,也能更加高效地开发更多机器人。您可以将 RPA 迅速扩展到整个企业,在更短的时间内获得更高的投资回报,这也是一个明智的企业级 RPA 战略的标志。

立即申请 Automation Anywhere Enterprise 平台演示版,零距离体验机器人生命周期管理。