《持续交付》读书笔记-第三章-持续集成

关于《持续交付》这本书,有评论称之为“持续交付精华的蒸馏水”


《持续交付》读书笔记-第三章-持续集成_第1张图片

“Continuous Delivery: Reliable Software Releases Through Build, Test, and and Deployment Automation”, Jez Humble, David Farley, Addison Wesley, 2010

  • 京东中文版有售:https://item.jd.com/10843669.html
  • 英文亚马逊地址: http://www.amazon.in/dp/0321601912

内容概要:

  • 一本持续交付早期的书
  • 它的出版其实在 DevOps 被热炒之前,但是它还是道出了DevOps概念的精华
  • 此书分为三部分:Foundation, The Deployment Pipeline, 和 The Delivery Ecosystem
  • 本书基于作者的时间经验,并涉及到重要的方面,如功能割接

以下是本章读书笔记脑图的图片以及之上的文字内容。
本图在Mac OS X上用MindNode软件编辑。下载MindNode原文件

CD-3-持续集成

目标

让正在开发的软件一直处于整体可以工作的状态

任何人提交代码之后,对整个应用做构建,并执行全面的自动化测试集合

如果有任何失败发生,团队要停止手头工作先修复错误

准则

持续集成不是工具,而是一种实践

所有人投入一定的精力

修复那些破坏了应用的任意源代码修改是团队优先级最高的任务

有限性依赖于团队的纪律

实现方式

准备工作

版本控制

  • 产品代码

  • 测试代码

  • 数据库脚本

  • 构建脚本

  • 部署脚本

自动化构建

  • 前提条件

    • 人和计算机都能通过命令行自动执行应用的构建、测试以及部署过程
  • 目标

    • 自动化执行整个过程,能对出现问题的做审计

    • 构建脚本应该与应用代码同等对待

    • 构建过程应该容易理解、维护、调试和协作

持续集成系统

厂商-工具

  • Handson

    • Jenkins
  • CruiseControl

    • CruiseContrul

    • CruiseContrul.NET

    • CruiseContrul.rb

  • ThoughtWorks

    • GoCD
  • TeamCity

  • Bamboo

  • Pulse

  • AntHillPro

  • ElectricCommander

  • BuildForge

文档记录和自动化持续集成构建服务器的配置

工作步骤

  • 7个步骤的流程图随后可以画一个

期望结果

  • 环境只要与我的持续集成环境一直,我的软件就可以工作

前提条件

频繁提交

每天至少几次

代码的主干-分支

  • 提交到主干

  • 不推荐使用分支

  • 分支无法实现持续集成

创建全面的自动化测试集合包

单元测试

  • 对象

    • 每个方法

    • 每个函数

    • 一组方法和函数之间的调用

  • 十分钟内完成所有测试

组件测试

  • 测试几个组件的行为

  • 可能需要连接数据库、访问文件系统、外部接口

  • 需要较长时间完成测试

验收测试

  • 测试是否满足预定义的业务需求

  • 其它方面

    • 容量

    • 有效性

    • 安全性

  • 整个应用最好运行在类生产环境

  • 运行一整天或者更长

构建和测试过程维护在更短的时间内

理想的时间:十分钟内,最好五分钟内,越短越好

效率工具

  • JUnit

  • NUnit

将测试分成若干阶段

  • 第一阶段:提交阶段

    • 编译软件

    • 执行单元测试

    • 构建部署包

    • 冒烟测试(可选)

  • 第二阶段

    • 验收测试

    • 集成测试

    • 性能测试(可选)

    • 任务可以并行

    • 大于半小时就需要通过投入更多运算资源降低时间消耗

管理开发工作区

从一个已知最新的正确版本的起点开始

精细的配置管理是基础

注意依赖的库文件

应用可以在开发机上跑起来

自动化测试(含冒烟测试)能在开发机上跑通

使用持续集成软件

基本操作

动作

  • 第一部分:按时间间隔执行工作流水线

  • 第二部分:展示流水线运行结果

铃声和口哨

使用声光电等提示错误提示手段

第一时间了解构建状态

现在可以发送:Slack等即时线上通讯手段

相关分析

  • 测试覆盖率

  • 重复代码

  • 编码标准的遵从

  • 健康指标

最佳实践

构建失败后停止新代码提交

提交前在本地和持续集成服务器测试执行所有目标测试

保证构建一直是绿的

预提交测试

  • pretested commit

  • personal build

  • preflight build

在本地测试将要提交的代码

等提交通过之后再继续工作

构建必须成功后才能回家

随时准备回滚到前一个旧版本

不能在构建失败的情况下提交代码

回滚前要规定一个修复时间

例如:十分钟无法修复代码就回归到前一个版本

不要将失败的测试注释掉

为自己所导致的问题负责

使用测试驱动开发

推荐实践

极限编程开发实践

若违背了架构原则,就让构建失败

若测试运行变慢了,就让构建失败

本地测试容忍时间:秒级

尽早解决测试的性能问题

若编译告警或代码风格有误,就让测试失败

代码检查工具

  • Simian

  • CheckStyle

  • FindBugs

提高代码质量

分布式团队

对流程的影响

集中式持续集成

技术问题

替代方法

分布式版本控制系统

小结

持续集成提高了团队的生产效率

需要良好的团队记录

相关基础设施

一个巨大的可视化指示器

结果报表系统,供给给测试团队的安装包

为项目经理提供项目资料监测的应用或报表

用持续部署的流水线,为所有人员提供能延伸到生产环境的一键式部署

你可能感兴趣的:(《持续交付》读书笔记-第三章-持续集成)