持续交付第三章

持续集成

3.1准备工作

• 版本控制
  与项目相关的内容必须提交到版本控制库
• 自动化构建
  人和计算机之间可通过命令行自动执行应用的构建、测试以及部署的过程
• 团队共识
  修复破坏应用程序的任意修改是最高优先级的任务

3.2一个基本的持续集成系统

若要提交修改更新的代码
（1）查看是否有构建正在运行
（2）一旦构建完成且测试全部通过，就从版本控制库中将该版本更新到自己的开发环境
（3）在自己的开发机上执行构建脚本，运行测试，确保机器上的代码正常运行
（4）如果在本地构建成功，将代码提交到版本控制库中
（5）等待包含你的这次提交的构建结果
（6）如果构建失败，停下手中的事，在自己的开发机上立即修复这个问题，跳转到步骤（3）
（7）构建成功，开始下一项任务

3.3持续集成的前提条件

• 频繁提交
• 创建全面的自动化测试套件

单元测试：测试某些小单元的行为（方法、函数、一小组方法或函数之间的交互）——不需要启动整个应用，不需要连接数据库，
组件测试：测试应用程序中几个组件的行为
验收测试：应用程序是否满足业务需求所定义的验收条件（如功能、容量、安全性、有效性）——应用程序运行于类生产环境

• 保持较短的测试和构建过程
• 管理开发工作区
  1.在本地开发环境上运行应用程序时，确保所使用的自动化过程与程序集成环境、测试环境、生产环境中的一致。
  2.“最新的正确版本”——在持续集成服务器上最近一次通过所有自动化测试的那个版本。
  3.第三方库文件和组件版本与正在开发的源代码的版本相互匹配（工具：Maven和Ivy）
  4.确保自动化测试（冒烟测试）都能够在开发机上运行。
  对于大型系统——可能要在在开发机上配置中间件、运行内存数据库或单用户数据库。

3.4使用持续集成软件

1.基本操作：

• 一直运行的进程——每隔一段时间就执行一个简单的工作流程
• 提供展现这个流程运行结果的视图——通知构建和测试是否成功

2.铃声和口哨

3.5必不可少的实践

• 构建失败之后不要提交新代码
• 提交前在本地运行所有的提交测试，或让持续集成服务器（Pulse、TeamCity、ElectricCommander）完成此事
• 等提交测试通过后再继续工作
• 回家之前，构建必须处于成功状态
• 时刻准备着回滚到前一个版本
• 在回滚之前必须规定一个修复时间
• 不要将失败的测试注释掉
• 为自己导致的问题负责
• 测试驱动的开发

3.6推荐的实践

1.极限编程开发实践
重构——一系列小的增量式修改来改善代码结构，但不改变软件的外部行为
2.若违背架构原则，就让构建失败
3.若测试运行变慢，就让构建失败
生产率提高，错误减少、频繁提交、快速修复。
4.若有编译警告或代码风格问题，就让构建失败
代码质量检查的开源工具

• Simian——代码重复;
• JDepend——设计质量评估（Java）
• CheckStyle——对“烂代码”（嵌套的代码块、公共构造函数、比较长的代码行）做一些检查（容易扩展）
• FindBugs——Java软件（CheckStyle的代替品）

3.7分布式团队

1.流程问题
2.集中式持续集成
3.技术问题（网速不佳——建立更高的带宽通信机制）
4.本地化版本控制系统的存取问题（本地建立持续集成系统）

• 将应用程序分为多个组件
• 使用分布式或支持多主库拓扑结构的版本控制系统

3.8分布式版本控制系统（DVCS）

git remote add core git://github.com/rapidsms/rapidsms.git
项目主代码库的一个分支加到每个CC.rb（持续集成工具）监控的git代码库中。每次触发构建时，CC.rb会尝试合并且运行构建。

git fetch core
git merge --no-commit core/master

构建之后CC.rb会运行git reset -hard将本地的储存库指向Head;

总结与感悟

在本章我了解了持续集成的必要性及其每个成员都必须具备的职业素养。
持续集成的益处

• 使应用程序一直处在可工作的的状态
• 创建了一个快速的反馈环，使其可以快速的发现问题、解决问题，修复成本降低。
• 迫使遵循良好的配置管理和创建并维护一个自动化构建及测试流程