持续交付发布可靠软件的系统方法(基础篇)第三章:持续集成

《持续交付发布可靠软件的系统方法》读书笔记

持续集成要求每当有人提交代码时,就对整个应用进行构建,并对其执行全面的自动化测试集合,一旦出现问题,开发团队应停下手中的工作,修复问题。
持续集成的目标是:让正在研发的软件一直处于可工作的状态。

实施持续集成的先决条件

  • 版本控制,与项目相关的所有内容都必须提交到一个版本控制库中(产品代码、测试代码、数据库脚本、构建与部署脚本、以及所有用于创建安装运行和测试该应用的程序的东西)
  • 自动化构建:必须满足人和计算机都能通过命令行自动执行应用的构建、测试以及部署过程
  • 团队共识:持续集成是一种实践,需要团队所有成员都遵循规则

一个基本持续集成系统

  • 第一次在持续集成工具上执行构建时,可能会缺少一些必须的软件及配置,请将所操作的工作记录下来,并放在自己项目的知识共享库中,应花一些时间将应用程序所依赖的所有软件和配置项提交到版本控制系统中,并将重建全新环境的整个活动变成一个自动化的过程
  • 查看一下是否有构建正在运行,如果有,等它运行完。如果它失败了,则与团队其他人一起将它修复,后再提交自己的代码
  • 一量构建完成且测试全部通过,就从版本控制库中将该版本的代码更新到自己的开发环境上
  • 在自己的开发机上执行构建脚本、运行测试,以确保所有代码在本地工作正常
  • 如果本地构建成功,就将代码提交到版本控制库中,然后等待包含本次提交的构建结果
  • 如果构建失败,就停下手中的工作,立即修复这个问题,本地测试通过后,再次提交代码到版本控制库中
  • 如果构建成功,开始下一项任务

持续集成的前提条件

  • 频繁提交,开发始终在主干上提交代码
  • 创建全面的自动化测试套件【单元测试(10m),组件测试(较长),验收测试(长)】

理想情况下,提交前的预编译和测试过程与持续集成服务器上的编译和测试过程都应在几分钟内结束,10m是极限,90s内完成最理想。
如果测试过程太久,则需要找出那些运行较慢的测试,优化它,缩短测试时间。
测试分为两个阶段:提交阶段、提交后阶段

  • 提交阶段:运行所有类别的单元测试,并构建部署的二进制文件。提交前运行一次,通过后再提交到持续集成环境再运行一次
  • 提交后阶段:进行验收测试、集成测试,一旦提交测试通过,立马运行验收测试。如果超过30m,就要考虑采用高性能多进程机器缩短测试时间

使用持续集成软件

  • 触发Job或轮询版本控制系统,如果有更新,运行构建脚本及测试
  • 提供展示这个流程运行结果的视图,并通知报告 ,拿到生成它的安装文件等

必不可少的实践

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

推荐的实践

  • 极限编程开发实践
  • 若违背架构原则,就让构建失败
  • 若测试运行变慢,就让测试失败(2s)
  • 若有编译警告或代码风格问题,就让构建失败

在持续集成系统之上的扩展

持续集成的实施迫使你遵循两个重要的实践:

  • 良好的配置管理
  • 创建并维护一个自动化构建和测试流程

一个好的持续集成系统是基石,在此之上你可以构建更多的基础设置:

  • 一个巨大的可视化指示器,用于显示构建系统所收集的信息,以提供高质量的反馈
  • 结果报告系统,以及针对自己测试团队的安装包
  • 为项目经理提供关于应用程序质量的数据的提供程序
  • 使用部署流水线,可以将其延展到生产环境,为测试人员和运维团队提供一键式部署系统

你可能感兴趣的:(持续交付发布可靠软件的系统方法(基础篇)第三章:持续集成)