问题描述
公司正在集成CI/CD，目前已经实现了CI。目前，当开发人员将代码推送到git仓库时，CI流水线会运行。
目前，我们的CI流水线包括构建项目和进行静态代码分析，以确保其符合我们的编码标准。接下来，我们将实施测试。目前，构建和静态代码分析大约需要3分钟。根据我的理解，立即修复问题对于CI/CD至关重要。我预计，当我们添加单元测试时，流水线可能需要大约10分钟才能运行。
所以我的问题是，当开发人员发起拉取/合并请求时，他们应该等待CI流水线完成，还是继续下一个任务，如果存在问题，再回来修复？还是他们应该坐下来观看流水线运行？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
解决方案1
不需要坐下来观看流水线运行。开发人员将他们的提交推送到源代码仓库，然后触发CI/CD流水线。
开发人员可以随时发布一个写得很好的拉取请求。通常会有一个可视化标记表示“正在构建”/“构建失败”/“构建成功”。
通常，只有在满足以下所有条件时，才能合并分支：
– 至少有一个审批者/或者需要多个审批者批准。
– 一个“成功的构建”。
– 没有未解决的合并冲突。
如果这些条件中的任何一个不满足，就需要修复它们，但开发人员可以在有时间或优先级的情况下完成这个任务。
解决方案2
我建议尽力确保流水线的运行时间不超过10分钟。你可以并行执行测试来实现这一点。正如Jonas所回答的，开发人员可以在流水线运行时花时间创建一个拉取请求。
频繁切换任务对生产力不利，所以与其选择另一个任务，我建议开发人员利用这段时间来处理与他们刚刚做出的更改相关的任何其他事情。也许有一些文档可以更新，与此相关。如果这是一个值得注意的功能，他可以创建一个简短的gif，展示如何使用它。甚至再次查看他们的代码更改可能有助于他们思考如何在下次改进它。这段时间还可以用来审查其他开发人员的拉取请求和代码更改。
如果他们在这10分钟内转移到开发另一个功能，那么在他们回到这个功能之前可能会过了10分钟，而且他们对工作的记忆也会变得不那么新鲜。如果CI失败，他们将更难记住可能出了什么问题并修复代码。