了解持续集成

持续集成 (CI) 是一种 DevOps 做法，旨在帮助开发团队更高效地工作和更可靠地交付软件。 使用 CI，每次合并更改时，CI 服务器都会自动构建和测试您的代码，为您的工作提供快速反馈。 这种快速可靠的反馈周期可以帮助您更频繁地发布更改，同时减少进入生产的 bug 数量。

无 CI 的开发

要理解为什么需要持续集成，不妨考虑一下没有持续集成的软件开发会是什么样子。 假设您正在使用 Git 这样的版本控制系统。 您和同事都有各自的仓库副本，您可以使用该副本进行本地开发，然后再将工作推送到共享仓库。

如果您正在开发一项新功能，您可能需要工作几天后才能共享更改。 在此期间，您的同事也在仓库的本地副本上构建功能。 完成后，你们将各自的更改推送到共享仓库，并开始合并到指定分支，以便测试每个功能与其他功能结合时是否按预期工作。

不过，由于组合了多个开发者的大量更改，代码无法继续构建的风险很高。 您和同事需要花时间确定哪组更改导致了问题，然后要么撤消这些提交来继续发布其他更紧急的更改，要么进一步更改代码以修正问题。

代码构建后，您可能会发现更改的组合引入了各种 bug。 于是，您又要检查每个贡献者的代码更改，寻找问题根源，将其修正，然后重新开始构建流程。

对 CI 的需求

每次将更改合并到指定分支时，持续集成都会自动执行构建和测试步骤，加快这一流程。 自动执行这些步骤后，您就可以每隔几小时构建和测试代码库，而不是每几周一次。

以较小的增量工作意味着您可以更快发现和修正由代码更改引入的问题。 与检查成百上千行的更改来查找问题源头相比，您的搜索将仅限于一组更小的更改。 而且，您还记得这些更改，因此不会有额外的上下文切换负担。

通过确认您的软件在每次更改后仍能按预期构建和运行，CI 帮助您使代码保持可部署状态。 因此，将更改发布到生产的难度有所降低，您可以更频繁地交付功能和修正。

虽然持续集成旨在解决涉及多个贡献者的大型软件开发项目所面临的问题，但将 CI 添加到开发流程中总能带来收益。 即使您是一名独立开发者，以小规模的增量进行工作并通过自动化测试验证更改也可以帮助您更高效地工作并提高代码质量。

有效的 CI 工作流需要工具、流程和团队做法的结合。 我们来依次查看。

使用版本控制系统

持续集成依赖于将整个代码库存储在源/版本控制系统中。 这应该包括所有源代码文件、库、配置文件和脚本。 使用版本控制可以让多个开发者更轻松地并行工作并相互共享更改。 CI 服务器与版本控制系统集成，用于构建和测试代码更改。

定期提交更改

为了使每位成员都能在相同的基础上进行构建，您需要一直使用同一仓库并频繁共享所做更改。 一个良好的经验法则是让每个人每天将其提交合并到共享仓库的 CI 分支中，但您也可以提高频率。 同时，让本地副本与共享仓库保持同步，降低每次推送时发生合并冲突的风险。

自动化构建和测试

合并代码更改后，下一步是构建解决方案并对其进行一系列检查，例如 Lint 分析、单元测试和静态分析。 手动构建和/或测​​试既耗时又容易出错，每天集成更改不切实际，因此自动化非常重要。 所有主流编程语言都有构建工具和自动化测试框架，您可以使用 CI 服务器自动启动流程并协调各个步骤。

及时解决故障

要获得持续集成的优势，当自动构建或测试失败时，参与项目的每个人都必须快速响应。 这可以确保每个人都是在坚实的基础上做出贡献，而不是尝试为无法正常工作的代码添加新功能。 虽然您可能会要求团队成员中断工作来修正损坏的构建或测试，但自动化 CI 流程可以在几分钟内交付初步结果，让您在还记得代码更改时解决问题。

维护流程

自动执行构建和测试后，您需要维护 CI 流程。 这包括在编写新代码时添加单元测试并保持反馈循环的速度。

添加 CI 服务器来监控您的仓库、触发构建、运行自动化测试以及整理结果，有助于集中管理这些零散的工作，从而让您在编写自定义自动化逻辑时节省时间。 好的 CI 服务器还可以提供额外洞察，例如代码覆盖率指标和构建历史记录。

了解持续集成的预期收益有助于激励团队成员尝试新的做法并说服利益相关者支持新流程。

对于个人和整个开发团队，CI 能带来：

