这不是一个编程问题，但我不知道任何更活跃的论坛，而且程序员是能够回答我问题的最佳人选。
我试图了解持续集成背后的基本原理。一方面，我知道在回家之前每天提交代码是一个很好的做法，无论编码和测试是否完成，然后有持续集成的概念，即每提交一些东西，它就会触发构建并运行所有测试用例。这两件事不是矛盾的吗？如果我们每天提交任何编码，都会导致每日构建失败。为什么我们不在编码和测试完成后手动触发构建？
【问题讨论】：
标签： jenkins version-control jenkins-pipeline hudson
通常当您每天保存代码时是为了确保您的工作不会丢失。
相对而言，CI 或持续集成是为了测试您的产品是否正常，在大多数项目中，CI 并不适用于单个分支，即：feature、@987654323 @，它适用于主要分支，即：master、develop、releases 等。这些分支不会每天更新，因为它们需要更新拉取请求并有人批准拉取请求。
在单个分支（功能、错误修复）上实现 CI 的用例是在将拉取请求合并到主要分支之前检查它何时检查测试以及代码是否构建。
所以恢复，是的，您需要每天提交您的代码，但您不需要每天对其应用 CI。
我建议你检查 Gitflow 工作流程：https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
【讨论】：
答案显而易见。
1.提交代码： 通常，只有在本地环境测试后才会提交代码。
考虑Developer_A 在Component_A 上工作，因此必须以最少的验证提交，因为范围是开发 Component_A。
无法想象有 50 名开发人员开发的复杂系统Component_B...Component_Z++
如果有人在没有最低限度的测试的情况下提交代码，它很可能会给你失败的结果。
否则开发人员可能会将其提交到开发分支上，这一切都取决于项目中采用的 SCM 策略。
2。继续集成测试范围： 另一方面，集成商主要将不同的代码（软件组件）收集并协同到一个容器中并执行不同的测试。 最重要的是，集成商需要确保从不同开发人员开发的所有组件都合适，并且最终软件按预期工作。为确保 Integrator 具有验收标准并主动防止可能出错的情况，在 Continues integration 的帮助下使这些标准自动化非常重要。
但在所有因素中，向开发人员提供有关软件质量的反馈非常重要。最好有利于项目（在经济上），尽早了解该错误，从而继续集成和 DevOps。 在复杂系统中，值得拥有自动观察器来捕捉开发人员偷偷摸摸的错误。
3 工具和自动化： 要创建人类独立系统，像 Jenkins 这样的自动化工具很有帮助。 根据测试策略，可以借助自动化工具执行不同的测试级别。
【讨论】：