配合一些工作实践,对持续交付的一点学习和思考。主要参考:《持续交付:发布可靠软件的系统方法》、极客时间的专栏、本人的一点工作实际经验。首先是一些读书笔记,后面是自己的一点感想和评论。
1、 持续交付背景
个人觉得很大情况和敏捷开发一样,背后的原因:1)最深层的当然是互联网的普及提出了需求:互联网应用特别是移动互联网应用带来的高迭代、强调快速交付、对一般性小问题、小错误的一定容忍度;2)基础平台的完善提供了支撑:云互联的基础设施完善,各类开发测试运维技术和平台的完善,如软件开发技术、集成开发平台IDE对版本控制工具、单元测试工具、系统测试工具等的集成,自动测试理论和工具的发展,硬件平台和性能的极速提升。3)集成编译部署工具发展使之得以成为可能:如jenkins、部署工具如docker技术等平台的完善。
当然同时面临着:多应用环境和多平台提出的挑战;快速部署交付对开发和测试提出自动化方面的极为苛刻的要求。
2、持续交付的原则
- 为软件发布创建一个可重复且可靠的过程 个人理解: 必须固化,否则不能自动化,无法实现持续交付
- 将几乎所有事情自动化
- 把所有的东西都纳入版本控制
- 提前并频繁地做让自己感到痛苦的事 个人理解:痛苦的事容易出问题,不断做才能降低风险,其实持续交付也是敏捷过程,很大程度就是风险驱动的
- 内建质量 个人理解:毫无疑问,没有一定覆盖度的自动测试支持,持续交付的版本必然是一团烂泥
- “Done”意味着“已发布” 个人理解:其实“已发布”也不是,当然通过验收测试不是终点,实际部署交付应用成功才是。
- 交付过程是每个成员的责任 大公司有这个要求
- 持续改进 套话。