持续集成

持续整合（英语：Continuous integration，[[缩写]]CI），又译为持续集成，是一种软件工程流程，是将所有软件工程师对于软件的工作副本持续集成到共享主线（mainline）的一种举措。该名称最早由[1]葛来迪·布区（Grady Booch）在他的布区方法[2]中提出，在测试驱动开发（TDD）的作法中，通常还会搭配自动单元测试。持续集成的提出主要是为解决软件进行系统集成时面临的各项问题，极限编程称这些问题为集成地狱（integration hell）。

解释

持续集成的宗旨是避免集成问题，如同在极限编程(XP)方法学中描述的集成地狱。持续集成并非普遍接受是用来改善集成频率的方法，因此重要的是区分两者所带来的效益。

在极限编程方法学，持续集成需要达到最佳成果，必须依靠着自动化集成单元测试并通过测试驱动开发。首先必须设想在上线运作之前，已在开发环境完成并通过所有的单元测试。这将帮助避免一个开发者的作业流程，导致其他开发者作业的中断。如果有需要，可以在完整上线运作之前进用部分已完成的功能，例如使用功能切换。

接着进行CI服务器建置概念的阐述、自动化运行单元测试的周期与每次测试需要提交给开发者的报告。建置CI服务器的用途(不一定要运行单元测试) 已经开始在极限编程(XP)社区之外的团队练习。如今，许多企业组织已经开始采用持续性集成，而非采用完整的极限编程(XP)。

除了自动化单元测试，组织在运用持续性集成(CI)一般会建置CI服务器来维护持续性套用质量控制的程序-小部分的影响，并且经常性使用。除了运行单元与集成测试之外，还有额外的静态与动态测试，量测与描述性能，从程序来源码摘录与文件格式与促成手动质量保证(QA)程序。持续性质量控制应用程序用意在提升软件质量以及减少交付的时间，在完成所有开发后，取代传统软件上线质量控制机制。此非常相似进行频繁集成的最初概念让集成得以在QA程序上更容易地达成。

同样的道理，持续性交付的最佳实践进一步扩展了持续性集成(CI)，以确保软件检核在主要程序上并且能够布署到用户以确保实际的布署流程可以非常快速。

工作流程

当从事变更时，开发者会从目前基础代码库复制以进行作业，其他开发者提交代码的变更至来源代码库，并透过副本的方式取代来源代码库的代码。不只变更目前的代码库，新的代码也可以新增成为程序库、其它共享资源与潜在冲突。

当分支代码保持在取出状态时间越长，当分支代码开发者进行主线重新集成时，就愈容易遭遇集成多重冲突的风险以及失败。当开发者将代码提交到代码库时，首先必须更新代码以反映他们在代码库中的更改，因为他们拿到了副本。代码库包含的更改越多，开发人员在提交自己的更改前必须运行的工作越多。

终于，该程序库也许变成非常不同于开发者的目标代码，他们进入有时候被称为合并地狱或集成地狱[3]的阶段，这时候开发者所花费的集成时间，将超过最初代码开发的时间。

持续性集成涉及预先集成与预先与经常性的集成，借此来避免踩到集成地狱的陷阱，实践的目标是减少重工、减少成本与时间[4]。

持续性集成补充的实践是在提交成果之前，每个开发人员必须运行一个完整的构建与运行及通过所有的单元测试、集成测试，这些都是当持续性集成服务器侦测到代码有新的提交时，必须经常性与自动化的进行。