12 | 持续集成：你说的CI和我说的CI是一回事吗？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
持续集成（CI）是软件开发中的重要实践，旨在通过频繁地将团队成员的工作成果集成到一起，并自动触发运行包含自动化验证集的构建任务，以尽早发现集成问题。CI的核心理念是“越是痛苦的事情，就要越频繁地做”，通过提高集成频率和减少每次集成的内容，以降低软件开发末端集成所带来的风险和不确定性。 本文详细介绍了持续集成的三个阶段：快速集成、质量内建和问题修复。在快速集成阶段，关键是统一的分支策略、清晰的集成规则、标准化的资源池和快速的反馈周期；在质量内建阶段，关键是匹配合适的测试活动、树立测试结果的公信度和提升测试活动的有效性；在问题修复阶段，需要建立团队内的持续集成文化，制定清晰的规则，保证集成主线的可用性，并且主动关注、分析和推动问题解决。 通过阐述每个阶段的关键要点和挑战，读者能够深入了解持续集成的重要性，并在实践中更好地应用持续集成的理念和方法。文章强调了实践的重要性，而非单纯依赖工具，提醒读者要理解CI的核心理念，并将工具作为实践的载体。 总的来说，本文为读者提供了全面的实践指导和思考，帮助他们更好地理解和应用持续集成的理念和方法。
《DevOps 实战笔记》，新⼈⾸单¥59
全部留言(23)
- 最新
- 精选
Robert小七对于老师问的三个问题，我们公司可以算是做到了！但对于每一次提交触发集成，想请教下是否意味着每次提交都会触发持续集成流水线？如果是这样，也就是说持续集成是包含持续部署的？因为构建只能运行单元测试，但是大量的自动化还是需要先部署服务的！再就是老师所说的每次提交集成触发这个机制，很想请教下老师，您推荐监控主线分支还是特性分支？或者说有专门的集成分支？如果是主线分支，按照特性分支策略，其实已经做过一轮测试了再提交到主干的，所以我很想知道您落地时思考的工作流程！也就是在实际工作中的整个流程！比如从拉分支，提交代码到远端分支，是否会触发持续集成服务，还是说只有集成到主干才会触发？作者回复: 你好，感谢你的留言，抱歉回复晚了。首先，要区分开持续集成和持续部署，也就是常说的CICD的关系。CI一般意义上来说是研发实践，核心目的是给研发快速的反馈，所以这个阶段最重要的就是运行时间，所以对于一些比较耗时的操作，比如系统集成测试是不会放在这个环节进行的。至于说是否需要部署服务，还真不能一概而论，因为有些项目单元测试也是依赖于环境的！我也见过有的团队会在持续集成过程中跑核心接口测试，其实我觉得不用太过于教条应该有哪些环节，而是根据实际情况，以快速反馈为优先搭建整个流程。 第二个问题，是监控主线分支还是特性分支，这首先要看你们当前的分支策略。原则上如果你采用的是我推荐的分支策略，也就是带特性分支的主干开发分支发布，那么会在两个点来做持续集成，一个是提交特性分支时间点，一个是集成主线的时间点，当然如果你们有在用MR或者PR的机制，那么MR/PR也是一个可选的时间点，但是注意要做一次和主干的合并操作。核心就是两个关注点，一个是特性分支是否正常，另外一个就是特性跟主线集成后是否正常，只要把这两个点检查到就OK，你可以按需选择检查点。 最后无论主干是否有持续集成，都需要一些定期的构建，因为主线上的测试往往依赖于环境，甚至是手工测试的内容，所以并不是只要跑了持续集成就可以的，常见的做法还是按照测试节奏，手工部署环节后验收。
2019-11-0739
石子头老师，有什么相对权威的DevOps培训可以推荐吗？网上很多，比较难分辨真正好的，能指明个方向也行的，谢谢！作者回复: 你好，又是一个让我比较纠结的问题啊，说实话，要看你自己对于培训的心理预期，如果你现在对于DevOps还属于门外汉的阶段，我觉得参加一个培训建立全局认知，多理解一些案例，是有帮助入门的，但是如果说入门之后，只靠培训就比较困难了，因为你面临的实际问题，并不是培训的主题，培训更多的是一些客观的技能提升，比如某个工具，语言，技能等等，还是要跟高手一起共事和思考才行，如果你们公司在做一些这方面的转型工作，你可以多关注一下参与一下，在解决实际问题的过程中积累经验。
2019-11-086
pines之前的公司，采用了gitlab+gerrit+jenkins组件了一条CI的流水线，做的也比较简单，每个人创建自己的分支进行提交，触发jenkins进行编译与自动化测试(测试没人写，只进行了简单的编译检查)。然后在gerrit上进行review，通过代码才能进master。现在的公司没有这套流水线，感觉特别low作者回复: 的确，这些也基本上属于研发标配了，有个小问题，你们为什么要结合Gitlab和Gerrit呢，我们公司也有这样的使用的，原因是公司要求统一使用Gitlab，实际上如果看重Gerrit强大的Review能力的话，为什么不直接使用Gerrit管理代码呢，毕竟多套环境不稳定因素也会增多，同步镜像备份都是麻烦事，不知道你们是怎么考量的呢？
2019-11-075
雷霹雳的爸爸赶巧了我是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-0733
陈文涛这句话说的很对-------根据 CI 变更，自动识别匹配对应的测试任务也是一个挑战。 老师，对于ci这块一个很现实的问题困扰着我，跟您请教。 对于ci大多数团队都是半路出家，在存在历史包袱的情况下如何践行ci呢，具体点来讲： 比如，我们在逐步建立代码静态扫描的平台和自动化业务的测试，这个如何能够跟代码的提交，版本的变更相衔接呢，如何能够针对变更进行“增量的CI”呢，有什么好的解决方法和实践么？作者回复: 你好，这是一个特别好的问题啊，看来有深入思考过了，先赞一个👍 首先我想说的是，增量CI也好，精准测试也好，自动回归分析也好，这些高级玩法都是建立于一套成熟的CI机制之上的，所以首先要确保CI的稳定，可靠，执行效率和反馈机制。 至于版本变更关联测试，其实是配置管理的副产品，也就是通过将需求，代码，版本管理起来，通过代码匹配需求，需求匹配模块和测试用例，从而实现全链路的追踪，所以单单只是依靠CI是解决不了这个问题的。当然，如果只是为了CI提效，主要得看你们一个完成CI过程的时间分布，如果大量时间在编译阶段，那么就可以考虑增量编译的方式来改进。所以还是目标导向哈，如果不知道当前的问题，那就不太好给出解决方案啦。
2019-11-232
陈斯佳老师，问一个问题下，您觉得自动化测试能算是运维技能树当中的一环吗？还是应该归测试组的职责？作为运维，需要了解到什么程度的自动化测试的知识呢？只要会配置就好吗？还是也要去了解如何编写测试案例？我们公司现在都是请大学生来做自动化测试这块，进展很慢，我很想帮忙，但是又不知道要怎么切入，值不值得花时间去学习…作者回复: 你好，坦率的说，我不是很建议运维去做自动化测试的事情，因为自动化测试本身受到使用场景的限制，根据不同的业务形态能发挥的价值也不确定，你可以了解一些测试的思路，这对于后续做运维平台或者产品也很有帮助哈，因为测试能够以更加全面的视角来看待问题，而实现者往往只关注一条路径。
2019-11-112
Jxin
ci是一套理念，随着它的推行会催生出工具平台和文化。工具平台的重心在于提高效率，也就是所有可以被自动化的操作最终都由自动化来解决，使得问题可以close，人力可以得到解放。文化则是倒逼着人们制定并执行ci的流程，同时开始切割集成工作，缩小每次集成的力度提高灵活性，规范每次提交的原子性提高版本管理和问题识别的精准度，以及核心流程单元测试的编写close风险。作者回复: 嗯，我觉得很多时候我们都在就事论事，比如ci有问题就谈ci，其实ci也是整个团队能力的体现，需求拆分是否合理，分支策略是否合适，构建速度是否足够快，自动化测试能力有没有，质量门禁的指标和规则是哪些，通知机制是否合理，反馈是否及时，想把ci做好，真不是工具的问题。
2019-11-072- Bun有什么好的自动化测试工具推荐下
作者回复: 你好，不知道你具体指哪种测试类型呢，比如常见的单元测试、接口测试、UI测试，到典型的非功能性测试，如性能，兼容性，稳定性，安全性，再到端到端测试，压力测试等等，即便一种测试类型也有多重模式，比如面向接口的，面向契约的都不相同哈。 我推荐你看下专栏特别放送（下），里面有一幅DevOps工具罗盘图，里面罗列的典型的工具哈，如果对某一个具体的工具有问题，也欢迎给我留言，谢谢。
2019-11-0722 
manatee请问老师前端项目在ci中的测试有什么好的联系吗作者回复: 你好，这个必须有，我们团队自己就在使用前后端分离的开发模式，对于Vue.js来说单测可以使用Jest和Mocha，覆盖率采用的Istanbul，在以前的演示项目里面也用到过PhantomJS和CasperJS，当然各种Lint工具对于代码风格也很有用，具体看你的使用场景啦。
2019-11-072
桃子-夏勇杰集成的问题在于需要集成，要是整个团队各自的模块互不影响，是不是集成就没有那么痛苦了？作者回复: 所以才有微服务嘛，就是为了尽量少的干扰和依赖，但是实际上还是有很多技术和业务上的耦合不是这么好解开的，所以集成也是少不了的。
2020-07-171
