|
|
# 开篇词 | 量身定制你的持续交付体系
|
|
|
|
|
|
你好，我是王潇俊，从今天开始，我将会和你一起聊聊“持续交付”这个话题。
|
|
|
|
|
|
“持续交付”已不再是一个陌生词汇了，绝大多数软件研发企业，都在或多或少地实施“持续交付”，因为大家都清楚，也都曾经体会或者听别人说过，**“持续交付”能够提高研发效率。** 但是要说实施得多好、多彻底，那我估计很多人都会面面相觑。
|
|
|
|
|
|
做好持续交付并不是件易事，从我的经验来看，它主要难在三个地方。
|
|
|
|
|
|
第一，实施“持续交付”，将会影响整个的研发生命周期，会涉及到流程、团队、工具等多个方面。很可能需要突破当前组织的束缚，引起大量的技术和组织变革。因为，实施“持续交付”需要组织从上到下的认可，需要有大勇气将一些可能属于黑箱操作的工作，公开出来给大家监督。所以，**这样的事情很难推进。**
|
|
|
|
|
|
第二，实施“持续交付”，对实施者和参与者的要求都很高，他们不仅需要了解开发，还要了解流程，了解测试，了解运维，甚至还需要有一定的架构知识和管理知识。所以，**这样的人才很难寻找。**
|
|
|
|
|
|
第三，实施“持续交付”，大多数团队都希望能够快速见效，立竿见影。但是，“持续交付”的改进过程本身就是一个持续迭代的过程，需要多次循环才能体现效果。甚至在实施的初期，因为开发习惯和流程变化，团队在适应的过程中效率会有暂时的下降。所以，**这样的效果很难度量。**
|
|
|
|
|
|
由于这三大难点，很多人对“持续交付”敬而远之，或者爱恨交加。因此，我希望这个专栏能够带你全面、立体地认识持续交付，当你了解得越多，理解得越透彻，你也就越有信心。简单来说，我认为：
|
|
|
|
|
|
**无论企业在什么阶段，无论个人的能力如何，都可以去尝试“持续交付”。**
|
|
|
|
|
|
在实践中，我还经常看到一些错误的观点。
|
|
|
|
|
|
1. **过度强调自动化**。认为只有自动化才能算是“持续”，但限于业务逻辑变化快，QA能力不足等，又无法实现测试自动化，而发布自动化更是遥遥无期，所以只能放弃。
|
|
|
|
|
|
2. **过度强调流程化**。总觉得“持续交付”先要构建强流程来管控，结果就一直限于流程和实现流程的“泥潭”里，却忘了初衷。
|
|
|
|
|
|
3. **过度强调特殊化**。比如我们经常会听到，我们的工程师能力特别强，我们的团队有特殊的工作方式，我们的系统有不同的设计，这些往往成了拒绝“持续交付”的借口。
|
|
|
|
|
|
|
|
|
希望在这个专栏里，通过我的讲解能够纠正你的这些错误观点。
|
|
|
|
|
|
同时，我也希望和你之间不是教与学的关系，而是切磋与讨论，在这三个月的时间里，我们一起讨论如何解决现实的问题，讨论如何进一步去做好“持续交付”，讨论那些超出你我边界的所谓的“难题”。
|
|
|
|
|
|
自从决定写这个专栏，我就一直在脑子里“翻箱倒柜”，在网络上收集相关参考资料，整理写作材料。突然，我脑子里蹦出一个问题：我自己当年是怎么接触到持续交付的，是怎么走上“持续”这条“不归路”的？
|
|
|
|
|
|
仔细回想一下，接触“持续集成”这个概念其实是挺早的事情了。那时我在第九城市负责用户中心的开发，有些与《魔兽世界》相关的功能需要大洋彼岸的老美同学（QA）进行验收。因此，为了利用时差优势，我们如果有新功能要测试，就会要求整个团队在当天下午冻结代码版本，并在6点后向测试环境发布。
|
|
|
|
|
|
晚上我们睡觉的时候，老美们就开始干活了。因为《魔兽世界》的爆红，所以当时开发需求特别多，缺陷也特别多，几乎每天都要提测，我就干脆用按键精灵写了个脚本，实现了每天自动地处理这些事情。现在想想，这不就是每日构建嘛。
|
|
|
|
|
|
你现在可能和当时的我一样，正在采用或借鉴一些“持续集成”或“持续交付”的最佳实践，但还停留在一个个小的、零散的点上，并没有形成统一的体系，还搞不定持续交付。
|
|
|
|
|
|
**所以，我希望这个专栏首先能够给你呈现一个体系化的“持续交付”课程，帮助你拓展高度和广度，形成对“持续交付”立体的认识。**
|
|
|
|
|
|
其实从这个角度来看，我想通过这个专栏与你分享的内容，不正好就是我自己在实际成长过程中一点一点学到的东西吗？那么，如果你不嫌厌烦，可以继续听一下我的故事。
|
|
|
|
|
|
离开第九城市之后，由于经受不住帝都“干燥”的天气，2008年我又回到魔都，加入了当时还默默无闻的大众点评网。在那里，我真正体验了一把“坐火箭”的感觉；也是在那里，我与“持续交付”真正结缘。
|
|
|
|
|
|
点评是一家工程师文化很浓重的公司，一直以来都以工程师的能力为傲。但随着O2O和移动互联网的兴起，点评走到了风口浪尖，团队在不断扩大，而研发效率开始下降了。
|
|
|
|
|
|
起初，大家都觉得是自己的能力跟不上，就开始拼命学习，公司也开始树立专家典型。但结果却事与愿违，个人越牛，杂事越多，不能专注，反而成了瓶颈。总结之后，我们发现，这种情况是研发流程、合作方式等低效造成的。**个人再强放在一个低效的环境下，也无力可施。**
|
|
|
|
|
|
然后，QA团队开始推动“持续交付”，试图改变现状。为什么是QA团队呢，因为QA在软件研发生命周期的最后一端，所有前期的问题，他们都得承担。低效的研发模式和体系，首先压死的就是QA。但是，QA团队最终还是以失败收场了。究其原因：
|
|
|
|
|
|
1. **缺乏实践经验，多数“持续交付”相关的图书、分享都停留在“what”和“why”上，没有具体的“how”；**
|
|
|
|
|
|
2. **QA团队本身缺乏开发能力，无法将“持续交付”通过工具进行落地，只能流于表面的流程和理念。**
|
|
|
|
|
|
|
|
|
但这场自底向上的革命，却让公司看到了变革的方向。
|
|
|
|
|
|
之后，点评就开始了轰轰烈烈的“精益创业”运动。“持续交付”作为研发线变革的重点，得到了更多资源的支持和高度的关注。也是在这时，我获得了与国内众多的领域专家进行探讨和学习的机会。
|
|
|
|
|
|
最终，**点评是以发布系统为切入点，从下游逐步向上游的方式推行“持续交付”。** 并且在这个过程中，形成了专职的工程效能团队，从而打造出了一套持续交付平台。
|
|
|
|
|
|
**所以，我希望这个专栏的第二个重点是，结合我个人多年的实践经验，与你分享“持续交付”涉及的工具、系统、平台，到底如何去设计，如何去实施，如何去落地。**
|
|
|
|
|
|
离开点评之后，我加入了携程。携程的规模、体量相比点评，又大了许多。比如，携程有近20个BU，应用数量达到6000+，研发人员有3000人；同时还有去哪儿、艺龙等兄弟公司，在系统上也息息相关；而且携程随着多年的业务发展，系统复杂度也远远高于点评。要在这么大的平台上推行“持续交付”，挑战是巨大的。
|
|
|
|
|
|
其实，携程在“持续交付”方面一直以来都是有所尝试和努力的，引进、自研各种方式都有，但是收效甚微。其中构建的一些工具和平台，由于种种问题，反而给研发人员留下了坏印象。这里面自然有各方面的问题，但我认为最主要的问题是以下三点：
|
|
|
|
|
|
1. **“持续交付”必须以平台化的思想去看待，单点突破是无力的；**
|
|
|
|
|
|
2. **“持续交付”的实施，也要顺应技术的变迁，善于利用技术红利；**
|
|
|
|
|
|
3. **“持续交付”与系统架构、运维体系息息相关，已经不分彼此。**
|
|
|
|
|
|
|
|
|
事实上，在携程推进“持续交付”时，我们联合了框架、OPS等部门，将目标放在支持更未来的容器化、云原生（Cloud Native），以及微服务上，利用这些新兴技术的理念，和开源社区的红利，从“持续发布”开始，逐步推进“持续交付”。
|
|
|
|
|
|
在推进的过程中，我们既兼容了老旧的系统架构，也为迁移到新一代架构做好了准备，并提供了支持。可以说，携程第四代架构的升级本身，就是在坚持“持续交付”，从而获得了成功。
|
|
|
|
|
|
**所以，在DevOps越来越火的今天，我希望这个专栏可以达到的第三个目的是，能够让你看到“持续交付”与新兴技术擦出的火花，并与你探讨“持续交付”的未来。**
|
|
|
|
|
|
除了以上内容，你还将通过我的专栏收获以下四个方面。
|
|
|
|
|
|
1. **“持续交付”的主要组件：配置管理、环境管理、构建集成和测试管理。**
|
|
|
在这一部分里，我会深入浅出地，跟你聊聊“持续交付”的这“四大金刚”，帮你全方位地理解“持续交付”的各项主要活动。
|
|
|
|
|
|
2. **如何实现“灰度发布”。**
|
|
|
如果你对“持续部署”有所期待，希望进一步了解，那么你大多数的问题都可以在这一部分得到解答。
|
|
|
|
|
|
3. **移动App中有所不同的“持续交付”体系。**
|
|
|
移动互联网如火如荼，你一定也想了解下，如何在手机客户端研发中做好“持续交付”。那么这一部分，你就不能错过了。
|
|
|
|
|
|
4. **如何利用开源红利，快速搭建一套持续交付平台。**
|
|
|
在这一部分，我会手把手地，带你真正去搭建一套最小集合的持续交付平台。
|
|
|
|
|
|
|
|
|
学须致用，思须有为。我的这趟“持续交付”班车即将发车，如果你感兴趣，那就赶紧一起来，让我们一同欣赏沿途的风景吧！
|
|
|
|