Jenkins 关于连续积分的一个基本问题

这不是一个编程问题，但我不知道还有什么更活跃的论坛，而且程序员是能够回答我问题的最佳人选

---

我试图理解持续集成背后的原理。一方面，我理解，无论编码和测试是否完成，每天在回家之前提交代码都是一种很好的做法，然后是持续集成概念，在提交某个内容时，它触发构建并运行所有测试用例。这两件事不矛盾吗？。如果我们每天提交所做的任何编码，都会导致每天的构建失败。为什么不在编码和测试完成后手动触发构建呢？

通常，每天保存代码时都会确保您的工作不会丢失

在对应项目中，CI或持续集成是为了测试您生产的产品是否正常，在大多数项目中，CI不适用于单个分支，即：

功能

，

错误修复

，它适用于主要分支，即：

主

，

开发

，

发布

，这些分支没有每天更新，因为它们需要更新拉取请求，并需要有人批准该拉取请求

在单个分支（特性、错误修复）上实现CI的用例是在将pull请求合并到主分支之前检查何时检查测试以及代码是否生成

因此，恢复时，您需要每天提交代码，但不需要每天对其应用CI

我建议您检查Gitflow工作流：

答案显而易见

1。提交代码：通常，只有在使用本地环境进行测试后才提交代码。 考虑<代码>开发人员A/<代码> <代码>组件-A 。因此，必须进行最小验证，因为范围是开发组件A。 不要想象有50名开发人员开发的复杂系统

Component\u B

…

Component\u Z++

如果有人在提交代码时没有进行最低限度的测试，那么很可能会给出失败的结果

或者，开发人员可能会将其提交给开发部门，这一切都取决于项目中采用的SCM策略

2。继续集成测试范围： 另一方面，integrator主要将不同的代码（软件组件）收集并协同集成到一个容器中，并执行不同的测试。 最重要的是，integrator需要确保由不同开发人员开发的所有组件都是合适的，并且最终软件按照预期工作。为确保集成商具有验收标准，并主动预防可能出现的问题，在持续集成的帮助下使这些标准自动化是很重要的

但在所有因素中，向开发人员提供软件质量反馈是很重要的。尽早了解bug是项目的最佳选择（经济上），因此可以继续集成和开发。 在复杂的系统中，有一个自动的观察者来捕捉开发人员隐藏的错误是值得的

3工具和自动化： 为了创建独立于人类的系统，像Jenkins这样的自动化工具很有帮助。 根据测试策略，可以借助自动化工具执行不同的测试级别