12 | 持续交付知易行难，想做成这事你要理解这几个关键点

Jan 24, 2018

12 | 持续交付知易行难，想做成这事你要理解这几个关键点-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

12 | 持续交付知易行难，想做成这事你要理解这几个关键点

2018-01-24 赵成来自北京

《赵成的运维体系管理课》

课程介绍



讲述：黄洲君

时长07:08大小3.26M



前面几篇文章，我们介绍了非常基础的运维建设环节。如果我们想要这些运维基础建设发挥出更大的作用和价值，就需要针对运维场景进行场景化设计和自动化，让效率和稳定性真正提升上来。也就是说，把基础的事情做好之后，我们就要进入效率提升的运维场景自动化阶段了。
在这一阶段，我个人的经验和建议是，首先要把持续交付做好。
为什么要先做持续交付？如果说我们完成了一些运维职责范围内的自动化工具，提升的是运维效率的话，那么，做持续交付就是提升整个研发体系效率的关键。
做持续交付的价值表现在哪里？
持续交付覆盖了应用的整个生命周期，涉及产品、开发、测试、运维以及项目管理等相关方面。从生命周期出发，自然就会牵出整个自动化的全貌，就会有从全局着眼的规划设计，这时无论是在开发还是运维过程中存在的问题，都会完完整整地暴露出来。那么，应该以什么样的主线开展？各方应该如何配合？应该以怎样的优先级明确任务？这些问题就都清楚了。同时，也避免了各个环节只把注意力放在各自职责范围内的事情上，而忽略了整体的配合。所以，做好持续交付，对于整个研发体系意义重大。
我们面临的实际场景是怎样的？
我们知道，随着业务复杂度的升高，不管是分层架构，还是微服务架构，都会带来一个最明显的变化，那就是应用数量增多，有时甚至多达几十个、上百个。不同的应用就有不同的代码、依赖和配置，为了协同多应用之间的在线发布，我们还要做到服务能够平滑地进行上下线切换。同时，为了最大限度地降低发布风险，我们还需要进行多环境下的验证，以及上线后的灰度策略等等。
应对这一切，如果只是手工维护，或者利用简单的工具脚本进行维护，都不能保证正常运作。这个时候，我们必须有一系列的流程、机制和工具链来支持和保障。
由杰斯·赫布尔（Jez Humble）、戴维·法利（ David Farley）编著，乔梁老师翻译的《持续交付：发布可靠软件的系统方法》（Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation）这本书，针对持续交付的过程、方法和指导建议几个方面做了非常详细的描述。我向你强烈推荐这本书，不过，这本书的内容并不仅仅针对于微服务架构。
接下来我就分享如何把持续交付的理念和实践相结合，讲一讲在实践过程中，做好持续交付最关键的几步是什么，以及具体应该怎么做。
什么是持续交付？我们现在经常会接触到这些名词，比如持续交付、持续集成、持续部署、持续发布、DevOps 和敏捷开发等等。大多有关持续交付的分享或文章中，这些名词经常会同时出现。它们之间到底有什么区别？我自己之前也弄不清楚，直到看到乔梁老师的这张图。
这里我重点解释一下持续交付这个概念，通俗地说，持续交付代表着从业务需求开始到交付上线之后的端到端的过程。后面我们会针对这个过程的关键环节进行分享。
受篇幅所限，其它名词就先不作过多解释了，你可以看图自己体会，都不难理解。后面针对某些概念我们还会提到。
持续交付的关键点可以说，这一部分也是我们后面将要分享内容的提纲。
从前面那张图来看，做持续交付需要端到端考虑，同时还要有一些非常关键的准备工作。我把这些工作大致分为以下几个部分。
1. 配置管理
这一部分会利用到我们前面讲过的标准化和 CMDB 打下的基础，同时还会有更大的外延，比如环境配置、代码配置以及依赖管理等等。
配置管理是非常关键的基础工作。有一点值得注意，那就是标准化是一个持续的过程。我们不太可能在一开始就把所有运维对象、属性和关系全部都考虑清楚，面面俱到是不太现实的，所以，一定要具备标准化的意识，在开展运维工作的过程中，持续不断地用这个思路去标准化新出现的对象。先标准，再固化，然后自动化。
2. 需求拆解
需求拆解这个工作跟业务需求部门和业务开发有更直接的关系。在这里，运维需要做的是，明确需求拆解的粒度和我们最终发布上线的粒度相匹配。
3. 提交管理
需求拆解完成后，就进入到开发阶段，开发完成后向代码库中提交代码，这个过程中代码分支的合并策略选择就是提交管理。
4. 构建打包
这一部分是指将提交后的代码编译成可发布的软件包。
5. 自动化测试
自动化测试包括功能测试和非功能性测试。对于运维来说，会更注重非功能方面的特性，所以后面我会着重讲非功能性相关的测试环节。
6. 部署发布
这一部分是指发布到不同的环境，如开发环境、预发环境、线上 Beta 以及线上全量环境。针对不同的环境，发布策略和注意事项也会不同。
以上是一个完整的持续交付过程中最重要的几个环节，后面我们分篇进行详细介绍。
从我自己的实践经验来看，配置管理、提交管理、构建和部署发布是持续交付的重中之重，是关键路径，是从开发代码开始，到发布上线的必经之路。当时，因为这几个环节出现了问题，不能解决，运维同学经常做手工发布，这样效率就跟不上，还经常出现各种问题。
后来，我们就是先从这几个环节入手，把阻塞的问题解决掉，然后在这个主流程上不断增加外围能力，让整个流程的功能更加丰富和全面。整个系统也从原来的只具备持续部署发布功能的平台，逐步演进为具有持续交付能力的平台。由此可见，我们实现持续交付的过程，也不是一蹴而就的，而是在摸索中逐步演进完善的。
最后，给你留两个思考题。
先放下持续交付的概念，你所理解或经历的从开发完代码到发布到线上这个过程中，会有哪些环节？和我列出来的这几部分是否有相同之处？
持续交付是谁的持续交付，它的主体是谁？或者有哪些主体？
欢迎你留言与我讨论。
如果今天的内容对你有用，也欢迎你分享给身边的朋友，我们下期见！

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 3

