开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：云原生时代的软件持续交付实践（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1265
云原生时代的软件持续交付实践（二）
内容介绍：
一、持续交付的特点
二、如何做到持续交付
三、基于云和云原生技术的持续交付实践
四、持续交付流水线
五、可信发布
六、持续交付的红利
七、小结
五、可信发布：
可信发布就是说一个代码、配置或者说是依赖上的变化，都会引发最后制品的改变。制品的改变会经过一系列的过程，刚刚说的流水线经过一系列的节点，节点中间有很多需要去验证和关注的点和管控点：比如说我们会有代码审查；有测试验证；有评审；有发布的管控等。那这中间会有很多的规则，会关注很多的那个检测项目，比如说代码质量、合规、验收、安全等。
这些规则加上这些检测项目，最终会给我们一个反馈来展现本次发布是不是可行。如果是有问题的，那就不应该发布。作为可信发布来讲，首先是要就是能够降低整个的发布的一个风险，就是说防止整个缺陷带来的业务损失。同时更重要的是，降低发布的一个心智负担。不会说不敢发布。
对阿里来说做到很好的发挥的是双11不封，我想发就发，谁都可以发。什么时候认为我们整个就做好了？即在最高峰期的时候，我敢随便发我的应用。另外一个就是希望能够通过这个获得质量的反馈，让这个质量是看得见的。这样的就有了一个发布信息，同时能够快速获得反馈。当我这个反馈足够快速的时候，整个开发效率都会比较高。因为可以及时的去反馈、及时的去修复。
六、持续交付的红利
1.消除对个人的依赖：整个研发过程中，信息共享，集成发布自动化完成;降底集成发布过程中的技术门槛，任何人都有能力完成集成发布。
2.降低团队之间的损耗。通过规范一致的流程，确保规则的一致性，版本的一致性;像流水线、仪表盘等保证信息透明。
1. 降低测试成本，提升质量。采用分层测试策略，以低投入的方式最大化收益;降低测试门槛，人人都能方便快速参与测试;缺陷能够快速定位并修复。
2. 降低发布风险。规范一致的版本管理，并通过自动化、最优发布策略，针对不同的生产环境和发布工具进行发布。
其实刚才提到的就是三点，今天主要介绍的就是说为什么要做到三点、应该是一个什么程度去做。大家也可以去对照一下自己团队里是否做到1.0、怎么去做。我们也认为在这些地方做好这些交付，可以给我们带来很多的红利。比如说所有东西建立自己的持续交付，或者说这种模式的话，是可以消除一些对个人的依赖。
所有的信息都是共享，就是我们常常说的可见、可控、可度量、可加速。我们希望所有东西都是可见的；另外一个就是团队之间的协作的损耗，是我们流程一致、所有东西的版本也是一致的。我曾经拜访过一家公司，他们的发布是直接从个人电脑发上去的，即不知道今天在生产环境跑的是谁的电脑里发出自己的版本。
尤其是当出现故障的时候，我也不知道当时版本是什么；另外一个就是降低测试成本，很多时候我们认为，测试要做事情的话，需要投入人力来去做一些设施自动化的维护，成本好像挺高，即前面去雇一些比较廉价的劳动力来做手工测试。
但是你会发现只有自动化的测试是可以回归的，是可以不断的来去运行的，可以不断重复。而手动测试的重复程度是特别高的，因为机器是廉价的，比如说把测试和质量保证的方式集成在整个学习集成发布的流水线上，就很容易降低成本。而且另外一个我们也说到了，对于做工程的来说，最多发明和创造最多创新，可以做一些相应的工具、或者说方式、方法，然后快速做问题的定位排查。尤其现在恢复架构下，一出现问题，如果有很清晰的、方便的定位排查手段，可以提升整个成本的。
比如说版本是可以回溯，可以追溯，而且版本一致性比较好，那么对于发布的风险来说，会有很好的一些控制。而且也可以根据跑出来的可信的规则运行，做相应的一些判断。包括发布一个相对策略。
七、小结
1.2个挑战1个机遇。
1. 达成共识：持续产品交付是响应业务的关键。
3.持续交付能力是持续产品交付的基础。
4.持续交付是持续地交付，即持续、快速、高质量、低风险地发布。
5.持续交付必须从三个方面落地:不可变基础设施、持续发布流水线及安全可信发布。
