Rundeck Enterprise 作业/工作流的部署和测试策略

如何解决Rundeck Enterprise 作业/工作流的部署和测试策略

我们正在评估 rundeck 企业，以便在我们的企业基础架构设置中采用。我有 2 个高级问题/疑问，我认为它们同样适用于 rundeck 企业或开源。

背景： 我们有一个现有的专有工具，我们希望将其移出并为我们一直在做的所有自动机采用 rundeck。

我们在寻找什么：

1. 以迭代方式将所有现有自动机移植到 rundeck - 这可以通过 SCM 插件并使用适当的开发生命周期在较低环境中构建和测试作业，然后推出以倾倒生产 rundeck 环境。
2. Rundeck Job/Projects Rollout 策略 - 使用基于 Canary 的方法的变体，我们让 rundeck 作业根据百分比或一天中的时间选择一定数量的可操作项目（例如，相同逻辑类型的 ServiceNow 票证）或ServiceNow 票证 ID 等的前缀/后缀模式。
3. 回滚策略 - 因此，当部署发生时，基于 Canary 或完全部署，我们发现相应的 rundeck 作业不像现有专有工具上的相同作业那样正常工作，我们回滚 rundeck 作业并修复错误。问题解决后，再次计划推出。
4. 在较低环境下测试 Rundeck 作业 - 单元和集成不仅测试作业/工作流，还测试我们开发的脚本、插件等。

问题：

1. 在将 rundeck 作业部署到生产集群之前，应该采用什么样的测试策略来测试它们？
2. 是否有将作业推出到 rundeck 生产集群的标准策略？如果不是，通常的做法是什么来避免对目标用户/服务和团队造成干扰？
3. 我们应该如何有效地管理发布和回滚并保持发布作业/功能的时间稳定？
4. 360 度测试策略以有效测试作业/工作流和插件/脚本？所以我们的想法是全面、真实和正确地测试（单元、集成、行为等）。从 rundeck 的角度来看，最佳做法是什么？

解决方法

基本上，最好的策略是在实际生产环境（包括插件测试、工作流程和配置）中部署之前，使用非生产环境来测试任何更改。无论如何，您可以使用 Rundeck docker 镜像创建一个快速测试环境。

关于推出/回滚，一个好的方法是使用您的稳定作业配置 SCM，以便在实施不当的情况下恢复。