DevOps实战笔记
石雪峰
京东商城工程效率专家
立即订阅
3436 人已学习
课程目录
已更新 30 讲 / 共 35 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从默默无闻到风靡全球,DevOps究竟有什么魔力?
免费
基础理论篇 (4讲)
01 | DevOps的“定义”:DevOps究竟要解决什么问题?
02 | DevOps的价值:数字化转型时代,DevOps是必选项?
03 | DevOps的实施:到底是工具先行还是文化先行?
04 | DevOps的衡量:你是否找到了DevOps的实施路线图?
落地实践篇 (16讲)
05 | 价值流分析:关于DevOps转型,我们应该从何处入手?
06 | 转型之路:企业实施DevOps的常见路径和问题
07 | 业务敏捷:帮助DevOps快速落地的源动力
08 | 精益看板(上):精益驱动的敏捷开发方法
09 | 精益看板(下):精益驱动的敏捷开发方法
10 | 配置管理:最容易被忽视的DevOps工程实践基础
11 | 分支策略:让研发高效协作的关键要素
12 | 持续集成:你说的CI和我说的CI是一回事吗?
13 | 自动化测试:DevOps的阿克琉斯之踵
14 | 内建质量:丰田和亚马逊给我们的启示
15 | 技术债务:那些不可忽视的潜在问题
16 | 环境管理:一切皆代码是一种什么样的体验?
17 | 部署管理:低风险的部署发布策略
18 | 混沌工程:软件领域的反脆弱
19 | 正向度量:如何建立完整的DevOps度量体系?
20 | 持续改进:PDCA体系和持续改进的意义
平台工具篇 (4讲)
21 | 开源还是自研:企业DevOps平台建设的三个阶段
22 | 产品设计之道:DevOps产品设计的五个层次
23 | 持续交付平台:现代流水线必备的十大特征(上)
24 | 持续交付平台:现代流水线必备的十大特征(下)
特别放送 (4讲)
特别放送:成为DevOps工程师的必备技能(上)
特别放送:成为DevOps工程师的必备技能(下)
特别放送:学习DevOps不得不了解的经典资料
特别放送:Jenkins产品经理是如何设计产品的?
总结答疑 (1讲)
期中总结:3个典型问题答疑及如何高效学习
DevOps实战笔记
登录|注册

12 | 持续集成:你说的CI和我说的CI是一回事吗?

