关于持续集成的一个基本问题

问题描述

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

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

解决方法

通常每天保存代码是为了确保您的工作不会丢失。

相反，CI 或持续集成用于测试您生成的内容是否正常，在大多数项目中，CI 不应用于单个分支，即：feature， bugfix，它应用于主要分支，即：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 具有验收标准并主动防止出现问题，在继续集成的帮助下使这些标准自动化非常重要。

但在所有因素中，向开发人员提供有关软件质量的反馈非常重要。最好有利于项目（经济上），尽早了解错误，从而继续集成和 DevOps。 在复杂系统中，值得拥有自动观察器来捕捉开发人员的偷偷摸摸的错误。

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