• 更顺畅的合并：以较小的增量开始工作，合并冲突的数量就会减少。 关键是定期使用其他人推送的更改来更新您的本地仓库。
• 更高效的工作流：自动化构建和测试流程的快速反馈可以在您推送更改几分钟后提醒您代码中的问题。 相比之下，如果您依赖手动构建或测试流程，那么可能要过几天或几周您才会发现更改引入的 bug。
• 更易维护的代码库：添加自动化测试覆盖率以确保 CI 流程运行良好，使代码库更易理解和维护。
• 更好的沟通和协作：以较小的增量工作并更定期地共享更改意味着您也能看到其他人正在做什么。 这样就有更多机会与同事讨论功能设计、向产品经理和实用性专家展示进度，以及根据需要调整方向。

持续集成也有利于更广泛的业务，例如：

• 更少的 bug：虽然持续集成不能防止引入 bug，但它可以让开发者更容易识别和修正 bug。 因此，bug 发布到生产中的可能性要小得多，从而减少对用户的影响。
• 更快、更频繁的发布：自动执行构建和测试流程可以节省时间并确保步骤一致执行，减少准备软件发布的手动工作量。 随着团队对 CI 流程越来越有信心，他们可以更频繁地发布更改。

要详细了解持续集成、交付和部署的更多好处，请阅读我们的 CI/CD 的 12 大优势指南。

CI 的挑战

虽然持续集成为开发者和更广泛的业务都能带来好处，但它并不总是受到欢迎。

对于许多开发部门而言，DevOps 都代表了工作方式的巨大变革，并会挑战现有流程。 需要良好的沟通来协调团队间的工作并培养协作文化。

如果您已采用敏捷方法，那么进行这种转变通常会更为容易，因为听取反馈的重要性以及自组织团队的观念已经得到认可。

如果尚未接触，那么认识到这是一项重大变革、积极互动、从小事着手并逐步展现其优势，都有助于让您的同事相信 CI 带来的好处。

持续集成还面临着更多实际挑战。 如果您正在处理大型单体式应用程序，那么构建速度可能会很慢，如果测试环境短缺，则并行运行测试将是一项挑战。

直观呈现持续集成工作流并使用指标来识别瓶颈，可以帮助量化在架构更改、附加架构和自动化测试覆盖率方面进行投资的成本和收益。

设置 CI 工作流看似很困难。 有很多选项可供考虑，也有很多东西可以自动执行。 好在这个流程很容易被分解成更小的部分，因为每个步骤都会带来一些好处。

以下领域是不错的起点：

1. 开始以较小的增量工作：只要您的代码采用版本控制，您就可以开始以较小的批次工作并更频繁地共享更改，减少合并冲突。 为此，您可能需要在积压工作细化期间开始分解开发任务。
2. 就分支策略达成一致：这决定了哪些分支将通过 CI 流，以及更改如何发布。 常见的选择包括基于主干的开发和 GitFlow（特别是对于版本化软件）。
3. 在编写代码时添加单元测试：无论您是已经拥有单元测试，还是从零开始，让单元测试成为团队“完成的定义”的一部分都能确保代码覆盖率不断提高。 拥有自动化测试总比没有更好，而且只需少量自动化测试您就可以开始实践 CI。
4. 逐步自动执行：不要尝试一次性编写 CI 流程每个阶段的脚本，而是专注于最耗时或提供最多反馈的部分。 准备就绪后，您可以使用 CI 服务器开始将这些步骤链接到自动化 CI 流程中。

您可以通过我们的 CI/CD 最佳做法指南详细了解如何设置 CI 和 CD。

采用持续集成有助于加快开发过程并同时提高代码质量。 通过自动执行这些步骤，您可以更高效地工作并专注于增加用户价值。 但是，持续集成只是 CI/CD 管道的起点。 下一阶段为持续交付，涉及将 DevOps 原则应用于发布流程的后续部分。

TeamCity 是一个灵活的 CI/CD 平台，您可以根据自己的需求进行自定义。 它为所有主流版本控制系统提供支持，包括 Git、Perforce、Mercurial 和 Subversion，并为领先编程语言提供构建和测试工具。 广泛的 CI 触发器意味着您可以在每次提交到指定分支后启动构建测试流程，在功能分支上运行检查子集，安排隔夜构建，并让团队成员选择在本地运行 CI 检查。

为了确保您尽快获得反馈，TeamCity 可以并行运行测试和其他构建任务。 无论您在哪里工作，Slack 和 IDE 集成都能提供反馈，而详细的测试报告则可以帮助您快速找出故障原因。 TeamCity 还提供一系列指标，帮助您优化 CI 流程和评估单元测试覆盖率。

如果您决定扩展 CI 流程以包含持续交付或部署，TeamCity 可以为您提供管理环境和自动化执行部署所需的一切资源。