持续交付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
收起评论
18
99+
返回
顶部