《持续交付:高效率和高质量可以兼得.pdf》由会员分享,可在线阅读,更多相关《持续交付:高效率和高质量可以兼得.pdf(23页珍藏版)》请在金锄头文库上搜索。
1、持续交付-高效率和高质量可以兼得 互联网时代对IT交付的诉求 专注专注、极致极致、口碑口碑、快快 快速迭代快速迭代 快速转型 快速转型 只有第一只有第一,没有第二没有第二 用户体验至上用户体验至上 细节决定成败细节决定成败 缺陷缺陷-差评差评-卸载卸载 服务故障服务故障 - 市场丢失市场丢失 我们处在一个我们处在一个VUCAVUCA的时代的时代 IT交付面临易变性、不确定性、复杂性、模糊性 效率 质量 VSVS 2016 IT交付能力对比 如何成为高效能组织? 图片来源:Lean Enterprise Water-Scrum-Fall 无法达到目标 最后一公里痛苦和难以预测的集成与测试,使得发
2、布周期更长,导致项目延期、交付质量低、用户不满意 整体改进的效果优于局部优化 DevOps:建立IT服务的供应链 图片来源:DevOps Master Whitepaper: Success with Enterprise DevOps 持续交付是DevOps的最佳工程实践 持续交付的加速度 如何每天发布100次 图片来源:Lean Enterprise 分支模型 Feature Branch RD在自己的分支工作,隔离其他工作变更 场景A:分支开发,分支发布,发布后合并主干 场景B:分支开发,分支测试,主干回归,主干发布 存在的问题存在的问题: 最终还是要集成,如果不同分支代码有交互,合并时
3、大量冲突需要解决(文本冲突、语意冲突) 合并冲突时易出错,发布后容易忘记合并回主干 每个分支建立单独的测试流水线,浪费资源,并且其实未实施集成测试 带来的好处带来的好处: 多个Feature完全并行开发,互不影响 可以选择Feature进行发布,不会被其他功能阻塞 分支模型 Trunk Based Development RD经过充分的本地验证后,频繁提交代码到主干 场景A:主干开发、主干发布 场景B:主干开发、分支发布 存在的问题存在的问题: 主干上功能开发有先后,有未完成的功能但又需要发布时,需要能隐藏未完成部分 为了避免以上情况,有三种递进的方式: (1)功能拆分,小批量频繁发布;(2)
4、后端先行,UI或功能入口后发布;(3)功能开关,配置决定功能 带来的好处带来的好处: 主干持续集成,在冲突形成的早期发现 主干一直健康,每次合入后都可安全发布 By RD Automated Job By QA R A Q 8.Release Test Q 7.Branch Out R 9.Cherry-pick R Local Branches Master Branch Release Branches 10.Release R 1.Change Request R 4.Merge To Master R 0.Local Build R 2.CR Build A 5.Check-in Bu
5、ild A 3.Code Review R 6.Integration Test Q Daily Build A 测试管理 快速反馈 快速反馈的价值快速反馈的价值:更高质量更高质量 - 减少返工减少返工 - 缩短周期缩短周期 - 降低成本降低成本 在早期捕获和解决错误,降低修复成本 小批量地推进工作,减少在制品数量 每个阶段都保证质量,降低传输成本 组织学习更快,整个团队更好的协作 Reference : The History of DevOps And what you need to do about it Damon Edwards 测试管理 测试分级 分级 测试模型 建立分级测试体系
6、建立分级测试体系,从多个层次和多个验证角度实现质量防护网 从多个层次和多个验证角度实现质量防护网 测试管理 持续集成 不仅是技术不仅是技术,重点是原则的坚持重点是原则的坚持 小的改动,逐步构建 每人、每天提交代码 在主干上做持续集成 至少要每天进行集成 使用好持续集成工具 自动化的构建和测试 分级测试并快速反馈 红灯需要立即被修复 全量部署包全量部署包 包含服务正常运行需要的所有程序Binary、配置、数据、额外的依赖等,在任何一台标准配置机器中,都可以完整、正常的部署、启动 提供稳定的控制接口提供稳定的控制接口 Start、Stop、Restart、Reload、Status 差异化部署使用
7、配置派生差异化部署使用配置派生 规范的模板文件(.template文件)和对应的value文件,提供给部署系统 自定义上线步骤自定义上线步骤 operation_list:DSL描述上线操作步骤 部署管理 部署包规范 GIT/SVN 构建 回溯 标准化部署包规范标准化部署包规范,提升大规模部署时的自动化程度提升大规模部署时的自动化程度 源代码,测试代码,部署脚本,编译配置,应用配置,数据描述,做包描述 部署管理 配置注入的方式 场景:少量配置文件或配置每次随程序变更 优点:部署简单,不同环境使用特定包部署 缺点:环境、程序、配置紧耦合,灵活性低 场景:大量配置项,不同环境存在差异 优点:使用部
8、署器,动态生成配置信息 缺点:维护匹配关系,增加复杂度 场景:频繁变更配置项,或需动态加载 优点:彻底解耦,较高的灵活性 注意:配置中心的高可用性和一致性 ?部署管理 最佳实践 部署管理的最佳实践部署管理的最佳实践 部署包全部来自制品仓库 各环境使用相同部署方式 各环境使用相同部署脚本 部署流程编排,阶梯式晋级 运维人员参与部署过程创建 只有流水线才可变更生产环境,防止配置漂移 不可变(Immutable)服务器 热部署:蓝绿部署、金丝雀发布 自动化测试 自动化测试 自动化 监控 自动化 监控 自动化测试 自动化测试 自动化测试 自动/手工测试 自动化测试 产品A 测试环境 产品B 测试环境
9、产品C 测试环境 编译集群 单元测试 模块测试 提交代码 主干持续集成 沙盒 测试环境 预上线 环境 内网 生产环境 外网 生产环境 自动部署 自动部署 自动部署 自动部署 自动部署 自动部署 自动部署 自动部署 拉分支 源码库 代码代码、配置配置、脚本 脚本 系统测试 分支发布 自动化编译 自动部署 自动部署 候选发布版本 候选发布版本 低风险的发布 灰度策略 将部署与发布解耦将部署与发布解耦: 部署:将特定版本安装到特定环境 技术决策 发布:让特性对客户可见 业务决策 图片来源:Development_and_Deployment_at_Facebook 低风险的发布 数据库兼容性 将应用
10、程序与数据库迁移解耦将应用程序与数据库迁移解耦: 尽量避免一次性进行所有变更 将变更分解为一系列可逆的步骤 时 间 轴 DB Version V14 App Version V1.2.1 DB Version V13 App Version V1.2.2 DB Version V15 应用程序 向前/向后兼容 兼容数据库 V13 & V14 兼容应用 V1.2.1 & 1.2.2 新版数据库 新增字段/表 老版本数据库 匹配数据库 V14 新版应用程序 匹配最新数据库 匹配应用 V1.2.2 新版数据库 移除不用的旧字段 匹配老版本 应用程序 提炼更完整的持续交付体系 ? ? ? ? ? ?
11、? ? ? ?建立可靠可重复的交付流水线 通过流水线阶段晋级通过流水线阶段晋级,平衡测试反馈速度与覆盖度平衡测试反馈速度与覆盖度 通过流水线分析瓶颈通过流水线分析瓶颈、识别自动化改造点和协作点识别自动化改造点和协作点 20 交付流水线的工具实现 开源方案开源方案: JenkinsJenkins、 BambooBamboo、GoCDGoCD、SpinnakerSpinnaker、CodePipelineCodePipeline 持续交付改进效果 编译 单元测试 模块测试 系统测试 发布发单 上线 上线检查 持续交付 改进之前 编译、开发、测试、部署上线全面加速,整体交付周期显著缩短 各角色可以基于统一的交付流水线紧密协作,产品交付过程可视化、可控制 每日多次发布能力、故障快速回滚的能力 持续交付的价值 快速交付快速交付 从需求到交付端到端周期缩短 保证质量保证质量 效率提升的同时,保证质量稳定 降低风险降低风险 稳定节奏的交付, 增强可预测性 Q & A