开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：云原生持续交付的4大原则-下（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1279
云原生持续交付的4大原则-下（一）
1、有可持续部署的软件增量
做到不中断，也可以保证准确性了，但是有没有东西持续的去部署，如果说没有东西去部署，那就没有任何意义。去做持续部署，为了什么？那肯定有程序的东西。
所以这里，这两组图估计很多人都看到过，那么上面这一组也就是蒙娜丽莎的微笑，它是每次都是玩一小块儿的，一小块一小块，最后做成了第五块，但它从1234每一个都是不完整的，而下面的这一组1234。它每一个都是完整的，但是它在不断的丰富她的细节，所以在这里一个隐喻就是软件增量应该对应的一个明确的需求价值点，其实这样的也就是每一次的一个增量，它必须是一个对应的一个需求一个价值，它是一个有明确的需求价值也可以去交付的，第二点就是软件增量应该是完整的，是可以独立发布的一个单元。第三个就是软件的质量它是能够被独立的验证。因为要发布，要保证放心的发布，那么这一个单元也需要被验证。所以这里提到的三点。其实更多的是关注在拆分完之后怎么集成在一起？成为一个可以独立发布的一个单元和一个独立可以验证的一个单元。
Kent Beck 说过一句话 Team programming isn't adivide and conquer problem. It is a divide, conquer, and integrate problem. "就是并不是拆分，再去解决问题，而是拆分解决应该是集成的，所以他觉得集成是一件非常重要的事情，不能拆开导致完了之后合不拢，因为在绝大多数件开发协作过程当中，其实就是把问题拆分，然后去解决再集成的一个过程，那么无论是需求写作也好，还是软件的一个集成发布也好，基本上都是这样一个阶段。那么看一下这个软件增量是怎么过来的，其实绝大多数时候遇到的都是要去做软件的集成，那么软件的集成其实无非就是三个步骤。代码提交，打包部署，最后验证。
为什么持续的做或者快速的去做相应一些集成？集成的目的其实是为了验证，验证他它的一个完整性。验证比如代码合并，那可能要求语法的角度去集成，那么代码能够去构建，那要在逻辑上去集成，再比如要去做相应的一些功能性的一些测试验证，那要在功能上要集成，所以整个集成它其实是尽早发现在培训过程当中带来的一些风险。
比如像这张图里那桥造的差不多了，合拢的时候发现合不了了，视角不一样，稍微错开来拍了一下，就是会感觉到好像真的很不好，不能过桥的。要做到尽早的集成，但尽早的集成意味着每次集成的点应该尽可能的要小。那有很多很小的点，就可以尽早去集成，也就是集成的批量应该是很小。
那么批量很小，其实有两个单元，一个是从部署的角度来说叫可部署单元，另外一个从集成的角度来说叫一个可集成的单元。那部署的单元必须做到可发布的可测试，是站在需求的粒度，就是增量是一个需求，是一个特性，特性对于用户来说是可以看得到的可以用到的一个功能。另外一个就是可集成的单元，它更多的是可构建的一个单元，从逻辑上能够构建在一起。然后它可以做相应的一些单元测试，然后再去做代码级别的一个验证，那这里就是从代码粒度来看。从这一个角度来说去接降低集成的一个粒度，它可以尽早的去做集成。
刚才说到的，集成其实就提交打包部署验证，但是在持续集成验证过程其实相对来说会更细一点。有时候从代码提交，提交完了要去做相应的一些代码的分析，然后再去编译构建，其实编译构建它也是在做相应的一些代码的质量的检查的一个过程，至少是能够编译成功的，其实这个在很多时候就是给的第一手的反馈。然后在单元侧测试，集成测试，功能性测试，最后一次达到了可以进入待发布的一个状态。所以前半部分蓝色的是在做持续一阵过程，而进入待发布之后，这个时候就可以去做相应一些部署了，这里是站在第三的角度来说，需要做到有可持续部署的一个软件增量，然后进入待发布状态，需要有一个待发布的一个软件的特性。
