开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：云原生持续交付的4大原则-下（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1279
云原生持续交付的4大原则-下（二）
2、低成本、高效地部署发布
怎么样可以低成本高效的，先说怎么样不行，也就是它的反模式是什么？
对于哪些常见的一些问题，其实很多人可能都见到过这样一些问题，最常见的就是说延迟集成，这个很常见，就是可能一个月集上一次或一个月批量提交一把。
第二种就是累积负债，就是这个主干，上面一直不稳定，有很多的问题，永远测不通过，那这个就是累计负债。第三个就是无测试自动化，就是整个的测试完全靠手工来保证，或者说有测试自动化，但是它不稳定，没法依赖。
这个时候就完全靠人去判断，说这个测试是否可以。第四个是返工，就是经常因为一些质量的问题或者缺陷或者什么导致这个发布活动经常要反复，其实记得之前学校问过大家发布成功率怎么样，很多人发布重率很高。但是事实情况下其实都知道的发布是这一次，其实有好多次返工，用那个 bug 来一把再来一把。
所以这个中间就是一个很多很多的返工，然后这个中间带来了大量的一个时间浪费。还有一个就是一个耗时的活动，很多时候需要人工去查代码，去做每一阶段的审批，去看每一阶段的质量情况，这些都是会耗费大量的时间，从而导致整个发布比较低效的。而且耗时的活动里其实是很常见的一种，当软件完成了某一项工作之后，进入了一个状态，要进入到下一个状态的时候，是靠人工的方式来去判断，再转移状态迁移的，那么这个时候耗时就很长了。
因为你反馈等待的时间会过长，所以它导致在整个发布的时候，整个项目的状态难做的很高效，所以常见就是有的时候开玩笑说，反馈基本上靠吼，测试基本上靠手，或者说其他的一些做很久。一种不对，就很难做到回归和保证整个发布的一致性里面很难做到这一点。
如上图两个应用的发布统计，上面是 a 应用，下面是 b 应用，每一个点表示一次发布。纵轴是它这次发布所耗的时间，可以看到用 LOGO 二的那个坐标，上面的很大，像最上面有三天了，面十几个小时大概几分钟这样子。在y轴上它表示的是在哪一天发布的，纵轴表示时长，横轴表示时间点，每一个点表示一次发布，绿色的点表示发布成功，红色的点表示失败，这是真实的两个应用。
将两个应用对比一下，两个应用都不太好。看第一个应用的情况是什么呢？它发布的频率非常的低，它一个月就发那么几次，一两次。但是它成功率还好，就是发布的成功率还比较高。第二个就是它的发布频率是比较高的，可能几天就有一次发布，但是它的失败率实在是非常的高，它失败的次数远远大于它成功的次数。所以其实两个各有它的问题，这两个应用，整个发布时间都比较长。经常是要超过一个白天，需要24小时往上的，其实可以知道，如果发布超过了8小时，意味着在一天中搞不定了，就需要加班，发布这个是比较高危的一个事情，很多公司的发布的时候需要盯盘的，不可能说还没发完，就先回去睡觉了，这个是一般做不到的。那这种情况下看如果它发布需要耗时超过一天，假设一个组两个人轮流，也需要12个小时。
举一个例子，有很多企业，把他们的集成时间放在周二，然后发布时间放在周四，因为默认发布一定要加班的，而且周四发布不上去周五还要发。
如果放在周五的发布，那周六肯定要加班了。其实很多情况下，虽然发在周四，但可以发现绝大部分的情况下，发到周五晚上，甚至到周六才能够发上去，其实发到周日的其实也不少。所以从这两张图看看，发现像 a 应用一样，它频率很低，好久才会发一次，然后另外一个，两个都是体现出这一点，就是时间很长，成功的就一定要很久。然后像b应用易出错。
还有一个就是确实有相应的一些风险。因为这个时间很长，又很容易出错的话，很难做到按需发布，保证那个发布上先点能够做好。可以观察一下b应用，会发现如果它挨着时间点，连续有多次红点再加一个绿点的话，往往意味着连续发布出问题，要紧急的去修复，然后再去重新发布。所以这个时候就意味着这个软件其实是很有可能在紧急修复和出故障中间出现风险的，那怎么能够让这个发布频率变得更高，时间更短，然后更不容易出错，没什么风险。这是愿景，希望就是任何时候发上去都是好的，都是绿的，也就是能够持续快速，高质量，放心大胆的能够发布上去，那么这个时候就要提到的就是一个集成和发布的一个能力了，那么这里虽然这里叫快速集成能力，其实发布也是部署类似的。
这里其实是要注意到2点，第一个就是减小批量，第二个就是保持顺畅。
集成的一个批量的，一个集成的粒度跟资源利用率和周期时间是有相关性的，可以看到小批量它的周期时间是比较短的。大批量它的周期时间一般来说会比较长，从资源利用率看，其实它们都相对比较接近，不会有太大的一些问题。通过减少批量可以让周期时间尽可能的变短，时间短了，基本上频率就会做的多了。频率做的多，时间又快，然后反馈又快，那对于这一个应用的修复或者相应的一些问题响应，就会变得更快，这是第一点，要做到减少批量。
那么第二个就是保持顺畅，举一个简单例子，正在录像，然后开车，大家各行其道，但突然之间有一条车道追尾了，那这个时候第一要做的是什么？还继续放车过去？肯定不是。首先要做的就是阻止进入，然后让有问题的，先把这个问题解决掉之后，然后才能把右边的顺畅起来，这里头有两个比较重要的点，怎么来去做。
第一个减少剂量，刚才已经提到过了，是说从需求的粒度和代码的粒度看，要明确可发布单元和可测试单元尽可能的少。然后可构建和单侧单元代码尽可能的小。但保持顺畅的角度，基本上有很多的实践。比如第一点全面自动化，测试能够做到自动化，构建的速度能够自动化，部署能够自动化，整个流程串起来能够自动化状态迁移，能够做到自动化。
第二点管理异常，什么叫异常？就是发布过程当中的车辆的追尾，持续的挂在那里，这个时候应该把这个异常情况先修复掉，再让这个道顺起来。发布的流水线出现问题时，这个时候就应该先停下来，先不要提交，先不要确定，不要触发集成发生。然后先把这个问题先解决，就是先让主干变好，因为如果主干都是有问题的主干，那接下来所有的工作都是有问题的。所以要先保证把这个主干修复掉，然后剩下的集成再去做。
在以前有一些企业里的工作的时候，会做到这一点，一旦遇到出现问题的时候，谁提交代码的，谁就负责去解决掉问题，如果半小时或者说给一个限定的时间内没有完成处理。那么系统会自动的把它的代码摘掉，让后面的人能够继续的做相应的一些集成，这里是管理相一些异常。
第三个减少依赖，如果本身集成或者发布过程当中，对外部有特别多的依赖，这个时候也会相应的阻塞，因为依赖会导致要去做相应等待。第四质量内建，上游的质量好了，才能保证下游的更快，比如上游不去做相应一些问题，那下游肯定阻塞。
举个例子，有一篇文章叫《扁鹊见蔡桓公》，扁鹊说自己的医术在他三兄弟当中是最差的，他二哥医术比他好，但是他大哥最好，为什么？扁鹊治的是快要死的人，他二哥是人刚生病，就能把病人治好。大哥是未病已治病，人家都不知道他生过病，就已经治好了。这里一个思维方式就是凡事应该尽早的去做，去上游找问题，保证早一点让下游变得更好一点。这里是一个质量内建的一个，第五及时反馈也是一样的。有了问题之后能够及时准确的反馈到具体的人类一个地方。有时候有一个反模式，垃圾式反馈，但凡用了这套系统和提交代码，会有很多的邮件或者很多的钉钉信息发送到。这个时候一般来说用户的做法是它忽略，过滤到垃圾箱。一旦规则给这个反馈建立了一个规则，那基本上就不会再去看了，那么最后一个就是复用。很多过程尽量去复用它，有一些过程就比如做完了之后就不用去重复再找，所以以上是保持顺畅的几个参考点。
从四个角度要持续部署，第一个准确、可预期的部署结果，第二个部署过程不影响线上服务，第三个有可持续部署的软件增量，第四个低成本、高效地部署发布，整个发布做到按需部署发布最理想的情况是什么时候想发就可以发。
