持续交付-入门介绍

持续交付

目的

  • 快速发现错误

    • “快速失败”,在对产品没有风险的情况下进行测试,并快速响应;

    • 每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易。

    • 最大限度地减少风险,降低修复错误代码的成本;

  • 将重复性的手工流程自动化

    • 让工程师更加专注于代码;
  • 保持频繁部署,快速生成可部署的软件;

  • 防止分支大幅偏离主干。如果不是经常集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成。

  • 增强开发人员对软件产品的信心

    • 提供项目的能见度,方便团队成员了解项目的进度和成熟度;

    • 帮助建立更好的工程师文化;

准则

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

  • 所有人投入一定的精力

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

  • 有限性依赖于团队的纪律

实现方式

  • 准备工作

    • 版本控制

      • 产品代码

      • 测试代码

      • 数据库脚本

      • 构建脚本

      • 部署脚本

    • 自动化构建

      • 前提条件

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

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

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

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

  • 持续集成系统

    • 工具

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

    • 工作步骤

      • 7个步骤的流程图随后可以画一个
    • 期望结果

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

前提条件

  • 频繁提交

    • 每天至少几次

    • 代码的主干-分支

      • 提交到主干

      • 不推荐使用分支

      • 分支无法实现持续集成

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

    • 单元测试

      • 对象

        • 每个方法

        • 每个函数

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

      • 十分钟内完成所有测试

    • 组件测试

      • 测试几个组件的行为

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

      • 需要较长时间完成测试

    • 验收测试

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

      • 其它方面

        • 容量

        • 有效性

        • 安全性

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

      • 运行一整天或者更长

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

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

    • 效率工具

      • JUnit

      • NUnit

    • 将测试分成若干阶段

      • 第一阶段:提交阶段

        • 编译软件

        • 执行单元测试

        • 构建部署包

        • 冒烟测试(可选)

      • 第二阶段

        • 验收测试

        • 集成测试

        • 性能测试(可选)

        • 任务可以并行

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

  • 管理开发工作区

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

    • 精细的配置管理是基础

    • 注意依赖的库文件

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

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

使用持续集成软件

  • 基本操作

    • 动作

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

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

  • 铃声和口哨

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

    • 第一时间了解构建状态

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

    • 相关分析

      • 测试覆盖率

      • 重复代码

      • 编码标准的遵从

      • 健康指标

最佳实践

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

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

    • 保证构建一直是绿的

    • 预提交测试

      • pretested commit

      • personal build

      • preflight build

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

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

  • 构建必须成功后才能回家

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

    • 不能在构建失败的情况下提交代码
  • 回滚前要规定一个修复时间

    • 例如:十分钟无法修复代码就回归到前一个版本
  • 不要将失败的测试注释掉

  • 为自己所导致的问题负责

  • 使用测试驱动开发

推荐实践

  • 极限编程开发实践

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

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

    • 本地测试容忍时间:秒级

    • 尽早解决测试的性能问题

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

    • 代码检查工具

      • Simian

      • CheckStyle

      • FindBugs

    • 提高代码质量

小结

  • 快速发布。能够应对业务需求,并更快地实现软件价值。

  • 编码->测试->上线->交付的频繁迭代周期缩短,同时获得迅速反馈;

  • 高质量的软件发布标准。整个交付过程标准化、可重复、可靠。

  • 整个交付过程进度可视化,方便团队人员了解项目成熟度;

  • 更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作,相比于传统的瀑布式软件团队,更少浪费。

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

  • 需要良好的团队记录

  • 相关基础设施

    • 一个巨大的可视化指示器

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

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

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

持续集成-实践

  • 实践工具

    • Jenkins

参考

下篇文章 持续交付-Jenkins官网文档阅读笔记

    原文作者:数学视角
    原文地址: https://www.jianshu.com/p/6fc76d919a58
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