《持续交付-发布可靠软件的系统方法》全书51.2万字,15章,384页。本次阅读第三章持续集成,大概42页。
持续集成最早出现在Kent Beck写的《解析极限编程》一书中,主要思想:既然经常对代码库进行集成对我们有好处,为什么不随时做集成呢?《持续交付》第三章主要讲述如何实现持续集成。
在本书中,对持续集成的定义如下:持续集成是一种软件开发实践。在持续集成中,团队成员频繁集成他们的工作成果,一般每人每天至少集成一次,也可以多次。每次集成会经过自动构建(包括自动测试)的检验,以尽快发现集成错误。自从在团队中引入这样的实践之后,Martin Fowler发现这种方法可以显著减少集成引起的问题,并可以加快团队合作软件开发的速度。
1、实现持续集成
1.1 准备工作
1.版本控制
使用SVN或者git免费工具可以进行版本控制。
2.自动化构建
有以下理由持续推进自动化构建:
- 能够在持续集成环境中以自动化的方式来执行整个构建过程,以便出现问题时能够审计。
- 应将构建脚本与代码库同等对待。应该对它测试,不断重构,以便使它保持整洁且容易理解。
- 使理解、维护和调试构建过程更容易,并有利于和运维人员更好的协作。
3.团队共识
团队认同:“修复破坏应用程序的任意修改是最高优先级的任务”。
2 持续集成的前提条件
2.1. 频繁提交
2.2 创建全面的自动化测试套件
三类测试在持续集成构建中使用:单元测试,组件测试和验收测试。
将验收测试按照功能模块分组通常是可取的。这样,当仅修改了系统中的个别模块功能时,就可以单独运行影响系统这部分功能的验证测试。很多单元测试框架都是提供这样的分组功能。
2.3 保持较短的构建和测试过程
2.4 管理开发工作区
三点:1)细心的配置管理 ;2)对第三方以来的配置管理 ;3)确保自动化测试在开发机可以运行。
3 使用持续交付软件
3.1 基本操作
两个部分:每隔一段时间周期运行一次工作流程;提供展示运行结果的视图。
3.2 铃声和口哨
失败可以用灯等设备提示,可以在流程加入圈复杂度,重复代码,静态检查等环节。
4 必不可少的实践
持续集成是一种实践,不是一个工具,他的有效性依赖于团队纪律。
4.1 构建失败后不要提交新代码。
4.2 提交前,在本地运行所有的提交测试。或者让持续集成服务器完成此事。
功能:预测试提交,个人构建。
4.3 等测试提交通过后再继续工作。
4.4 回家之前,构建必须处于成功状态。
4.5 时刻准备着回滚到前一个版本
4.6 在回滚之前要规定一个修复时间
4.7 不要将失败的测试注释掉
4.8 为自己导致的问题负责
4.9 测试驱动的开发
5 推荐的实践
5.1 极限编程开发实践
重构作为高效软件的开发基石。持续改进和测试驱动开发让TDD成为可能。
5.2 若违背架构原则,就让构建失败
5.3 若测试运行变慢,就让构建失败
5.4 若编译告警或代码风格问题,就让测试失败
6 分布式团队
6.1 对流程的影响
信任很重要,同时视频会议相互了解功能和进展。
6.2 集中式持续集成
集中式的持续集成是一种双赢的实践。
6.3 技术问题
推荐Git
6.4 替代方法
两个方式:分解系统为多个组件;使用分布式版本控制系统
7 分布式版本控制系统
介绍github的设计思想。
小结:
总之,一个好的持续集成系统是基石,在此之上你可以构建更多的基础设施:
--一个巨大的可视化指示器,用于显示构建系统所搜集到的信息,以便提供高质量的反馈;
- 结果报告系统,以及针对自己测试团队的安装包。
- 为项目经理提供关于系统质量的数据报告
- 使用部署流水线,可以将其延展到生产环境,为测试人员和运维团队提供一键式部署系统。