软件工程/工具/持续集成简介
 |
一位维基教科书贡献者建议将此书籍或章节合并到持续集成软件开发 中，因为 我们可以制作一本关于该主题的更全面的书籍 请在讨论页面上讨论是否应该进行合并。 |
在软件工程中，持续集成（CI）实施持续的质量控制流程 - 频繁应用的小部分工作量。持续集成旨在通过取代在完成所有开发后才进行质量控制的传统做法，来提高软件质量并缩短交付时间。
在开始更改时，开发人员会获取当前代码库的副本进行操作。当其他开发人员将更改后的代码提交到代码仓库时，此副本逐渐不再反映仓库代码。当开发人员将代码提交到仓库时，他们必须首先更新自己的代码以反映仓库中自获取副本以来的更改。仓库包含的更改越多，开发人员在提交自己的更改之前就必须完成的工作越多。
最终，仓库可能会与开发人员的基线代码相差很大，以至于他们进入所谓的“集成地狱”[1]，在这种情况下，集成所需的时间超过了最初进行更改的时间。在最坏的情况下，开发人员可能不得不放弃更改并完全重新进行工作。
持续集成涉及尽早且频繁地集成，以避免“集成地狱”的陷阱。该实践旨在减少返工，从而降低成本和时间。
本文的其余部分讨论了如何实现持续集成的最佳实践，以及如何自动化此实践。自动化本身就是最佳实践。 [2][3]
持续集成 - 作为频繁地将新的或更改的代码与现有代码仓库进行集成的做法 - 应该足够频繁，以至于在提交和构建之间没有任何间隙，并且这样一来，任何错误都不会在开发人员注意到并立即纠正它们之前出现。 [4] 正常的做法是通过每次提交到仓库来触发这些构建，而不是通过定期安排的构建。在快速提交的多开发人员环境中这样做，实际上是需要在每次提交之后触发一个简短的计时器，然后在计时器到期或上次构建之后经过相当长的时间后开始构建。CruiseControl 或 Hudson 等自动化工具可以自动提供此调度功能。
另一个因素是需要一个支持原子提交的版本控制系统，即开发人员的所有更改都应该被视为单个提交操作。尝试仅从更改了一半的文件进行构建毫无意义。
此实践提倡使用修订控制系统来管理项目的源代码。所有构建项目所需的工件都应该放置在仓库中。在此实践以及修订控制社区中，惯例是系统应该能够从全新的检出构建，并且不需要额外的依赖项。极限编程倡导者 Martin Fowler 还提到，在工具支持分支的情况下，应该尽量减少其使用 [需要引证]。相反，更倾向于将更改集成在一起，而不是同时维护软件的多个版本。主干应该作为软件工作版本的存放位置。
单个命令应该具有构建系统的能力。许多构建工具，例如 make，已经存在多年。其他更新的工具，例如 Ant、Maven、MSBuild 或 IBM Rational Build Forge，在持续集成环境中被频繁使用。构建的自动化应该包括集成过程的自动化，这通常包括部署到类似于生产环境的环境中。在许多情况下，构建脚本不仅会编译二进制文件，还会生成文档、网站页面、统计数据和分发媒体（例如 Windows MSI 文件、RPM 或 DEB 文件）。
构建代码后，所有测试都应运行以确认其行为符合开发人员的预期。
通过定期提交，每个提交者都可以减少冲突更改的数量。签入一周的工作可能会导致与其他功能发生冲突，并且可能非常难以解决。系统某个区域的早期、小的冲突会导致团队成员互相交流他们正在进行的更改。
许多程序员建议每天至少提交一次更改（每构建一个功能一次），此外还要执行夜间构建。
系统应该将提交构建到当前工作版本，以验证它们是否可以正确集成。常见的做法是使用自动化持续集成，但也可以手动进行。对于许多人来说，持续集成等同于使用自动化持续集成，其中持续集成服务器或守护进程监控版本控制系统以查看是否有更改，然后自动运行构建过程。
构建需要快速完成，以便如果集成出现问题，可以迅速识别。
拥有一个测试环境可能会导致测试系统在生产环境中部署时出现故障，因为生产环境可能与测试环境存在很大差异。但是，构建生产环境的副本成本很高。相反，应该构建一个可扩展版本的实际生产环境，以在保持技术堆栈组合和细微差别的同时，减轻成本。
使构建物易于供利益相关者和测试人员使用，可以减少重建不符合要求的功能时所需的工作量。此外，早期测试可以减少缺陷在部署前存活的可能性。在早期发现错误，在某些情况下，也减少了解决错误所需的工作量。
应该很容易找到构建在哪里/是否中断以及谁进行了相关更改。
大多数 CI 系统允许在构建完成后运行脚本。在大多数情况下，可以编写一个脚本将应用程序部署到一个每个人都可以查看的实时测试服务器上。这种思维方式的进一步发展是持续部署，它要求软件直接部署到生产环境，通常使用额外的自动化来防止缺陷或回归[5]。
持续集成起源于极限编程 (XP) 社区，XP 倡导者 Martin Fowler 和 Kent Beck 于 1999 年左右首次撰写了关于持续集成的文章。Fowler 的论文[6] 是有关该主题的流行信息来源。Beck 的书《极限编程解析》[7]，极限编程的原始参考，也描述了该术语。
持续集成有很多优点
- 当单元测试失败或出现错误时，开发人员可能会将代码库恢复到无错误状态，而不会浪费时间进行调试。
- 开发人员持续检测和修复集成问题 - 避免在发布日期（当每个人都尝试签入他们略有不兼容的版本时）出现最后一分钟的混乱。
- 早期预警不完整/不兼容的代码
- 早期预警冲突的更改
- 立即对所有更改进行单元测试
- 持续提供“当前”构建以供测试、演示或发布目的
- 立即向开发人员反馈他们正在编写的代码的质量、功能或系统范围的影响
- 频繁的代码签入促使开发人员创建模块化、不太复杂的代码[需要引用]
- 从自动化测试和 CI 生成的指标（例如代码覆盖率、代码复杂度和功能完整的指标）使开发人员专注于开发功能性、高质量的代码，并有助于在团队中形成发展势头[需要引用]
- 需要初始设置时间
- 需要完善的测试套件才能实现自动化测试的优势
- 由于代码库不断变化，大规模重构可能会很麻烦
- 构建机器的硬件成本可能很高
许多使用 CI 的团队报告说，CI 的优势远远超过缺点。[8] 在开发过程的早期发现并修复集成错误，在项目的整个生命周期内节省了时间和金钱。
为了支持持续集成，可以使用自动化构建软件等软件工具。
持续集成的软件工具包括
- AnthillPro — Urbancode 的持续集成服务器
- Apache Continuum — 支持 Apache Maven 和 Apache Ant 的持续集成服务器。支持 CVS、Subversion、Ant、Maven 和 shell 脚本
- Apache Gump — Apache 的持续集成工具
- Automated Build Studio — AutomatedQA 的专有自动化构建、持续集成和发布管理系统
- Bamboo — Atlassian Software Systems 的专有持续集成服务器
- BuildBot — 基于 Python/Twisted 的持续构建系统
- BuildForge - IBM / Rational 的专有自动化构建引擎
- BuildMaster — Inedo 的专有应用程序生命周期管理和持续集成工具
- CABIE - Continuous Automated Build and Integration Environment — 开源，用 Perl 编写；与 CVS、Subversion、AccuRev、Bazaar 和 Perforce 协同工作
- Cascade — 专有持续集成工具；提供一个检查点设施来构建和测试更改，然后再提交它们
- codeBeamer — 具有内置持续集成功能的专有协作软件
- CruiseControl — 用于持续构建过程的基于 Java 的框架
- CruiseControl.NET — 基于 .NET 的自动化持续集成服务器
- CruiseControl.rb - 轻量级、基于 Ruby 的持续集成服务器，可以构建任何代码库，而不仅仅是 Ruby，在 Apache Licence 2.0 下发布
- ElectricCommander — 来自 Electric Cloud 的专有持续集成和发布管理解决方案
- FinalBuilder Server — VSoft Technologies 的专有自动化构建和持续集成服务器
- Go — Thoughtworks 的专有敏捷构建和发布管理软件
- Jenkins（以前称为 Hudson） — 采用 MIT 许可，用 Java 编写，在 servlet 容器中运行，支持 CVS、Subversion、Mercurial、Git、StarTeam、Clearcase、Ant、NAnt、Maven 和 shell 脚本
- Software Configuration and Library Manager — IBM Rational Software 为 z/OS 提供的软件配置管理系统
- QuickBuild - 专有持续集成服务器，具有免费的社区版，提供构建生命周期管理和提交前验证功能。
- TeamCity — JetBrains 的专有持续集成服务器，具有免费的专业版
- Team Foundation Server — Microsoft 的专有持续集成服务器和源代码存储库
- Tinderbox — 基于 Mozilla 的产品，用 Perl 编写
- Rational Team Concert — IBM 的专有软件开发协作平台，具有内置的构建引擎，包括 Rational Build Forge
请参阅持续集成软件比较，以获得更深入的功能矩阵。
- Duvall，Paul M. (2007)。持续集成。改进软件质量和降低风险。Addison-Wesley。 ISBN 0-321-33638-0.
- ↑ 坎宁安，沃德 (2009 年 8 月 5 日). "集成地狱". WikiWikiWeb. 检索于 2009 年 9 月 19 日.
{{cite web}}: 检查日期值：|accessdate=和|date=(帮助) - ↑ 布劳内斯，大卫 (2010 年 1 月 1 日). "[OSLC 可能的新工作组 - 自动化"]。open-services.net 社区邮件列表. http://open-services.net/pipermail/community_open-services.net/2010-January/000214.html. 检索于 2010 年 2 月 16 日.
- ↑ 泰勒，布拉德利. "使用 ShadowPuppet 和 Capistrano 进行 Rails 部署和自动化".
- ↑ 福勒，马丁. "持续集成". 检索于 2009-11-11.
- ↑ 参见 5 个简单步骤的持续部署 - O'Reilly 雷达 和 IMVU 的持续部署：每天完成 50 次不可能的任务 - 蒂莫西·菲茨
- ↑ 福勒，马丁. "持续集成".
- ↑ 贝克，肯特 (1999). 极限编程解释. ISBN 0-201-61641-6.
- ↑ 理查德森，贾里德 (2008 年 9 月). "无废话，只讲干货大会上的敏捷测试策略". 马萨诸塞州波士顿. http://www.nofluffjuststuff.com.
- 持续集成软件比较
- 持续集成 由马丁·福勒（简介）
- 波特兰模式库中的持续集成 （协作讨论）
- 波特兰模式库中的跨平台测试
- 持续集成服务器功能矩阵 （工具指南）
- 持续集成：优秀团队的基石 由贾里德·理查德森（简介）
- 构建可维护性和可重用性的秘诀 由杰伊·弗劳尔斯
- 持续集成反模式 由保罗·杜瓦尔
- 极限编程