集成是指一种软件开发行为：将一些独立的软件组合为一个完整系统。
集成方式的重要性
从周到的继承中，你能预期获得某些下列的益处：
- 更容易诊断缺陷；
- 缺陷更少；
- 脚手架更少；
- 花费更少的时间获得第一个能工作的产品；
- 更短的整体开发进度表；
- 更好的顾客关系；
- 增强士气；
- 增加项目完成的机会；
- 更可靠地估计进度表；
- 更准确的现状报告；
- 改善代码的质量；
- 较少的文档。
集成频率——阶段式集成还是增量集成
阶段式集成
它遵循下列明确的步骤：
- 设计、编码、测试、调试各个类。这一步称为单元开发；
- 将这些类组合为一个庞大的系统；
- 测试并调试整个系统。这称为系统瓦解。
增量集成
增量集成遵循以下步骤：
- 开发一个小的系统功能部件；
- 设计、编码、测试、调试某个类；
- 将这个新的类集成到系统骨架上。测试并调试骨架和新类的结合体，在进一步添加任何新类前，确保该结合体能工作。如果做完了剩余的所有工作，就回到步骤2开始重复这一过程。
增量集成的益处
- 易于定位错误；
- 及早在项目里取得系统级的成果；
- 改善对进度的监控；
- 改善客户关系；
- 更加充分地测试系统中各个单元；
- 能在更短的开发进度计划内建造出整个系统。
增量继承的策略
- 自顶向下集成；
- 自底向上集成；
- 三明治集成；
- 风险导向的集成；
- 功能导向的集成；
- T型集成；
Daily Build与冒烟测试
- 每日构建；
- 检查失败的build；
- 每天进行冒烟测试；
- 让冒烟测试与时俱进；
- 将daily build和冒烟测试自动化；
- 成立build小组；
- 仅当有意义时，才将修订加入build中，但是别等太久；
- 要求开发人员在把他的代码添加到系统之前，进行冒烟测试；
- 为即将添加到build的代码准备一块暂存区；
- 惩罚破话build的人；
- 在早上发布build；
- 即使有压力，也要进行daily build和冒烟测试。
核对表：集成
集成策略
- [ ] 该策略是否指明了集成子系统、类、子程序时应该采用的最优顺序？
- [ ] 集成的顺序是否与构建顺序协调，以便在适当的时候准备好供集成的类？
- [ ] 该策略是否易于诊断缺陷？
- [ ] 该策略是否使脚手架最少？
- [ ] 所选的策略是否好于其他方式？
- [ ] 组件之间的接口是否有明确定义？
daily build与冒烟测试
- [ ] 项目是否经常build——理想情况下，每天build一次——以支持增量集成？
- [ ] 每次build之后是否都支持冒烟测试，让你直到这个build能否工作？
- [ ] 你是否以使build和冒烟测试自动进行？
- [ ] 开发人员是否频繁地check in他们的代码——两次check in之间最多间隔一两天？
- [ ] 冒烟测试是否与代码同步更新，随代码发展而发展？
- [ ] 破坏build是汉奸的事件吗？
- [ ] 是否在有压力的情况下，也对软件进行build和冒烟测试？
要点
- 构建的先后次序和集成的步骤会影响设计、编码、测试各类的顺序；
- 一个经过充分思考的集成顺序能减少测试的工作量，并使调试变得容易；
- 增量继承有若干变型，而且——除非项目微不足道的——任何一种形式的增量集成都比阶段式集成好；
- 针对每个特定的项目，最佳的集成方式通常是自顶向下、自底向上、风险导向及其他集成方法的某种组合；
- daily build能减少集成问题，提升开发人员的士气，并提供非常有用的项目管理信息。