开发者学堂课程【ALPD 云架构师系列：云原生 DevOps 36计-阿里云云效出品：云原生持续交付的4大原则-下】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/772/detail/13509
云原生持续交付的4大原则-下
内容介绍：
一. 原则#3/4：有可持续部署的软件增量
二. 原则#4/4：低成本、高效地部署发布
一. 原则#3/4：有可持续部署的软件增量
1.原则
⑴软件增量对应的明确的需求价值点
⑵软件增量是完整的、可独立发布的单元
⑶软件増量能够被独立验证的单元
这两张图估计很多人都看到过，那么上面的这一种，蒙娜丽莎的微笑每次都是完善一小块，最后拼成完整的，但之前都是不完整的。
而下面的是每一个都是完整的，但是它是不断的丰富细节。
这里就隐喻软件增量应该有一个明确的需求价值点，也就是每次的增量，都必须对应一个需求、一个价值点。它是有明确的需求价值点可以去交付的。
第二点，软件的质量应该是完整的、可独立发布的。一个单元不应该只是一块，这是不完整的。
第三点，软件增量是能够被独立验证的单元。因为要发布的话，就要保证这一个单元也能够独立验证。
那么开发完之后怎么集成在一起，成为一个可以独立发布的单元和一个可以独立验证的单元呢？
“Team programming isn't a divide and conquer problem. It is a divide, conquer, and integrate problem."
——Kent Beck wrote in Extreme Programming Explained
这是 Kent Beck 说过的一句话，并不能拆分，然后再去解决问题，而是拆分解决应该是集成的。他觉得集成是一件非常重要的事情，不能拆开，不然之后就合不拢了。 因为在绝大多数人的开发协作过程当中，其实经常会把问题拆分然后去解决，然后再集成。那无论是需求协作也好，还是软件的集成发布也好，基本上都是这样一个阶段。
那无论是需求协作也好，还是软件的一个集成发布也好，基本上都是这样一个阶段。软件增量是怎么过来的，其实绝大多数时候我们遇到的都是要去做软件的集成，那么软件的集成无非就是三步。
2. 集成的三个步骤
代码提交→打包部署→验证
其实我们绝大多数时候遇到的都是要去做软件的集成，那么软件的集成其实无非就是这三个步骤，代码提交、打包部署、最后验证。其实相来说它是非常简单的。
那为什么持续的或者快速的去做集成，或者说为什么要去做集成。集成的目的，其实就是为了验证一个完整性。比如说代码的合并，可能要用语法的角度来做去集成，代码去构建，然后在逻辑上去集成。比如说，做相应的一些功能性的测试验证，要在功能上要集成。所以整个集成其实是尽早帮助我们发现在集成过程当中带来的一些风险。
就像这张图里的这个桥，合拢的时候发现合拢不了。
所以说，如果我要做到尽早的集成，那尽早的集成就意味着每次集成的点尽可能的要小，也就是集成的批量很小。
3. 减小批量
⑴可部署单元
需求粒度：可发布单元、可测试单元
⑵可集成单元
代码粒度：可构建单元、可单测单元
这里一个从代码的力度，一个从需求力度，去降低集成的力度，让它可以尽早的去做集成。
4. 持续集成验证过程
代码提交→静态分析→编译构建→单元测试→集成测试→功能测试 → 进入待发布
进入待发布之后，就可以做相应一些部署了。这时就需要一个能够可持续部署的软件，然后进入待发布状态。
二. 原则#4/4：低成本、高效地部署发布
1. 持续集成、部署发布的反模式（经常存在的一些问题）
⑴延迟集成
修改东西过多，代码签出时间过长；批量提交。
⑵无测试自动化
手工测试或无测试
⑶耗时的活动
耗时的人工代码审查，手动干预每个阶段的执行，耗时的构建和耗时的测试
⑷累积负债
每次提交无法保证主干稳定性，技术负债增多
⑸返工
由于质量原因，导致些发布活动反复进行，造成时间浪费
很常见的一种就是，当软件完成了某项工作之后进入了一个状态，要进入到下一个状态时，是靠人工的方式来判断，然后人工转移状态，那么这时耗时就很长。
因为反馈等待的时间会很长，导致整个发布的时候很难做到高效。
2. 两个应用的发布统计
如上图两个应用的发布统计。上面是a应用，下面是b应用，每个点表示一次发布，纵轴表示这次发布所耗的时长，横轴表示时间点。绿色的点表示发布成功，红色的点表示发布失败。
那么哪个应用做的比较好呢？
首先，a应用发布的频率非常的低，很多时候一个月也就发那么几次，但是发布的成功率比较高。
第二个呢 就是它的发布频率比较高，但失败率也非常高。
这两个应用各有各的问题，而且发布时间都比较长。而且常常超过了一天，我们知道如果发布超过八小时，就意味着一天中搞不定，就需要加班。
这里举一个例子，有很多企业会把集成时间放在星期二，然后发布时间放在星期四，因为默认发布一定要加班的。而且绝大部分的情况下，其实还是星期五晚上甚至星期六才能够发上去，而且星期日其实也不少。
问题整理：频率低，时间长，易出错，有风险
那么怎么能够让发布频率变得更高、时间更短、不容易出错、没什么风险呢？也就是希望能够持续快速、高质量放、放心的发布上去。那么这里我们就要提到快速集成能力了。
3. 快速集成能力
需要注意两点，第一个是减小批量，第二个是保持顺畅。
⑴减少批量
因为集成的批量和力度，跟资源利用率以及周期时间是有相关性的，所以小批量的周期时间比较短，大批量的周期时间比较长。所以减少批量可以让周期时间变短。
这时频率就会变快，然后反馈也快，应用的修复以及相应的问题响应都会变快。
⑵保持顺畅
举一个简单例子。假设我们在路上开车，大家各行其道，但突然有一条车追尾，这个时候我们第一时间要做的是什么呢？ 肯定不能继续放车过去，而是把它拦下来，并且阻止进入。然后有问题的地方解决好，然后才能让右边的道路顺畅起来。
这里会有很多实践，比如全面自动化、管理异常、减少依赖、质量内建、及时反馈、复用。
①全面自动化
就是测试能够做到自动化，构建速度能够自动化，部署能够自动，整个流程穿起来能够自动化，状态迁移能够自动化。
②管理异常
什么叫异常呢，就是说我们发布过程当中的车辆追尾持续的挂在那里，这时我应该把这个异常情况先修复，再让道顺起来。也就是当我发布的流水线里出现问题，这时就应该先停下，都先不提交，先确定不会触发集成发生，然后把这个问题先解决，再让主干变好，然后继续剩下的工作。
如果是主干产生问题，那接下来所有的工作都会是有问题的，所以要先保证把这个问题修复，然后再去做剩下的集成。
③减少依赖
在基层或发布过程中，会有特别多的依赖，但这时相应的也会产生阻塞，因为依赖会导致相应的一些等待。
④质量内建
上游的质量好了，才能保证下游走的更快。
这里尽可能去要用一种上游思维去思考，就是说如何能够保证早一点让下游变得更好。
⑤及时反馈
有了问题能够及时准确的反馈到具体的人。
这里有一个反模式，就是垃圾式反馈，但凡用了这套系统和提交代码，就会有很多的邮件或者很多信息发给你。
⑥复用
很多过程当中，能复用就复，复用一些过程
这就是保持顺畅的几个参考的点。
