《持续集成:软件质量改进和风险降低之道》读后总结 1

豆瓣上有此书的介绍,《持续集成:软件质量改进和风险降低之道》。此书还有配套web站点,提供了此书更新、代码示例和其他材料。

第一部分 CI的背景知识:原则与实践

第一章 启程

一次构建:不止是一次编译(或是动态语言中的某种称谓)。一次构建可能包含编译、测试、审查和部署以及其他一些事情。一次构建是将源代码放在一起,并验证软件可以作为一个一致的单元运行的过程。

涉及到的工具和参与人员包括:开发人员、版本控制库(如subversion)、CI服务器(如CruiseControl)、构建脚本(如Ant)、反馈机制(如email)、集成构建计算机。

CI的特征:与版本控制器系统的连接;构建脚本;某种类型的反馈机制;集成源代码变更的过程。

其子过程包括:源代码编译;数据库集成;测试;审查(如静态和动态分析);部署;文档与反馈。

第二章 引入持续集成

CI的价值在于:

  • 减少风险
    1. 缺陷的检测和修复变得更快
    2. 软件的健康程度可以测量
    3. 减少假定
  • 减少重复过程
    1. 减少重复过程的劳动,让人们有时间做更多的需要动脑筋的、更高价值的工作。
    2. 通过对一些重要过程(如测试盒数据库集成)自动化,克服项目中的某些成员对实现改进的抵制。
  • 在任何时间、任何地点生成可部署的软件
  • 增强项目的可见性
    1. 有效地决策:CI系统可以对当前的构建状态和品质指标提供及时的信息。
    2. 注意到趋势:如构建成功或失败、总体品质以及其他相关的项目信息。
  • 对开发团队的软件产品建立起更强大的产品信心

阻碍团队使用CI的原因:

  • 增加了维护CI系统的开销
  • 变化太大
  • 失败的构建太多
  • 额外的硬件/软件成本
  • 开发者应该执行这些动作

对于在项目中实现CI的团队和个人很有好处的7项实践:

  1. 经常提交代码:进行小的变更;在每个任务之后进行提交。
  2. 不要提交无法构建的代码
  3. 立即修复无法集成的构建
  4. 编写自动化的开发者测试
  5. 必须通过所以测试和审查
  6. 执行私有构建
  7. 避免签出无法构建的代码

第三章 利用CI减少风险

CI能够缓解的一些关键风险:

  • 没有可部署的软件:利用CI系统随时构建可部署的软件。创建一个可重复的构建过程,使用版本控制库中的所有软件资产。
  • 很晚才发现缺陷:每次变更时都执行开发者测试,这样就能够在软件开发生命周期中尽早发现缺陷。
  • 缺少项目可见性:经常运行构建,随时了解项目的健康状况。如果有效地应用CI实践,项目的状态就不再是一个问题。
  • 低品质的软件:在每次变更时执行测试和审查,这样就能通过了解复杂程度、重复情况、设计、代码覆盖率和其他因素发现可能进入代码中的潜在缺陷。

第四章 针对每次变更构建软件

执行单命令构建 – Martin Fowler说:“把所有需要的东西都放到源代码版本控制库中,以便于您通过单个命令就能构建整个系统。”

将构建脚本从IDE中分离 – 因为:(1)每个开发者可能使用不同的IDE,找出每个IDE中配置文件的差别会很困难;(2)CI服务器必须在无人干预的情况执行自动化的构建,因此开发者执行的自动化构建脚本,同样也应该能够由CI服务器执行。

集中放置软件资产 – 一种方法是使用版本控制库来存放所有文件,除了代码,还包括:

  1. 组件,包括源文件和库文件;
  2. 第三方组件,如JAR文件、库、DLL等
  3. 配置文件
  4. 初始化应用程序的数据文件
  5. 构建脚本和构建环境设置
  6. 某些组件的安装脚本

让构建快速失败 – 好的构建知道如何快速地失败。在构建的许多部分都成功之后再失败,这让人很恼火,而且您在确定失败的目标时也会失去宝贵的时间。创建快速失败构建的主要步骤如下:集成组件;运行真正的单元测试;执行其他自动化的过程。

构建类型:

  • 私有构建:开发者在向版本控制库提交代码之前,要先进行私有构建。
  • 集成构建:集成构建集成项目团队向版本控制库中的主线提交的变更。
  • 发布构建:准备好发布给用户的软件。

构建触发机制:

  • 用户驱动:由某人手工发起构建
  • 定期执行:由时间驱动,不论是否发生了变更。
  • 轮训变更:一个进程以固定的时间间隔唤醒,从版本控制库中签出变更。如果检测到变更,它就执行集成构建。
  • 事件驱动:与轮训变更类似,但是是由版本控制库出发的,基于实现定义好的变更事件。

使用CI服务器 – 如果您打算自己写一个CI服务器,可能需要包含下面的一些功能:

  • 以特定的时间间隔轮训版本控制库中的变更
  • 定期执行某种操作
  • 标识出“安静期”,在这段时间内项目不进行集成构建
  • 支持不同的构建脚本工具,包括命令行工具
  • 向相应人员发送电子邮件
  • 显示以前构建的历史
  • 显示一个web信息面板,这样每个人都可以查看集成构建的信息
  • 为不同的项目支持多个版本控制系统

执行快速构建 – 快速反馈对CI是很关键的。集成构建的时间越短,您就能越快收到反馈信息。可以按如下方式分析并减少构建时间:

  1. 收集构建测量数据
  2. 分析构建测量数据
  3. 选择并实现改进
  4. 重新评估,有必要则再次重复这个过程

集成构建测量的指标:

  • 编译时间
  • 源代码行数(SLOC)
  • 审查的种类数
  • 平均组装生成时间
  • 测试执行时间(根据分类)
  • 成功构建和失败构建的比例
  • 审查时间
  • 部署时间
  • 重建数据库的时间
  • 集成构建计算机系统资源和使用情况
  • 版本控制系统的负载

可以采取的改进方法:

  • 使用专门的集成构建计算机
  • 增强集成构建计算机的硬件能力
  • 改进测试性能
  • 安排集成构建的顺序
  • 优化基础设施
  • 优化构建过程
  • 单独构建系统组件
  • 改进软件审查的性能
  • 执行分布式集成构建

About Kaveri, Yi XU

Agile Coach & Consutlant
This entry was posted in 文章转载. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s