什么是持续集成（CI），它有什么用？[关闭]

有人可以向我解释持续集成的概念吗，它如何以一种易于理解的方式工作？公司为什么要在代码交付工作流程中采用CI？我是一名开发人员，而我的公司（主要是构建团队）使用Team City。作为开发人员，我总是签出，更新代码并将其提交到SVN，但总的来说，我从来没有真正担心过TeamCity或CI。所以我想了解CI的用处？CI是敏捷方法论的一部分吗？

简而言之，持续集成意味着您可以保存工作，将其推送到文档管理系统（在您的情况下为SVN），自动运行所有测试（单元测试，集成测试，功能测试等），并编译和准备应用程序进行交付（即创建ISO映像）。持续集成与持续交付并不相同。交付仍在不同的时间完成。CI确保需要时可以交付产品，仅此而已。

每当出现问题时，团队都会收到通知。通常，在这一点上，所有工作都停止了，所有工作都集中在确保产品稳定的方式上。系统不是绿色时，不会在存储库上进行任何推送和提交。

CI确保产品始终处于稳定状态，并可以随时交付。请注意，稳定并不意味着功能完整。也可能有一半实现的功能，但系统可以稳定。

CI通常与敏捷方法论相关联，但是我个人不知道CI的确切历史。

持续集成意味着：将代码集成到实际运行且可以测试的产品中，始终（而不是像以前那样）始终在开发生命周期的后期进行。

它要求应用程序的构建过程是完全自动化的，并且需要一个自动化的测试套件，以及一台用于构建代码当前状态并在其上运行测试套件的服务器。这应该每天进行一次，甚至在每次代码签入后进行。

优点是可以立即收到有关导致编译错误（例如，由于开发人员无法检入所有更改或使用构建系统中不存在的某些组件）或测试用例失败的代码更改的反馈。这样您就可以更轻松地修复此类错误，因为您知道是哪些更改导致了这些错误，而负责人员仍然对它们的所作所为有新的记忆。

没有CI，所有这些错误都会在集成阶段同时出现，这使得它们极难修复。

您可能在开发中具有某种风格：签出，编码，编译，检查，诅咒，更改，编译，欢呼，提交。您仅提交工作代码，甚至可能以工作日结束时或功能完善时之类的较不精细的方式提交。只要导入API库，就可以验证依赖项。

当您开始与其他人一起进行编码并且存在相互依赖性时，采用持续集成是有意义的。仅仅因为您不知道更改对依赖于代码的人员的影响，并且您每次需要更新导入时都不会收到任何信号。

因此，当您其中一个进行更改时，应该一起构建和测试两个项目，即，根据彼此的API运行，使用新库构建和测试等。此类测试，您的代码和其他人的测试称为集成测试。

为什么要连续？因为在任何一个代码库中发生更改时，将集成的协调委派给一个测试干净构建的系统都比将所有这些组织给人类更容易。该系统能够扩展。

持续集成有两个方面。

1. 开发源代码控制策略可确保开发人员能够将其正在进行的工作与其他开发人员稳定的代码连续集成。
2. 由提交到源代码管理触发的自动构建和测试源代码

第一点很关键。开发人员实际执行的合并是频繁的，而本质上很小的合并使合并更有可能成功。

第2点是使第1点安全发生，快速识别由于破坏现有代码而失败的合并所需要的工具和框架。

它有用吗？

难以置信。作为从事项目工作的开发人员，它使您可以将大部分时间花在专注于自己的工作上，而不必担心团队其他成员的并发工作。当前工作完成后，您可以将更改发布到团队的其他成员，并在接下来的几个小时内将所有更改合并到当前工作中。

没有它，开发人员将进行大规模合并。通常需要花费几天的时间，并且必须将其与团队其他成员所做的所有更改一次性合并。当合并变得非常糟糕时，其他开发人员可能会转移到其他工作上，并开始忘记一些详细信息来帮助消除合并混乱。更糟糕的是，如果不进行持续的构建和测试，只要代码可以编译，合并错误就会出现在代码中，直到测试（或客户）找到它们后才会被发现。

在以下情况下，配置项很有用：

• 代码编译
• 实际测试
• 报告基于您的源代码（代码覆盖率，违反代码标准等）。
• 成功编译代码后定期执行的例程

列表可以继续。