持续集成
持续集成:个体不断向主干分支快速迭代的过程,强调开发的及时性,以保障局部和整体开发进度的协调,使软件随时处于可运行状态.同时避免像瀑布模型那样集中提交,引起大量冲突的情形;这里会执行单元测试.组件测试和功能性验收测试
解决什么问题
软件随时处于可工作状态,每次提交都会进行功能合格验证,保障功能和预期是一致的.
怎么做
实现持续集成
- 准备工作
- 版本控制.即对于应用关联因素进行版本化管理,实现流程可控,可追溯.
- 自动化构建.有人参与就会存在风险;自动化构建,可以避免人参与,量化所有指标,实现快速,高质集成.
- 团队共识.需要所有人参与,配合.
- 一个基本的持续集成系统
- 使用一些构建工具辅助持续集成,持续集成虽然不是一种工具,但是工具确实可以加速这个过程
- 获取版本库中代码.只有本地测试没有问题的代码才能提交到版本库中
- 进行开发,完成后进行本地构建,成功后提交到版本库
- 等待提交构建结果
- 如果有问题,立即解决后转入步骤3
- 构建成功后继续其他开发工作
持续集成前提条件
- 频繁提交.主干分支频繁提交,可以快速验证提交内容是否可运行,可以快速回滚.保障主干分支随时可运行.
- 创建全面的自动化测试套件.单元测试,组件测试,验收测试.
- 保持较短的构建和测试过程.这个是为了保障团队的构建和测试积极性,如果单此操作时间超过10分钟,很难保障团队成员会遵守.所以将构建和测试划分为两个阶段:编译阶段,进行单元测试,快速且较全面的测试;提交阶段,针对第一阶段的二进制文件进行验收和集成测试.
- 管理开发工作区.就是构建内容,本地易于部署,实现;包括版本管理,依赖管理,自动化测试都可以较简便的在本地执行.
使用持续集成工具
持续集成工具的核心功能
- 定时或通过触发机制发现版本变更,触发持续集成流水线
- 展示持续集成结果.结果包括了测试和各种指标分析,可以直观的看到是否成功,失败事项以及提交人是谁.
必须执行的实践
- 构建失败后不要提交新代码.所有人都有义务保证版本库中代码是可执行代码;
- 提交前必须在本地或持续集成服务器进行提交测试.这种方式有利于快速发现问题
- 提前发现问题,避免影响扩散.
- 可以快速定位问题.本地执行成功,服务器执行失败,只能是自己提交时缺失文件;或者别人的代码异常引起;
- 等提交测试通过后再继续工作
- 保证自己触发的构建处于成功状态.多团队协助时这个很重要,可以避免自己的工作影响别人.
- 时刻准备回滚到前一个版本.如果不能快速解决问题,就先回滚上一个版本,等解决后再进行该提交.保证代码库的代码一直是可执行状态.
- 在回滚之前要规定一个修复时间.可以约定一个回滚等待期,比如10分钟,超过该时间还未解决就必须马上回滚,避免影响扩大.修改后经过本地验证后,如果还不能正常运行,直接再次回滚,不再进行等待.
- 不要将失败的测试注释掉.注释测试虽然能让当此成功,但会掩盖产品缺陷的事实,会降低产品质量,长时间下去可能测试就会实去价值.可以定义一个修改测试的比例,比如2%,超过这个修改比例就让构建直接失败.
- 为自己导致的问题负责.实际中有可能存在关联代码,你的修改如果让其他地方的测试失败,你有责任去修复这些测试内容.这样意味着,每个成员都有全局修改代码的权限.
- 测试驱动开发.指当开发新功能或修复缺陷时,开发人员首先写一个测试,该测试应该是该功能的一个可执行规范.该测试不但驱动了设计,又是回归测试和代码说明文档.
推荐的实践
除了上面必须实施的实践内容,还有一些推荐实践,也可以加速以及保障软件质量
- 极限编程开发.12原则.通过规范,良好的沟通,明确的规划,较全面的测试,重构,功能拆解等方式,较全面的告诉成员共同的愿景,快速且高质的完成工作.
- 若违背架构原则,就让构建失败.组件间调用,应该是远程调用,但是本地调用也可以触发业务执行,但是这种行为就违背了架构设计,应该进行制止.
- 若测试运行变慢,就让构建失败.这是为了提高测试代码质量,同时还要注意一些通过片面测试来提高测试速度的行为,这个需要具体分析,看团队的规范.
- 若有编译警告或代码风格问题,就让构建失败.优质的代码,可以降低运行风险.