提建议

11 | 从谷歌CRE谈起，运维如何培养服务意识？

13 | 持续交付的第一关键点：配置管理

 写留言

精选留言(7)

付盼星
2018-03-06
持续交付的是产品不是代码，上家公司阐述QA指责的时候说的，通过测试的还是代码，通过QA的才是产品，用户要的是产品，不是代码。
作者回复: 你说的没错！
22
王岩
2018-05-03
在这里，运维需要做的是，明确需求拆解的粒度和我们最终发布上线的粒度相匹配。这块不太理解，能举个例子么？
9
岑崟
2018-01-25
持续交付的概念很清晰，阶段的交付物也很具体，到毕竟这个概念是跨多个团队，如果他们的意识没有起来，在落地的过程中及其痛苦，而且要有觉悟：同一件事会被翻腾个3、4遍（一二十个应用还好，如果应用有一二百个的时候，再加上上层对这件事情资源的投入，就会痛不欲生，所以此时上层管理层的支持至关重要）
作者回复: 需要引导，我也有类似的经历
5
送普选
2020-12-03
乔老师的图清晰易懂，豁然开朗啊！关于持续部署和持续交付的区别，这块赵老师能说下么？谢谢
作者回复: 部署（deployment）：将软件安装到一个特定的环境发布（release）：让一个或一组特性对应用可见和可用。没做完的新功能，我们同时会部署上去，只不过，用户是看不到这些功能的，应该feature是off的，偶尔也会向部分用户打开。确定功能完全OK了，就会把相应的feature，完全打开，所有用户就可以看这个新功能了。以上摘自何勉老师的，《精益产品开发》，有很清晰的定义。
共 2 条评论
5
ning
2019-03-16
1 从开发完代码到发布到线上这个过程中，会有哪些环节？和我列出来的这几部分是否有相同之处？环节有编译打包，分发，服务起停，此外还需要一个服务起停失败的回滚阶段
1
Benjamin.wang
2021-11-07
持续交付是谁的持续交付，它的主体是谁？或者有哪些主体？ //赵老师，通过学习，我的理解持续交付是整个研发运维体系的持续交付，主体有业务/产品、开发、测试、运维整个一条流水线上的所有人员。交付，也就是在业务部门提出需求（或者用户提出需求）后，开发实现、测试经过各种测试、运维发布上线，将产品、功能交付出去。而持续交付，强调的是“持续”“高效率”“流水线”，让流水线上的各个环节尽可能不要等待，以最优的计划去尽快地完成交付。周而复始地完成一个又一个产品交付，从而实现对业务的快速响应。相对应于传统的开发、测试、运维各自独立工作，“持续交付”让大家作为一个虚拟团队，共同聚焦于产品的快速交付，为此排定工作优先级。
展开
kevinsu
2021-04-08
预发布环境(自动化部署)->测试,通过or不通过->测试环境(自动化部署)->测试,通过or不通过->生产环境(批量发布,需人工干涉去自动化一键部署)

