持续交付的一点学习和思考

        配合一些工作实践，对持续交付的一点学习和思考。主要参考：《持续交付：发布可靠软件的系统方法》、极客时间的专栏、本人的一点工作实际经验。首先是一些读书笔记，后面是自己的一点感想和评论。

      1、 持续交付背景

             个人觉得很大情况和敏捷开发一样，背后的原因：1）最深层的当然是互联网的普及提出了需求：互联网应用特别是移动互联网应用带来的高迭代、强调快速交付、对一般性小问题、小错误的一定容忍度；2）基础平台的完善提供了支撑：云互联的基础设施完善，各类开发测试运维技术和平台的完善，如软件开发技术、集成开发平台IDE对版本控制工具、单元测试工具、系统测试工具等的集成，自动测试理论和工具的发展，硬件平台和性能的极速提升。3）集成编译部署工具发展使之得以成为可能：如jenkins、部署工具如docker技术等平台的完善。

当然同时面临着：多应用环境和多平台提出的挑战；快速部署交付对开发和测试提出自动化方面的极为苛刻的要求。

  2、持续交付的原则

•  为软件发布创建一个可重复且可靠的过程      个人理解： 必须固化，否则不能自动化，无法实现持续交付
• 将几乎所有事情自动化
• 把所有的东西都纳入版本控制
• 提前并频繁地做让自己感到痛苦的事      个人理解：痛苦的事容易出问题，不断做才能降低风险，其实持续交付也是敏捷过程，很大程度就是风险驱动的         
• 内建质量        个人理解：毫无疑问，没有一定覆盖度的自动测试支持，持续交付的版本必然是一团烂泥
• “Done”意味着“已发布”         个人理解：其实“已发布”也不是，当然通过验收测试不是终点，实际部署交付应用成功才是。
• 交付过程是每个成员的责任    大公司有这个要求
• 持续改进   套话。