持续交付36讲
王潇俊
携程系统研发部总监
立即订阅
7125 人已学习
课程目录
已完结 41 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 量身定制你的持续交付体系
免费
基本概念 (3讲)
01 | 持续交付到底有什么价值？
02 | 影响持续交付的因素有哪些？
03 | 持续交付和DevOps是一对好基友
配置管理 (4讲)
04 | 一切的源头，代码分支策略的选择
05 | 手把手教你依赖管理
06 | 代码回滚，你真的理解吗？
07 | “两个披萨”团队的代码管理实际案例
环境管理 (6讲)
08 | 测试环境要多少？从现实需求说起
09 | 测试环境要多少？从成本与效率说起
10 | 让环境自己说话，论环境自描述的重要性
11 | “配置”是把双刃剑，带你了解各种配置方法
12 | 极限挑战，如何做到分钟级搭建环境？
13 | 容器技术真的是环境管理的救星吗？
构建集成 (5讲)
14 | 如何做到构建的提速，再提速！
15 | 构建检测，无规矩不成方圆
16 | 构建资源的弹性伸缩
17 | 容器镜像构建的那些事儿
18 | 如何做好容器镜像的个性化及合规检查？
发布及监控 (6讲)
19 | 发布是持续交付的最后一公里
20 | Immutable！任何变更都需要发布
21 | 发布系统一定要注意用户体验
22 | 发布系统的核心架构和功能设计
23 | 业务及系统架构对发布的影响
24 | 如何利用监控保障发布质量？
测试管理 (3讲)
25 | 代码静态检查实践
26 | 越来越重要的破坏性测试
27 | 利用Mock与回放技术助力自动化回归
持续交付平台化 (3讲)
28 | 持续交付为什么要平台化设计？
29 | 计算资源也是交付的内容
30 | 持续交付中有哪些宝贵数据？
持续交付移动App (3讲)
31 | 了解移动App的持续交付生命周期
32 | 细谈移动APP的交付流水线（pipeline）
33 | 进阶，如何进一步提升移动APP的交付效率？
实践案例 (4讲)
34 | 快速构建持续交付系统（一）：需求分析
35 | 快速构建持续交付系统（二）：GitLab 解决代码管理问题
36 | 快速构建持续交付系统（三）：Jenkins 解决集成打包问题
37 | 快速构建持续交付系统（四）：Ansible 解决自动部署问题
特别放送 (2讲)
持续交付专栏特别放送 | 答疑解惑
持续交付专栏特别放送 | 高效学习指南
结束语 (1讲)
结束语 | 越痛苦的事，越要经常做
持续交付36讲
登录|注册
开篇词 | 量身定制你的持续交付体系
王潇俊 2018-07-02
00:00
10:57
讲述：王潇俊 大小：5.04M
你好，我是王潇俊，从今天开始，我将会和你一起聊聊“持续交付”这个话题。
“持续交付”已不再是一个陌生词汇了，绝大多数软件研发企业，都在或多或少地实施“持续交付”，因为大家都清楚，也都曾经体会或者听别人说过，“持续交付”能够提高研发效率。 但是要说实施得多好、多彻底，那我估计很多人都会面面相觑。
做好持续交付并不是件易事，从我的经验来看，它主要难在三个地方。
第一，实施“持续交付”，将会影响整个的研发生命周期，会涉及到流程、团队、工具等多个方面。很可能需要突破当前组织的束缚，引起大量的技术和组织变革。因为，实施“持续交付”需要组织从上到下的认可，需要有大勇气将一些可能属于黑箱操作的工作，公开出来给大家监督。所以，这样的事情很难推进。
第二，实施“持续交付”，对实施者和参与者的要求都很高，他们不仅需要了解开发，还要了解流程，了解测试，了解运维，甚至还需要有一定的架构知识和管理知识。所以，这样的人才很难寻找。
第三，实施“持续交付”，大多数团队都希望能够快速见效，立竿见影。但是，“持续交付”的改进过程本身就是一个持续迭代的过程，需要多次循环才能体现效果。甚至在实施的初期，因为开发习惯和流程变化，团队在适应的过程中效率会有暂时的下降。所以，这样的效果很难度量。
由于这三大难点，很多人对“持续交付”敬而远之，或者爱恨交加。因此，我希望这个专栏能够带你全面、立体地认识持续交付，当你了解得越多，理解得越透彻，你也就越有信心。简单来说，我认为：
无论企业在什么阶段，无论个人的能力如何，都可以去尝试“持续交付”。
在实践中，我还经常看到一些错误的观点。
过度强调自动化。认为只有自动化才能算是“持续”，但限于业务逻辑变化快，QA 能力不足等，又无法实现测试自动化，而发布自动化更是遥遥无期，所以只能放弃。
过度强调流程化。总觉得“持续交付”先要构建强流程来管控，结果就一直限于流程和实现流程的“泥潭”里，却忘了初衷。
过度强调特殊化。比如我们经常会听到，我们的工程师能力特别强，我们的团队有特殊的工作方式，我们的系统有不同的设计，这些往往成了拒绝“持续交付”的借口。
希望在这个专栏里，通过我的讲解能够纠正你的这些错误观点。
同时，我也希望和你之间不是教与学的关系，而是切磋与讨论，在这三个月的时间里，我们一起讨论如何解决现实的问题，讨论如何进一步去做好“持续交付”，讨论那些超出你我边界的所谓的“难题”。
自从决定写这个专栏，我就一直在脑子里“翻箱倒柜”，在网络上收集相关参考资料，整理写作材料。突然，我脑子里蹦出一个问题：我自己当年是怎么接触到持续交付的，是怎么走上“持续”这条“不归路”的？
仔细回想一下，接触“持续集成”这个概念其实是挺早的事情了。那时我在第九城市负责用户中心的开发，有些与《魔兽世界》相关的功能需要大洋彼岸的老美同学（QA）进行验收。因此，为了利用时差优势，我们如果有新功能要测试，就会要求整个团队在当天下午冻结代码版本，并在 6 点后向测试环境发布。
晚上我们睡觉的时候，老美们就开始干活了。因为《魔兽世界》的爆红，所以当时开发需求特别多，缺陷也特别多，几乎每天都要提测，我就干脆用按键精灵写了个脚本，实现了每天自动地处理这些事情。现在想想，这不就是每日构建嘛。
你现在可能和当时的我一样，正在采用或借鉴一些“持续集成”或“持续交付”的最佳实践，但还停留在一个个小的、零散的点上，并没有形成统一的体系，还搞不定持续交付。
所以，我希望这个专栏首先能够给你呈现一个体系化的“持续交付”课程，帮助你拓展高度和广度，形成对“持续交付”立体的认识。
其实从这个角度来看，我想通过这个专栏与你分享的内容，不正好就是我自己在实际成长过程中一点一点学到的东西吗？那么，如果你不嫌厌烦，可以继续听一下我的故事。
离开第九城市之后，由于经受不住帝都“干燥”的天气，2008 年我又回到魔都，加入了当时还默默无闻的大众点评网。在那里，我真正体验了一把“坐火箭”的感觉；也是在那里，我与“持续交付”真正结缘。
点评是一家工程师文化很浓重的公司，一直以来都以工程师的能力为傲。但随着 O2O 和移动互联网的兴起，点评走到了风口浪尖，团队在不断扩大，而研发效率开始下降了。
起初，大家都觉得是自己的能力跟不上，就开始拼命学习，公司也开始树立专家典型。但结果却事与愿违，个人越牛，杂事越多，不能专注，反而成了瓶颈。总结之后，我们发现，这种情况是研发流程、合作方式等低效造成的。个人再强放在一个低效的环境下，也无力可施。
然后，QA 团队开始推动“持续交付”，试图改变现状。为什么是 QA 团队呢，因为 QA 在软件研发生命周期的最后一端，所有前期的问题，他们都得承担。低效的研发模式和体系，首先压死的就是 QA。但是，QA 团队最终还是以失败收场了。究其原因：
缺乏实践经验，多数“持续交付”相关的图书、分享都停留在“what”和“why”上，没有具体的“how”；
QA 团队本身缺乏开发能力，无法将“持续交付”通过工具进行落地，只能流于表面的流程和理念。
但这场自底向上的革命，却让公司看到了变革的方向。
之后，点评就开始了轰轰烈烈的“精益创业”运动。“持续交付”作为研发线变革的重点，得到了更多资源的支持和高度的关注。也是在这时，我获得了与国内众多的领域专家进行探讨和学习的机会。
最终，点评是以发布系统为切入点，从下游逐步向上游的方式推行“持续交付”。 并且在这个过程中，形成了专职的工程效能团队，从而打造出了一套持续交付平台。
所以，我希望这个专栏的第二个重点是，结合我个人多年的实践经验，与你分享“持续交付”涉及的工具、系统、平台，到底如何去设计，如何去实施，如何去落地。
离开点评之后，我加入了携程。携程的规模、体量相比点评，又大了许多。比如，携程有近 20 个 BU，应用数量达到 6000+，研发人员有 3000 人；同时还有去哪儿、艺龙等兄弟公司，在系统上也息息相关；而且携程随着多年的业务发展，系统复杂度也远远高于点评。要在这么大的平台上推行“持续交付”，挑战是巨大的。
其实，携程在“持续交付”方面一直以来都是有所尝试和努力的，引进、自研各种方式都有，但是收效甚微。其中构建的一些工具和平台，由于种种问题，反而给研发人员留下了坏印象。这里面自然有各方面的问题，但我认为最主要的问题是以下三点：
“持续交付”必须以平台化的思想去看待，单点突破是无力的；
“持续交付”的实施，也要顺应技术的变迁，善于利用技术红利；
“持续交付”与系统架构、运维体系息息相关，已经不分彼此。
事实上，在携程推进“持续交付”时，我们联合了框架、OPS 等部门，将目标放在支持更未来的容器化、云原生（Cloud Native），以及微服务上，利用这些新兴技术的理念，和开源社区的红利，从“持续发布”开始，逐步推进“持续交付”。
在推进的过程中，我们既兼容了老旧的系统架构，也为迁移到新一代架构做好了准备，并提供了支持。可以说，携程第四代架构的升级本身，就是在坚持“持续交付”，从而获得了成功。
所以，在 DevOps 越来越火的今天，我希望这个专栏可以达到的第三个目的是，能够让你看到“持续交付”与新兴技术擦出的火花，并与你探讨“持续交付”的未来。
除了以上内容，你还将通过我的专栏收获以下四个方面。
“持续交付”的主要组件：配置管理、环境管理、构建集成和测试管理。
在这一部分里，我会深入浅出地，跟你聊聊“持续交付”的这“四大金刚”，帮你全方位地理解“持续交付”的各项主要活动。
如何实现“灰度发布”。
如果你对“持续部署”有所期待，希望进一步了解，那么你大多数的问题都可以在这一部分得到解答。
移动 App 中有所不同的“持续交付”体系。
移动互联网如火如荼，你一定也想了解下，如何在手机客户端研发中做好“持续交付”。那么这一部分，你就不能错过了。
如何利用开源红利，快速搭建一套持续交付平台。
在这一部分，我会手把手地，带你真正去搭建一套最小集合的持续交付平台。
学须致用，思须有为。我的这趟“持续交付”班车即将发车，如果你感兴趣，那就赶紧一起来，让我们一同欣赏沿途的风景吧！
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《持续交付36讲》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(18)
卫宣安继软件测试52讲后又一个我急需的课程，真的来得太及时，感觉就是看到我在软件测试课程留言而准备的（卖萌脸）。2018-07-03 11
小豪我们真的是一支很小规模的互联网产品研发团队，在实施持续交付这件事上一直犹豫不决，“无论企业在什么阶段，无论个人的能力如何，都可以去尝试“持续交付””这句话给我们打了一针强心剂，试试总是没错的，最差就是失败嘛。作者回复: 尝试一下成功率是50%，不尝试那就是0%
2018-07-03 10
shniu老师，您在点评时，为何会选择以发布环境作为CD的切入点呢？是怎么思考这些问题的呢？作者回复: 1. 抓住出口，掌握主导权。2. 先解决最痛的问题。3. 发布需要联合框架，运维，人多力量大
2018-07-03 3- 舍得我能公司也是在也很急这个持续集成，第一次花钱订阅专栏，希望有用2018-09-17 2
木木夕Ace学习学习2018-07-03 2- 羽卒精益创业中的精益是什么意思？
作者回复: 书的英文名称叫lean startup，你说这个lean怎么理解，那就是整本书要说的了：）其中有很多实践，比如MVP，BML过程等等，整本书应该说提供了一个很棒的管理创业过程的方法
2018-09-19 1 
小金库so持续交付不仅仅是靠个人能力，团队的合作尤其重要。主要有三方面：一、共识。团队要有共识，统一目标，你做持续交付很大程度上暴露出各团队的隐形缺陷。怎么取舍尤其重要。二、支持。这方面真的需要一个话语权足够的人来全力支持，没有一个最终拍板的人存在，大部分时间都会浪费在无用的口舌之争。三、言出必行。执行过程中不能出现任何影响建立持续交付的特殊破例。千里之堤溃于蚁穴，一旦有过这种特例，大家都会想着向这方面靠拢。作者回复: 把研发人员当客户，客户满意是最终目标
2018-07-07 1- 图·美克尔我们团队的持续集成刚刚搭建起来，还在适应中。使用的是Jenkins pipeline+Supervisor，感觉还不是很好用，很多地方需要改进。希望从这个专题中能收获一套稳健的持续集成方案。2018-07-03 1
qingliangwu你好，请问下如何衡量持续交付平台的效果呢？作者回复: 下一讲中就有答案：）
2018-07-03 1
老巫在那里，我真正体验了一把“坐火箭”的感觉；我与“持续交付”真正结缘。
我也有过这样的体验，不过是在携程。感谢PAAS，感谢OPS：）
--一个爱携程却膨胀匆忙离开的读者2018-11-15
Young赞2018-09-13
云中漫步最近公司说不需要项目经理，这颠覆了我们的想象。提出一个交付经理概念，本文希望能解答我们的疑问。^_^2018-07-17
硕我现在就是负责发布平台，准备搞一搞这个，学习了。2018-07-17
胡剑持续集成以前做开发接触过自动编译和自动化测试，对开发效率的提升没怎么感觉到，但是自动测试对质量的保底还是有体会的。但是因为一直没有体会过全过程的持续交付，所以对其优劣没有概念，所以这是我报课的初衷，希望在持续集成上学习到提升团队效率和质量的方法!最后感谢老师的分享!2018-07-17
九脉一谷正在梳理流程体系，建立了一些标准规范，打通了现有工具链，正准备搭建一套devops平台，在实践中前行还是遇到很多问题。希望听了你的系列讲座能有所收获。2018-07-04
王浩槟最近在寻求进阶的途径，希望能大有所获2018-07-04
sprinty老师您好，经常听到和看到持续部署、持续发布、持续交付的概念。这些概念有什么不同的含义吗？区别是什么？作者回复: 咱们5号的第一讲中就会讨论这个问题的
2018-07-04- shniu期待中...2018-07-03
收起评论