我听到很多人关于基于干线的开发。我不明白在进行基于主干的开发时，与Jenkins的持续集成是如何工作的。我们使用 git 进行组织中的版本控制。
Jenkins作业被设置为轮询git以获取任何更改，如果检测到任何更改，则一旦构建成功，就开始部署。
所有开发人员都可以访问jenkins，并且可以将构建配置为在不同的分支上启动。然后将此代码部署在dev实例中以进行测试。如果开发人员发现它很好，他们会重新配置jenkins build以指向master。这是手动的，开发人员可以这样做。
有一个管道作业定期运行并用标准作业覆盖Jenkins作业。因此，即使开发人员在配置上留下了螺丝，Jenkins仍然设法将构建保持在理智的状态。
现在我在使用多个提交工作 on feature / bugfix branches 时出现问题，CI / CD流程的最佳做法是什么？
a）开发人员将在每次提交后指向其分支并部署到dev实例。据我所知，这是手动的，开发人员很容易忘记这一点。
b）开发人员会在提出Pull请求之前将Jenkins构建指向其分支，并部署到dev实例。如果有多个提交，则构建/部署可能会因任何提交而失败。这也是手动的，可能很难进行调试。
c）开发人员将在本地运行构建以确保测试正在通过。部署是一种黑暗的艺术，将留给其他人弄清楚。在拉取请求之后，jenkins将运行构建以确保所有测试都通过。这是自动的。现在，如果构建/部署失败，开发人员就会知道出了什么问题。
答案 0 :(得分：1)
听起来你的c）是正确的方法，但我并没有完全掌握这种情况。对于基于主干的开发，只应在合并之前使用CI / Jenkins，而不是每次提交（即，不能替代本地构建机制）。您的开发人员应该通过手动运行测试并在出现任何问题时进行调试来在本地构建和测试其代码。
在合并时，您可以进行预合并或合并后的构建运行。对于预合并，您将Jenkins配置为针对每个pull-request分支运行，如果所有测试都通过，则合并pull-request。这样做的好处是配置起来非常简单。缺点是构建没有考虑到trunk分支中的新变化，因此在合并后trunk可能会被破坏，即使测试在pull-request分支中传递也是如此。
对于合并后，您可以从主干分支中签出工作区，执行＆＃34; git merge＆＃34;从您的pull-request分支，并在工作区中运行构建。只有在所有测试都通过后，您才会提交并将更改推送到主干。好处是保证后备箱不会被打破。缺点是您一次只能运行一个构建，因此会减少合并带宽。
您也可以同时进行合并前和合并后。主干可能仍然会因合并而中断，但您可以从合并后的构建中快速捕获它并立即修复它。