持续交付 《持续交付——Reliable Software Release through Build,Test,and Deployme

laofo · 2014年08月14日 · 1 次阅读

作者 :木头熊 sz

  之所以标题中引用英文,是因为这句英文非常贴切的概括了全书的核心内容。

  这本书是在持续集成、持续交付领域的扛鼎力作,难怪能获得 Jolt 图灵大奖。书中内容既有全面的体系、又有深入的分析,以部署流水线(streamline)作为核心手段,涉及配置管理、数据管理、组件和依赖管理、基础设施和环境管理、自动化构建和测试等配套机制。虽然书中内容有意避免挂靠敏捷开发模式,但快速交付、缩短反馈周期、消除浪费等敏捷 - 精益思想贯穿始终。

  对比部署流水线的最佳实践和我们当前的水平,可以看到还存在不少差距。粗浅分析,至少包括以下 7 点:

  a) 制品库的管理和一致性:交付全流程各环节及环境中,应该共享并使用同一个 ear 包,而不是每个环节自己打包。我们在 CI 环境经过集成与测试的包,理论上可以进入共享制品库,为下一个环节直接取用,既保证一致性、又提高流转效率。   b) 对配置和基础设施的全面配置管理:一个系统运行的完整环境(包括应用配置、中间件配置、OS 网络防火墙配置、操作系统补丁、直到虚拟机的硬件配置),都应该与程序代码同源进行配置管理,并用 puppet 之类的工具进行状态管理,以便在任何时候都能自动化创建/或恢复到一个任何版本的应用环境,且对环境的任何修改都应该通过自动化过程来完成。这就是 Infrastructure as Code。   c) 主干开发:开发人员至少每天 1 次将代码提交到主干,以便做到真正的持续集成。这种模式与传统分支模式是截然不同的思考方式,在 CC 工具本身的流策略决定了它不可能是主干开发,庆幸的是我们正在转移到 SVN 上。我们平时提及的"单流开发",是一种更高的境界,演化过程应该是:分支开发->主干开发->短发布分支->真正的单流。   d) 容量测试:性能测试与功能测试一样,应该成为一个自动化的环节加到部署流水线中,并且有具体的、可明确衡量的成功标准。对于一般的压力测试(即容量测试),并不需要运行很长时间。不过这个有时候收到软件 license 的制约。   e) 一键发布:我们基本做到了 STG 环境的一键发布(除了当涉及 b 中所述的配置和基础设施时),生产还没有做到,不过这个其实已经具备技术条件,只是时机问题。与人工的操作(像是一门"艺术")相比,自动化的操作(实际上是"科学"的过程)才能保证不出错。从精益的视角看,一键发布就是一个"拉动"系统,由运营/测试根据需要来拉动部署。   f) 小步提交:每一次的代码提交都应触发自动化构建和测试,这才能叫持续集成,否则只能叫"每日构建"。更频繁的提交依赖于开发人员的意识与能力,关键能力是如何切分需求,对一个 story 开发的过程,依然要有"纵向切蛋糕"的意识,每一次提交,都是一个纵向切片,这样每次提交都有价值、提交后系统都可以运行。   g) 开发运营合作:对部署流水线的优化,就是一个端到端的价值流优化、跨职能的合作、持续改进和消除浪费的过程,软件交付过程的各方(开发、运营、基础架构),应该定期回顾,检视如何缩短 cycletime。这需要解决开发和运营 incentive 冲突的问题,属于 devops 的范畴了。

其他方面的一些体会,枚举如下:

  1)"Done"意味着"已发布"或者是已演练过发布过程的"可发布"   2) 提交阶段的测试(相当于我们的 cud),10 分钟已经是极限   3) 持续集成的 9 条纪律,例如 No.1 构建失败之后不要提交新代码;No.2 提交前在本地运行所有的提交测试;etc.   4) 能够达到完美单元测试覆盖率的唯一办法,就是使用 TDD。TDD 既驱动设计、也是回归案例、又是代码文档   5) 单元测试的目的是证明系统是按照开发人员的思路来运行的,自动化验收测试的目的是证明系统实现了客户想要的   6) 要避免验收测试的脆弱性,验收测试需要分层,从 Given-When-Then 的 AC,到 DSL 测试实现层,才到应用驱动层   7) 自动化验收测试的拥有权不是测试人员,而是整个团队   8) 原有灰度发布有个优雅的名字,叫做"金丝雀发布"。另外还有一种模式叫"blue-green 发布",我们目前的生产服务器备份机制可以实现(目前没有这样用,想的话可以)   9)If it hurts, do itmore often。这句话是 XP 的座右铭,太经典了   10) 很多事情是"反直觉"的,例如持续部署,当 2 次部署之间间隔非常短、修改量非常小的时候,其实是最安全的   11) 数据库的 CI,原来已经有经典论著,一本叫《RefactoringDatabase》,一本叫《Recipes forContinuous Database Integration》,前者已经有同事在看了   12)如果一个团队的不同成员在不同的分支或流上工作的话,那么,按照定义,他们就不是在做持续集成。每次创建分支,都要认识到它带来的风险,而最小化风险的唯一方法,就是无论由于什么样的理由创建了分支,都要努力保证任何活跃分支每天合并回主干   13) 推进变革的每件事情,应该有 AC、用 ATDD。这个戳中我了……   14) Scrum 失败的 3 个主要原因:1 缺乏承诺、缺乏 xie 性和纪律性 2 忽视好的工程实践 3 随便定制敏捷开发过程。这个总结得太好了……   15) 关于文档自动化,让你按照某种方法做事的那张纸,无法保证你真的是这么做的。这个就是说我们的部署说明哪……   ……

http://card.weibo.com/article/h5/s#cid=2304186d85a0a80102v018&vid=2153203421&extparam=

刚到货,才看完标题

这本书读过,是值得学习,有中文版本的。

分支开发->主干开发->短发布分支->真正的单流,这主意真不错哎,转入测试流前,只要以真正的单流为基准即可,既保证了变更控制,同时又能更细腻地控制开发的版本,真 good idea!

需要 登录 后方可回复。