Jenkins在使用基于主干的开发时进行构建

我从人们那里听到很多关于基于主干的开发的消息。我不明白在进行基于主干的开发时，与Jenkins的持续集成是如何工作的。我们使用git在组织中进行版本控制

Jenkins作业被设置为轮询git是否有任何更改，如果检测到任何更改，则启动构建，一旦构建成功，就开始部署

所有开发人员都可以访问jenkins，并可以将构建配置为在不同的分支上启动。然后将此代码部署到dev实例中进行测试。如果开发人员认为没有问题，他们会重新配置jenkins build以指向master。这是一本手册，由开发人员来完成

有一个管道作业定期运行，并用标准作业覆盖Jenkins作业。因此，即使开发人员离开了配置，Jenkins仍然设法使构建保持正常状态

现在，我的问题是，在使用多个提交的功能/错误修复分支时，CI/CD流程的最佳实践是什么

a） 开发人员将在每次提交后指向其分支，并部署到开发人员实例。据我所知，这是手动的，开发人员很容易忘记这一点

b） 开发人员将在提出请求之前将Jenkins build指向他们的分支，并部署到dev实例。如果存在多个提交，则生成/部署可能会因为任何提交而失败。这也是手动的，调试时可能会很痛苦

c） 开发人员将在本地运行构建，以确保测试通过。部署是一门黑暗的艺术，将留给其他人来解决。在pull请求之后，jenkins将运行构建以确保所有测试都通过。这是自动的。现在，如果构建/部署失败，开发人员将知道哪里出了问题。

听起来你的c）是正确的方法，但我没有完全理解这种情况。对于基于主干的开发，您的CI/Jenkins应该只在合并之前使用，而不是每次提交（即，不作为本地构建机制的替代品）。开发人员应该通过手动运行测试并在出现任何错误时进行调试，在本地构建和测试他们的代码

在合并时，您可以执行合并前或合并后生成运行。对于预合并，您将Jenkins配置为针对每个拉请求分支运行，如果所有测试都通过，则合并拉请求。这样做的好处是，配置起来非常简单。缺点是构建没有考虑主干分支中的新更改，因此在合并后主干可能会断开，即使测试在拉请求分支中通过

对于后期合并，您可以从主干分支签出一个工作区，从pull请求分支执行“git merge”，并在工作区中运行构建。只有当所有测试都通过时，您才能提交更改并将其推送到主干。好的一面是它保证了后备箱不会被打破。缺点是一次只能运行一个构建，因此会减少合并带宽

您还可以同时进行预合并和后合并。主干可能仍然会因合并而中断，但您可以从合并后的构建中快速捕获它并立即修复它