本文主要是介绍【读书笔记】持续交付，发布可靠软件系统的方法，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
持续交付，发布可靠软件系统的方法
思维导图地址如下
持续交付、发布可靠软件系统的方法
前言
周期时间
- 决定做某种修改到该修改结果正式上线
- 减少周期时间并建立有效反馈环节
敏捷宣言
- 首要任务是尽早持续交付有价值的软件并让客户满意
整体优化
- 用一种整体方法将交付过程中各个方面以及参与该过程的所有人联系在一起是非常必要的
软件交付的问题
部署流水线
- 指一个应用程序从构建、部署、测试到开发这整个过程的自动化实现
- 以持续集成为理论基础
- 提交构建----->自动化测试-------->容量测试------->手工测试-------->发布
- 高度自动化测试和部署+全面的配置管理
减少当天发布压力
确保每次发布可靠性都是可预见的
发布反模式
-
手工部署软件
-
问题
- 详细的文档
- 手工测试
- 发布中的配置检查
- 发布时间过长
- 可能需要回滚
-
解决方式
- 选择版本
- 选择环境
- 一键部署
- 使用相同的脚本部署到各种环境上
-
思考点
- 如何快速搭建一套环境，降低成本
- 生产问题复现或者模拟，对应环境搭建，修复上线，环境铲除，节省资源
-
-
开发完成之后才向类生产环境部署
-
问题
- 开发、测试、模拟生产、真实生产环境配置不一致
- 运维团队只在开发完成时做部署，存在第一次去部署情况
-
解决方式
- 各个环境的配置中间件以及版本保持一致
- 测试、部署、发布活动都需要纳入开发过程
-
思考点
- 多套环境时，需要和生产环境保持一致，中间件、版本、镜像版本等
- 上生产之前做模拟演练
-
-
生产环境的手工配置管理
-
问题
- 运维团队手动修改prd基础配置或者application配置，如果忘记登记，后续会存在问题
-
解决方式
- 基础设施和服务配置采用自动化的配置
-
思考点
- 实现自动化配置的时候，需要考虑回滚问题，目前的版本的配置信息和历史版本的配置信息
-
快速交付质量足够高的软件
-
速度和效率
-
软件的质量足够高
- 满足业务需求
- 代码的简单化
- 代码的可扩展和兼容性
-
自动化
- 构建
- 部署
- 测试
- 发布
-
频繁发布
-
版本差异小
-
容易回滚
-
加速反馈
-
修改触发反馈
-
可工作软件组成
- 可执行的代码
- 配置信息
- 运行环境
- 数据
-
-
反馈信息及时发出
- 版本控制
- 组织代码
-
针对反馈信息作出相应行动
-
反馈流程
- 代码编译通过
- 代码单元测试必须成功
- 满足一定质量标准，测试覆盖率以及阻断性问题
- 功能性测试和验收
- 非功能性测试和验收，性能，安全性
- 探索性测试，给客户demo功能
-
-
-
原则
-
自动化
-
构建、部署、测试、发布需要置于版本控制管理中
-
提前并频繁的做让你感到痛苦的事情
-
交付过程是每个成员的责任
-
持续改进
-
定期复盘，召开回顾会议
-
哪方面做的好，继续保持
-
哪方面做的不好，需要改进
- 讨论如何改进
- 每个改进点由专人follow，确定执行和有效
-
-
小范围内反馈，同时需要在大范围内形成反馈机制，避免相互指责的出现
-
-
配置管理
使用版本控制
- 源代码
- 文档
- 环境配置
- 数据库配置
- 测试脚本
- 构建脚本
- 部署脚本
频繁提交代码到主干分支
- 增量方式开发新功能，并频繁且有规律的向版本控制系统提交代码
- 使用意义明显的提交注释
依赖管理
-
外部库文件管理
- 建议在本地保存一份外部库的副本，如果使用maven，应该创建一个本地仓库，里面存放那些你的公司中统一使用的外部库
-
组件管理
可配置的软件
高效配置管理策略原则
- 将二进制文件与配置信息分离
- 将所有的配置信息保存在一处
工具
- Puppet
- CfEngine
持续集成
要求
- 每当有人提交代码时，对整个应用进行构建，并对其进行全面的自动化测试集合执行
先决条件
-
版本控制
-
频繁提交到主干分支
-
自动化构建
-
单元测试
- 应用程序中某个小单元的行为，不需要启动整个应用程序，也不需要链接数据库
- 整个单元测试套件执行完应该在10min之内
- JUnit或者NUnit，通过测试报告时长，来优化代码，提高执行速度
-
组件测试
-
验收测试
- 可以按照功能快分组进行验收
-
-
团队共识
开源工具
-
Hudson
-
CruiseControl.rb
-
zutubi pulse
-
Team City
-
Atlassian Bamboo
持续集成软件
-
最基本功能
- 轮询版本控制系统，查看是否有新的版本提交，如果有的话，拉取最新版本软件，运行构建脚本编译程序，运行测试用例
-
基本操作
-
一直运行的过程
-
持续集成的结果
-
成功
-
失败
- 原因
- 对应owner
-
-
-
持续集成中的分析
- 测试覆盖率
- 代码复杂度
- 代码重复率
- 健康指标
不可少的实践
- 构建失败后不要提交新代码
- 提交前在本地运行所有的提交测试，或让持续集成服务器完成这件事情
- 等提交测试通过后再继续工作
- 回家之前，构建必须处于成功状态
- 时刻准备着回滚到前一个版本
- 在回滚之前要规定一个修复时间
- 不要将失败的测试注释掉
- 为自己导致的问题负责
- 测试驱动开发
推荐的实践
- 极限编程实践
- 若违背架构原则，就让构建失败
- 若测试运行慢，就让构建失败
- 若有编译警告或者代码风格问题，就让测试失败
测试策略
设计
- 识别和评估项目风险的优先级，以及决定采用哪些行动来缓解风险的一个过程
书籍
- Agile Testing
分类
- 业务导向测试
- 技术导向测试
- 支持开发过程的
- 评判项目的
- 测试分类.png
测试替身
-
自动化测试的一个关键是在运行时用一个模拟对象来替代系统中的一部分
-
模拟对象
-
mock
- 在编程时就设定了它预期要接受的调用
- 如果收到了未预期的调用，就会抛出异常
-
spy
- 可以记录一些关于他们如何被调用的信息的桩
-
stub
- 在测试中为每个调用提供一个封装好的响应，他通常不会对测试之外的请求进行响应
-
dummy
- 那些被传递但不被真正使用的对象
- 通常这些dummy对象只是用于填充参数列表
-
fake
- 是可以真正使用的实现
-
回归测试
冒烟测试
Happy Path
Sad Path
Alternate Path
单元测试
组件测试
部署测试
测试、开发、分析师、客户定义详尽的测试验收case
DSL
- domain-specific language[领域专属语言]
- 书写验收条件
管理待修复的缺陷列表
最佳实践
- 反例：开发完成story1，在开发story2时，测试验收出现bug，打断开发去修复，此时效率会很低
- 推荐做法：开发完成后，测试可以在开发电脑做一次验收，在发布
部署流水线解析
概念
- 软件从版本控制库到用户手中这一过程的自动化表现形式
基本部署流水线图
- 基本的部署流水线.png
书籍
- learn software development:an agile toolkit
代码变更经过部署流水线过程图
- 代码变更经过部署流水线过程.png
阶段
- 提交阶段
- 自动化验收测试阶段
- 手工测试阶段
- 发布阶段
有用的度量项
- 测试覆盖率
- 重复代码数量
- 圈复杂度
- 输入耦合度
- 输出耦合度
- 编译警告数量
- 代码风格
构建和部署的脚本化
构建工具
-
核心功能
- 对依赖关系建模
-
分类
-
任务导向
-
Ant,MSBuild
- 会依据一系列的任务描述依赖网络
-
-
产品导向
-
Make
- 根据生成产物来描述
-
-
Ant
-
缺点
- XML写构建脚本
- 是一个贫血领域模型，花大量时间为编译、生成jar、运行测试等编写样板文件
- 声明式语言，提供少量命令式标签
- 关于Ant的任务
- Ant通过import和macrode任务支持重用
maven
-
特点
- 自动管理java库和项目之间的依赖
- 支持复杂且严格的软件分区方案
-
缺点
- 必须需要按照maven规定的结构和生命周期来组织
- 为了扩展，需要写代码。需要xml或者外部DSL
- 在默认配置中，是自动更新的
构建部署脚本化的原则和实践
- 为部署流水线的每个阶段创建脚本
- 使用恰当的技术部署应用程序
- 使用同样的脚本向所有环境部署
- 使用操作系统自带的包管理工具
- 确保部署流程是幂等的
- 部署系统的增量式演进
提交阶段
原则
-
提供快速有用的反馈
-
提交失败的原因
- 语法错误导致编译失败
- 语义错误导致一个或多个测试失败
- 应用配置或者环境方面导致
-
越早发现，越容易修复
-
-
何时让提交阶段失败
-
代码质量
- 阻断
- 测试覆盖率
- 代码复杂度
- 代码重复率
-
-
精心对待提交阶段
-
开发人员具有所有权
-
大型团队制定专门构建负责人
- 轮值，每个人都可以学到一些经验
实践
-
提交阶段的结果
-
输入
- 源代码
-
输出
-
二进制包和报告
- 测试报告
- 代码库分析报告
-
-
-
制品库
- 制品库角色.png
自动化验收和测试
如何写有效的验收测试
-
验收测试目的
- 验证一个用户故事或需求的验收条件是否被满足
-
验收条件类型
-
功能性验收条件
-
非功能性验收条件
- 容量
- 性能
- 可修改性
- 可用性
- 安全性
- 易用性
-
如何维护一个高效的验收测试套件
-
验收测试来源于验收条件
-
INVEST原则
- 独立性
- 可协商的
- 有价值的
- 可估计的
- 小的
- 可测试的
-
测试工具
- FitNesse
- Twist
测试驱动开发 TDD
非功能需求测试
容量 capacity
- 在一定的工作负载下，当每个单独请求的响应时间维持在可接受的范围内时，该系统所能承单的最大吞吐量
吞吐量 throughput
- 系统在一定时间内处理事务的数量，通常它受限于系统中的某个瓶颈
性能 performance
- 对处理单一事务所花时间的一种度量，既可以单独衡量，也可以在一定的负载下衡量
容量度量
-
扩展性测试
- 随着服务器数、服务或者线程的增加，单个请求的响应时间和兵法用户数的支持会如何变化
-
持久性测试
- 要长时间运行应用程序。通过一段时间的操作，看是否有性能上的变化，可以捕获内存泄漏或者稳定性问题
-
吞吐量测试
- 每秒能处理多少事务、消息和页面点击
-
负载测试
- 当系统负载增加到蕾丝PRD环境大小或者超过它时，系统的容量如何？
基准式容量测试
容量测试
-
目标
- 测试具体场景
- 预先设定成功门槛
- 尽可能让测试运行时间短一些
- 在变更面前变的健壮
- 组合成大规模的复杂场景
- 可重复且可并行或者串行执行
容量测试系统的附加价值
- 重现生产环境中发现的复杂缺陷
- 探测并调试内存泄漏
- 持久性测试
- 评估垃圾回收的影响
- 垃圾回收的调优
- 应用程序参数的调优
- 第三方应用程序配置的调优，操作系统，应用服务器或者数据库配置
- 模拟非正常的、最糟糕情况的场景
- 评估一些复杂问题的不同解决方案
- 模拟集成失败的情况
- 度量应用程序在不同硬件配置下的可扩展性
- 与外部系统进行交互的负载测试
- 复杂部署的回滚演练
- 有选择的使系统的部分或者全部瘫痪，从而评估服务的优雅降级
- 短期可用的生产硬件上执行真实世界的容量基准
应用程序的部署与发布
部署软件
发布软件
-
创建发布策略
- 每个环境部署和发布负责人
- 资产和配置管理策略
- 部署时所用的技术描述
- 部署流水线计划
- 枚举所有的环境
- 描述在测试和生产环境中部署应该遵循的流程
- 应用程序的监控
- 部署和运行时配置方法的管理
- 应用程序和所有外部系统如何集成
- 日志记录
- 灾备
- 软件服务级别
- 生产环境数量和容量计划
-
发布计划
- 发布文档
- 自动化脚本
- 流程步骤
-
发布产品
部署和发布的区别
-
回滚能力
-
零停机发布和回滚
-
蓝绿部署
-
蓝环境
-
绿环境
-
步骤
- 系统的用户被引导到当前正在作为生产环境的绿环境
- 新版本发不到蓝环境，让程序先热身
- 蓝环境进行冒烟测试
- 修改路由配置
- 从绿色环境进行导流
-
注意点
- 数据库的管理
-
-
金丝雀发布
-
概念
- 把应用程序的某个新版本部署到生产环境中的部分服务器中，从而快速得到反馈
-
好处
- 非常容易回滚
- 可以将一批用户引至新版本和旧版本，做A/B测试
- 通过逐渐增加负载，慢慢把更多的用户引到新版本，记录并衡量应用程序的响应时间、CPU使用率、I/O、内存使用率和日志
-
-
-
发布回滚通用原则
- 发布之前，确保生产系统的状态已经备份
- 发布之前都练习一下回滚计划，包括数据、服务、中间件
-
零停机发布（热部署）
-
概念
- 将用户从一个版本几乎瞬间转移到另一个版本
-
关键
- 发布流程中的不同部分解偶，尽量使他们能独立发生
-
-
基础设施和环境管理
数据管理
组建和依赖管理
版本控制进阶
持续交付管理
XMind - Trial Version
这篇关于【读书笔记】持续交付，发布可靠软件系统的方法的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
