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