持续交付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讲
登录|注册

01 | 持续交付到底有什么价值?

王潇俊 2018-07-05
随着云计算、容器等新兴技术的发展,“持续交付”这个老生常谈的问题,忽如一夜春风来,仿佛找到了从理想通向现实的大门。各类相关工具、产品、服务,也是纷纷出现:如 Jenkins 2.0,Jenkins X,阿里云效,Netflix Spinnaker,Jfrog Artifactory 等等。
到底是什么魔力使得各大公司和厂商对“持续交付”如此趋之若鹜?那么,作为本专栏的第一篇文章,我就先来为你揭示“持续交付”真正的价值。

你了解持续交付吗?

持续交付,到底是什么意思,它的定义是什么?《持续交付:发布可靠软件的系统方法》一书中把“持续交付”定义为:
持续交付是软件研发人员,如何将一个好点子,以最快的速度交付给用户的方法。
是不是听起来有点抽象呢?其实这就好像你去问 100 个哲学家,“哲学”的定义是什么,你会获得 101 个答案一样。与马丁 · 福勒(Martin Fowler)老爷子在 2006 年,提出“持续集成”概念时一样,我们可以把 “持续交付”定义为“一套软件工程方法论和许许多多的最佳实践的集合”。
但即使熟知了定义和方法论,其实也还是如海市蜃楼一般,无法落地,因为大家所贡献的最佳实践才是持续交付理论的核心。只有真正在工作中贯彻和使用这些实践工具,才能体会持续交付的真正含义和作用。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《持续交付36讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(22)

  • 刘为红 置顶
    持续交付是从用户获取反馈后再通过持续集成不断改进的过程,持续部署又是持续交付的最后一公里,是不是可以理解为为持续交付=持续集成+持续部署,我们做持续交付就是要进行持续集成+持续部署,这三者的关系有点晕,希望老师解答一下

    作者回复: 应该这样理解,持续交付包含其他两者,但不是等于两者相加。就像我文中提到的,交付对象未必一定是最终用户,定期提测、修复、再提测,充分利用了测试资源,也是持续交付。千万不要认为一定要做到端到端完整才叫持续交付。持续的产出并持续的验证。这也是为什么我会说任何企业,任何人都可以去尝试持续交付的原因

    2018-07-05
    6
  • 妮小小
    看完文章,觉得公司的主要问题集中在持续集成和持续部署上。看完回复和评论内容,就觉得,三者互相渗透,没有绝对的对立。团队后台开发人员,总是以后台逻辑是个整体,需要统一编码结束后,方可测试,但是受交付进度的影响,测试人员往往压力很大。中间有试过,后台单个功能模块编码结束,测试人员测试没问题后,整体交付前,之前测试的模块又有新的问题,这样测试人员的积极性又没了,觉得还是都编码结束整体测试才比较好。小公司的效率问题,一直没办法提升,任重道远,作为管理新人,希望看完能有真正的理解与运用,为实际工作减少压力。
    2018-07-06
    2
    5
  • 极杰子
    我想提前了解一个问题、携程是否做到开发提交代码即触发流水线流程、并且其中自动化测试是针对提交的这块代码做测试、如果做到了具体如何做,没做到原因是什么?

    作者回复: 携程的话,push2CI2CD都是做到的,静态扫描是针对新增代码的,但是自动化测试不是。另外自动化测试怎么只对提交的代码,我不知道怎么做到,可能也没人能知道:)比如我改了一个枚举,我真的不知道该怎么只测试这个commit的内容就算OK了,因为自动话测试本来就是讲求覆盖率,ut也是一样的

    2018-07-06
    3
  • 卫宣安
    期待实际实施课程,目前正在犹豫是专门招一个有经验的CI/CD工程师还是在团队内培养,毕竟初期无法投入太多人力进行工具的搭建,目前也只能从意识上向团队推广,要以一种快速开发 快速提测 快速反馈 快速修复的理念开展工作,但没有工具的支撑又很担心人员出现负面情绪,反而降低了效率。
    2018-07-05
    3
  • 破晓
    我在一家初创企业做小组leader,系统从单体到微服务,小组成员从两人到十人,规模不断扩大,系统越来越复杂。持续交付的技术工具了解很多,我们也在尝试一些实践。希望在这里得到老师的最佳实践经验,使我们少走弯路,提升整个团队的效率和满意度。
    2018-07-05
    3
  • 九脉一谷
    效率和质量是当前我们希望通过持续集成,持续交付来解决两个最棘手的问题。新开发的产品部署到用户现场已经上百套了,一直都没有一个稳定的版本。这也是困惑我许久的难题。
    2018-07-05
    2
  • greatliu
    无论是横向的业务研发团队,还是纵向的技术框架团队。

    我的理解是业务是纵向的,技术是横向的,你这句话是不是有问题

    作者回复: 嗯,确实是,感谢指出

    2018-12-16
    1
  • 师不愈
    问:你的团队最希望借助持续交付解决什么现实问题?答:我们团队的交付物是SDK,需要支持多种平台(win,Linux ,iOS,android),引入持续交付,现在能理解的,就是提升生产效率,让研发人员专注业务,提高产品质量。目前SDK产品经过2年的开发已成熟,但从开发到提测到测试到上线,全都是非常传统的复制粘贴方式,仅仅依靠人为编写的文字流程与文档规范去控制整个过程,可想这中间有多大的效率提升空间。以交测举例,原来需要开发在源码的若个build目录下拷贝文档,sdk,demo,按照规范组成产品包,手动提交到某个交测目录下,发邮件通知测试同事,整个过程需要1h,且容易出错。在简单使用Jenkins之后,源码的提交就会自动触发上述所有过程,只需1分钟,直接为研发用户带来效益。

    作者回复: 看起来棒棒的

    2018-10-26
    1
  • 王浩槟
    嗯,终于等到第一篇。
    我在一家初创公司做中层技术管理,面临项目交付业务压力大、项目交付速度要求高的困境,希望利用持续交付能有所建树

    作者回复: 坚持并持续改进,持续交付和重构其实一样,越痛苦的事,就越要多做,加油💪

    2018-07-05
    1
  • 桃子-夏勇杰
    很好奇老师遇到过哪些“不可持续点”,希望有个参考列表。

    作者回复: 首先可以自动化但没有自动化的点
    其次是需要人工判断的,是否可通过约定来解决
    再有,不在控制能力之内的事情,可否异步处理
    最后注意记录,回溯,幂等处理

    2019-11-03
  • leo gao
    现在持续交付主要是想通过自动化来确保每次开发修改代码后没有影响到其他功能 。
    2019-06-02
  • 红娟
    持续集成,持续交付,持续部署三者之间是什么关系呢?

    作者回复: 文章里应该写清楚了吧……

    2018-12-21
  • 红娟
    关键词:持续交付,持续集成,持续部署
    2018-12-21
  • zlh
    看留言中有人提到如何实现自动化测试只针对提交的代码做测试,我在以前的公司的时候,有考虑到往这个方面考虑。大概思路有两种:第一种是通过前期的运行测试后,会自动形成一个代码和测试用例的一个对应关系(这个是个难点,在我离开时尚未形成可行的方案),当下次代码提交后,会自动寻找修改代码对应的测试用例,只运行该部分测试用例。 第二种是在写测试用例的时候,手动分模块,当对应模块的代码修改后,就只运行对应模块的测试用例(手动选择)。 第二种方式是我们一直在操作的,但是这个比较粗糙,只能保证修改的模块的测试用例通过,当跨模块影响时,是无法辨别的。而第一种方式,系统会自动判断哪些测试用例会受影响,从而自动运行对应的测试用例即可。
    2018-11-19
  • LXJ
    从单个需求的角度来看,如果有一个大的需求,涉及到不同的部件或者说模块,怎么能够保证各个部件的进度是统一的,不影响其他需求的构建?

    作者回复: 这是一个解耦问题,一定要保证独立组件能够独立构建,甚至部署。微服务流行也是这个道理

    2018-10-28
  • 羽卒
    代码上线和业务上线的解耦分离,能举个栗子吗,呵呵😄

    作者回复: 比如利用功能开关,功能代码上线,但开关不开,功能暂不生效

    2018-09-21
  • 亲亲小胖鱼
    可以认为 持续交付=DevOps?
    2018-07-18
  • JinSong
    能简单介绍下你们的持续交付演进路线吗,首先做了自动部署,后面紧接着做了哪些?

    作者回复: 部署之后,就可以利用优势解决环境问题;而环境管理会对编译打包有一定要求,比如配置等;如果是小团队的话,也可以在初期就订立分支规范;如果分支规范已经比较分散,则最后处理

    2018-07-05
  • Rachel_fang
    自动化测试的效率和脚本的正确性应该也是其中重要一环~如果自动化测试效率很低,同时失败的脚本需要人工check也达不到持续交付的标准~

    作者回复: 说的太对了,但是持续交付也不一定要完全自动化,自动化是加速和优化的手段

    2018-07-05
  • 禾子先生
    之前对这几个概念还挺模糊,现在会比较清晰,感谢作者。现在的理解就是:持续交付=持续集成+持续部署

    作者回复: 应该说是包含关系,而不是相加

    2018-07-05
收起评论
22
返回
顶部