石雪峰 2019-11-07
你好,我是石雪峰。今天我来跟你聊聊 CI。
之前,我曾应邀参加某公司的 DevOps 交流活动,他们质量团队的负责人分享了 DevOps 平台建设方面的经验,其中有一大半时间都在讲 CI。刚开始还挺好的,可是后来,我越听越觉得奇怪,以至于在交流环节,我只想提一个问题:“你觉得 CI 是个啥意思?”后来,为了不被主办方鄙视,话到嘴边我又努力憋回去了。
回来的路上,我就一直在思考这个问题。很多时候,人们嘴上总是挂着 CI,但是他们说的 CI 和我理解的 CI 好像并不是一回事。比如,有时候 CI 被用来指代负责内部工具平台建设的团队;有时候,CI 类似一种技术实践,间接等同于软件的编译和打包;有时候,CI 又成了一种职能和角色,指代负责版本的集成和发布的人。可见,CI 的定义跟 DevOps 一样,每个人的理解都千差万别。
可问题是,如果不能理解 CI 原本的含义,怎么发挥 CI 真正的价值呢?以 CI 的名义打造的平台又怎么能不跑偏,并且解决真正的问题呢?
所以,今天,就让我们一起重新认识下这个“最熟悉的陌生人”。
CI 是 Continuous Integration 的缩写,也就是我们熟悉的持续集成,顾名思义,这里面有两个关键的问题:集成什么东西?为什么要持续?要回答这两个问题,就得从 CI 诞生的历史说起了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DevOps实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(14)

  • 石子头
    老师,有什么相对权威的DevOps培训可以推荐吗?网上很多,比较难分辨真正好的,能指明个方向也行的,谢谢!

    作者回复: 你好,又是一个让我比较纠结的问题啊,说实话,要看你自己对于培训的心理预期,如果你现在对于DevOps还属于门外汉的阶段,我觉得参加一个培训建立全局认知,多理解一些案例,是有帮助入门的,但是如果说入门之后,只靠培训就比较困难了,因为你面临的实际问题,并不是培训的主题,培训更多的是一些客观的技能提升,比如某个工具,语言,技能等等,还是要跟高手一起共事和思考才行,如果你们公司在做一些这方面的转型工作,你可以多关注一下参与一下,在解决实际问题的过程中积累经验。

    2019-11-08
    2
  • Robert小七
    对于老师问的三个问题,我们公司可以算是做到了!但对于每一次提交触发集成,想请教下是否意味着每次提交都会触发持续集成流水线?如果是这样,也就是说持续集成是包含持续部署的?因为构建只能运行单元测试,但是大量的自动化还是需要先部署服务的!再就是老师所说的每次提交集成触发这个机制,很想请教下老师,您推荐监控主线分支还是特性分支?或者说有专门的集成分支?如果是主线分支,按照特性分支策略,其实已经做过一轮测试了再提交到主干的,所以我很想知道您落地时思考的工作流程!也就是在实际工作中的整个流程!比如从拉分支,提交代码到远端分支,是否会触发持续集成服务,还是说只有集成到主干才会触发?

    作者回复: 你好,感谢你的留言,抱歉回复晚了。首先,要区分开持续集成和持续部署,也就是常说的CICD的关系。CI一般意义上来说是研发实践,核心目的是给研发快速的反馈,所以这个阶段最重要的就是运行时间,所以对于一些比较耗时的操作,比如系统集成测试是不会放在这个环节进行的。至于说是否需要部署服务,还真不能一概而论,因为有些项目单元测试也是依赖于环境的!我也见过有的团队会在持续集成过程中跑核心接口测试,其实我觉得不用太过于教条应该有哪些环节,而是根据实际情况,以快速反馈为优先搭建整个流程。

    第二个问题,是监控主线分支还是特性分支,这首先要看你们当前的分支策略。原则上如果你采用的是我推荐的分支策略,也就是带特性分支的主干开发分支发布,那么会在两个点来做持续集成,一个是提交特性分支时间点,一个是集成主线的时间点,当然如果你们有在用MR或者PR的机制,那么MR/PR也是一个可选的时间点,但是注意要做一次和主干的合并操作。核心就是两个关注点,一个是特性分支是否正常,另外一个就是特性跟主线集成后是否正常,只要把这两个点检查到就OK,你可以按需选择检查点。

    最后无论主干是否有持续集成,都需要一些定期的构建,因为主线上的测试往往依赖于环境,甚至是手工测试的内容,所以并不是只要跑了持续集成就可以的,常见的做法还是按照测试节奏,手工部署环节后验收。

    2019-11-07
    2
  • 雷霹雳的爸爸
    赶巧了我是12讲发出来才看的11讲,刚好一起看的,所以难免想起好像在哪儿有一个论调,翻了下笔记,https://www.continuousdeliveryconsulting.com/blog/organisation-pattern-trunk-based-development/,这哥们提到Jez humble在 https://book.douban.com/subject/26702829/ 将TBD称为CI的synonymous

    而对于老师的思考题,我的问题在于我好像连老师三连问的第一问好像都举不了手…

    作者回复: 你好,很多理念,比如TBD,CI,这些都是一以贯之的哈,关于CI的三个测试问题,你可以参考下这篇文章: [https://martinfowler.com/bliki/ContinuousIntegrationCertification.html](https://martinfowler.com/bliki/ContinuousIntegrationCertification.html)

    2019-11-07
    2
    2
  • 陈斯佳
    老师,问一个问题下,您觉得自动化测试能算是运维技能树当中的一环吗?还是应该归测试组的职责?作为运维,需要了解到什么程度的自动化测试的知识呢?只要会配置就好吗?还是也要去了解如何编写测试案例?我们公司现在都是请大学生来做自动化测试这块,进展很慢,我很想帮忙,但是又不知道要怎么切入,值不值得花时间去学习…

    作者回复: 你好,坦率的说,我不是很建议运维去做自动化测试的事情,因为自动化测试本身受到使用场景的限制,根据不同的业务形态能发挥的价值也不确定,你可以了解一些测试的思路,这对于后续做运维平台或者产品也很有帮助哈,因为测试能够以更加全面的视角来看待问题,而实现者往往只关注一条路径。

    2019-11-11
    1
  • 桃子-夏勇杰
    周六雷涛老师在我们公司做devops培训,果然也问了这3个问题,真的是灵魂拷问啊。

    作者回复: 哈哈,不知道你回答上了几个问题呢😄

    2019-11-10
    1
  • Jxin
    ci是一套理念,随着它的推行会催生出工具平台和文化。工具平台的重心在于提高效率,也就是所有可以被自动化的操作最终都由自动化来解决,使得问题可以close,人力可以得到解放。文化则是倒逼着人们制定并执行ci的流程,同时开始切割集成工作,缩小每次集成的力度提高灵活性,规范每次提交的原子性提高版本管理和问题识别的精准度,以及核心流程单元测试的编写close风险。

    作者回复: 嗯,我觉得很多时候我们都在就事论事,比如ci有问题就谈ci,其实ci也是整个团队能力的体现,需求拆分是否合理,分支策略是否合适,构建速度是否足够快,自动化测试能力有没有,质量门禁的指标和规则是哪些,通知机制是否合理,反馈是否及时,想把ci做好,真不是工具的问题。

    2019-11-07
    1
  • 睡觉💤
    之前的公司,采用了gitlab+gerrit+jenkins组件了一条CI的流水线,做的也比较简单,每个人创建自己的分支进行提交,触发jenkins进行编译与自动化测试(测试没人写,只进行了简单的编译检查)。然后在gerrit上进行review,通过代码才能进master。现在的公司没有这套流水线,感觉特别low

    作者回复: 的确,这些也基本上属于研发标配了,有个小问题,你们为什么要结合Gitlab和Gerrit呢,我们公司也有这样的使用的,原因是公司要求统一使用Gitlab,实际上如果看重Gerrit强大的Review能力的话,为什么不直接使用Gerrit管理代码呢,毕竟多套环境不稳定因素也会增多,同步镜像备份都是麻烦事,不知道你们是怎么考量的呢?

    2019-11-07
    1
  • Bun
    有什么好的自动化测试工具推荐下

    作者回复: 你好,不知道你具体指哪种测试类型呢,比如常见的单元测试、接口测试、UI测试,到典型的非功能性测试,如性能,兼容性,稳定性,安全性,再到端到端测试,压力测试等等,即便一种测试类型也有多重模式,比如面向接口的,面向契约的都不相同哈。
    我推荐你看下专栏特别放送(下),里面有一幅DevOps工具罗盘图,里面罗列的典型的工具哈,如果对某一个具体的工具有问题,也欢迎给我留言,谢谢。

    2019-11-07
    1
    1
  • manatee
    请问老师前端项目在ci中的测试有什么好的联系吗

    作者回复: 你好,这个必须有,我们团队自己就在使用前后端分离的开发模式,对于Vue.js来说单测可以使用Jest和Mocha,覆盖率采用的Istanbul,在以前的演示项目里面也用到过PhantomJS和CasperJS,当然各种Lint工具对于代码风格也很有用,具体看你的使用场景啦。

    2019-11-07
    1
  • linda.zx
    老师,针对于紧急发布执行CI,由于时间紧迫,开发团队会跳过代码检查和自动化测试。理论上应该是不可以的~但是该如何平衡时间呢?

    作者回复: 你好,我特别能理解你的处境,紧急问题出了,火急火燎的,啥流程也不顾了,这种情况下,我客观来说,真是没办法,就好像火烧到家门口了,除了赶紧跑路还想啥呢?
    所以核心问题不是出了这种情况怎么办,而是怎样尽量避免这种情况发生,以及如何优化这些检查的执行效率。说白了,大家觉得可以跳过,潜意识里面还是觉得没用,不重要。
    我觉得至少就事论事来说,可以看看类似这样的问题,是否可以加到自动化测试里面来发现,分析下出现的根音,问题驱动改进。下次再有人说可以跳过哦,就得好好想想,以前出现的坑,是否还愿意再掉进去一次哈。

    2019-12-05
  • 陈文涛
    这句话说的很对-------根据 CI 变更,自动识别匹配对应的测试任务也是一个挑战。
    老师,对于ci这块一个很现实的问题困扰着我,跟您请教。
    对于ci大多数团队都是半路出家,在存在历史包袱的情况下如何践行ci呢,具体点来讲:
    比如,我们在逐步建立代码静态扫描的平台和自动化业务的测试,这个如何能够跟代码的提交,版本的变更相衔接呢,如何能够针对变更进行“增量的CI”呢,有什么好的解决方法和实践么?

    作者回复: 你好,这是一个特别好的问题啊,看来有深入思考过了,先赞一个👍

    首先我想说的是,增量CI也好,精准测试也好,自动回归分析也好,这些高级玩法都是建立于一套成熟的CI机制之上的,所以首先要确保CI的稳定,可靠,执行效率和反馈机制。

    至于版本变更关联测试,其实是配置管理的副产品,也就是通过将需求,代码,版本管理起来,通过代码匹配需求,需求匹配模块和测试用例,从而实现全链路的追踪,所以单单只是依靠CI是解决不了这个问题的。当然,如果只是为了CI提效,主要得看你们一个完成CI过程的时间分布,如果大量时间在编译阶段,那么就可以考虑增量编译的方式来改进。所以还是目标导向哈,如果不知道当前的问题,那就不太好给出解决方案啦。

    2019-11-23
  • Hunter Liu
    《持续交付:发布可靠软件的系统方法》,这节课和这本书里的很多观点不谋而合,不过在我的公司很难做到这点,欠的东西太多,版本发出后各种问题完成版本不可用,项目延期。

    作者回复: 你好,的确持续集成的理念从诞生到现在其实并没有什么太多的变化,文章里面的三个问题,其实也代表了持续集成实施的三个阶段,可以对照看下看看是什么地方出了问题。

    2019-11-17
  • 阿硕
    石老师,您好,关于每次提交触发构建中的方式,应该如何选择呢?能否提供下最佳实践参考,谢谢。

    作者回复: 你好,我想这个问题首先取决于你们当前的业务形态,比如典型的包括APP类型,服务端类型,智能硬件类型和商业软件类型。为什么说跟业务形态有关,这就牵扯到了分支策略和分支模型,提交构建首先要明确监控哪条分支上的提交,在最开始我的建议是如果资源不够充裕或者集成时长普遍超过15分钟的话,可以优先在主干分支上跑起来,再逐步扩展到下游分支。从集成的操作来说,可以先跑一个最小集,如下载代码,构建,然后再逐步拓展到静态检查,自动化测试等,这样循序渐进的来进行。至于工具层面,最典型的就是Jenkins跟版本控制系统打通,你可以在Jenkins中搜索对应系统的插件,大多可以支持,你也可以留言说明你们现在使用的工具,我可以找到一些更详尽的资料给你哈。

    2019-11-07
    1
  • leslie
    老师在文章中的"工具是实践的载体,实践是工具的根基,单纯的工具建设仅仅是千里之行的一小步"其实深有感悟,在此基础上简单的扩充一下"方法/理论是实践的载体,实践是工具的根基,单纯的方法/理论建设仅仅是千里之行的一小步"。
          落地性和实践性确实非常成问题:可能自己中小企业和大型企业的OPS的工作时间对半吧,期间其实碰过不少企业做自动化,可是2009就普遍使用的SVN其实很多时候都简单的在人工操作。其实人很多时候不愿意走出舒适和适合的环境:企业在某些方面同样如此,只有在被逼迫到不做不行的时候才会去做才会去反思XXX之前提出的好像不错是不是可以考虑一下。
          就像这次大会自己为何去听失败案例讲解:其实就感受到很多的不仅仅是存在而且是普遍现象;引发了大量的反思和自己的策划。通过广度去明白/理解深度,从而在实践中修正深度。
          其实当我们确定去做的时候有些工作是可以提前做的:这个月就又学习了关于项目管理的,提前做和理解一些事情,这样可能会在真实操作时更好落地。谢谢老师今天的分享,期待下一次的教诲。

    作者回复: 呵呵,我觉得很多时候,文章就是抛砖引玉,而留言区的互动反而更加精彩,因为能看到不用形态、规模、岗位的同学对于同一个问题的不同思考,以及面对的困难,和自己的观点。
    虽然目标是确定的,但是实践的路径却有很多条,所以不要迷恋一家之言,有独立思考能力才更加重要,感谢leslie的补充和回复。就像一个心理咨询师,他不会替你解决问题,更多的是帮助你解决问题,企业的外部顾问也是如此,很多时候的确需要一个外部的推动力,或者目标性更强的事情来推动团队的变革。

    2019-11-07
收起评论
14
返回
顶部