Devops 管道中的手动测试

Question

我们目前正在做传统的瀑布模型，我们在 SIT 和 UAT 环境中进行手动和自动化测试。我们正在转向敏捷/Devops，我正在开发关于 Devops 的 POC。根据我的研究，DevOps 适用于 CI 和 CD，这意味着测试是自动化的，并且从开发到生产的流水线是自动化的。但是，当我们实施时，我们希望在不同的环境中进行自动代码部署，但在签署代码以进行 PROD 部署之前停止管道以进行手动 QA 测试和手动 UAT。如果我将 Jenkins 用于 Devops，是否建议将管道停止几天，直到完成手动 QA 并完成手动批准？ Devops 实施中如何考虑手动测试？任何见解都会有所帮助。

Answer 1

让管道阻塞数天当然是一种反模式。这是减轻它的一种方法-

1. 独立的持续集成 (CI) 和持续部署 (CD) 管道。
2. 有一个单独的流程为环境路由正确的工件（免责声明：我偏向于我们提供的那个 - https://relizahub.com，因为我正在处理它；视频批准是如何实现的 - https://www.youtube.com/watch?v=PzdZjMby6Is）
3. 基本上，会发生什么 - 您运行 CI 管道，它会创建一个部署工件。然后，您将获得一些专门记录在此工件上的批准（手动和/或自动）。然后你有一个单独的部署管道，它选择正确的工件并进行部署。这样，所有管道都运行得很快，您不必处理管道运行长时间卡住的问题。

Answer 2

CI 和 CD 是帮助团队提高生产力的工程实践。 并且这些应该逐步实施——首先实施CI，然后实施CD。因此，随着您在 DevOps 流程中的成熟，构建管道。

例如，利用 Jenkins 管道首先编排 CI 管道，其中以下是自动化的-

1. 应用程序构建，
2. 单元测试，
3. 代码覆盖率，

此阶段的输出是部署在 Nexus 等二进制存储库中的二进制文件。

成功实施 CI 后的下一步是 CD——将工件从一个环境自动部署到另一个环境的过程。考虑到我们需要在 QA 中部署工件（二进制文件）进行测试。您可以通过将工件从 DEV 移动到 QA 系统来扩展 CI 管道以执行 CD。然后在这里停下来，因为只有在手动测试记录得到批准后才能转移到下一个环境。这意味着将手动触发进入下一个环境。因此，在计划构建 CD 管道时，请列出应该自动化的基本步骤，然后逐步进行。

一旦您准备好使用自动化测试和工具，您就可以完成 CD 流水线并自动从 DEV-QA-NONPROD 等迁移到工件。