【方法论】 持续集成应用实践指南原创

大家好，我是陈军统，来自腾讯coding团队的解决方案架构师。今天我给大家分享的内容是持续集成的应用实践指南以及基于coding产品的实践与操作演示。今天的课程会分为以下几个部分，在简单介绍基础知识之后，我们会讲解持续集成的应用实践。在今天的原生时代下，持续集成也被赋予了新使命，作为everyday next code这个理念的承载实现，我们也会对这部分进行讲解以及使用coding产品做实践落地。最后一部分是整体介绍coding持续集成解决方案。我们先来了解一下什么是持续集成，持续集成指的是频繁的一天多次将代码集成到主干。注意，这里既包含持续将代码集成到主干的含义，也包含持续将源码。

生成可供实际使用的制品的过程。持续集成的目的就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是代码集成到主干之前必须通过自动化测试，只要有一个用力测试失败，就不能集成。世界级软件开发大师敏捷宣言只需为作者之一的马丁曾经说过，持续集成并不能消除吧，但是它确实可以让爸变得更容易被发现和被修复。那为什么需要持续集成呢？过去一个团队的开发人员可能会孤立的工作很长一段时间，他们每次的改动都只会保存到本地，只有在他们的工作完成后，才会将之前积累的所有变更一次性合并到主干分支，这使得合并代码更改变得困难而耗时，而且还会导致错误积累很长时间而得不到纠正，导致修复成本变高。这些因素将导致我们更加难以迅速向客户交付更新。在实施了持续集成以后，开发人员会进行频繁的代码集成，每次提交的改动都比较小，由于每次提成都是由小改动组成，合并的复杂度也会大大降低，集成过程中可能出现的话也能较早的被检测到，也更加便于追踪。

这就在整个项目的生命周期中节约了时间和金钱。经常提交代码还能推动开发者编写模块化的、复杂度低的代码。此外，通过设置质量门禁，我们还能持续提高代码质量。持续集成现在已经成为现代软件开发周期中不可或缺的一部分。它的使用场景包括快速构建应用、进行代码规范检查、进行自动化测试、执行定时任务、进行自动部署同步代码仓库等等。

持续集成能为我们带来以下好处，第一是尽早发现缺陷，降低集成风险。多数情况下，一个项目会有多个人单独处理任务或者一部分代码，人员越多，整合的风险越大和调试解决问题本身会是非常痛苦的，我们很可能需要大量修改代码。频繁的集成可以极大减少此类问题，降低缺陷修复成本。第二，保障代码质量。自动化流水线将开发人员从手工操作中解放出来，这样可以把精力更多的放在业务代码和功能上，从而获得更高质量的软件。第三，有效的版本控制。通过及时的信息反馈，如果有人提交的代码有问题，团队会及时收到通知，在有任何的拉取之前解决问题。第四，减少团队之间摩擦。明确而公正的制度和流程可以减少团队之间的争吵。第五。

改善测试团队质量。通过不同版本和构建隔离并追踪错误，可以有效减轻测试团队负担。第六，部署更快自动化可以让原本繁琐耗时的部署工作变得轻松高效。第七，增强团队信心和士气。团队成员不必再为潜在错误可能会造成的不良后果而忧心忡忡，可以轻装上阵去创造更好的软件。第八，团队新成员可以更容易的融入整个项目之中，简单便捷的集成步骤让新的团队成员能够更快的上手，适应项目环境，进入工作状态。了解完持续集成的基础知识以及好处后，假设我们现在要对已有的老旧项目进行改造，使其接入持续集成，那么需要做什么工作呢？接下来就让我们介绍这方面的规划思考以及应用实践。在正式接入CI前，我们需要规划好一种新的工作流，以适应项目切换为高频集成后可能带来的问题与难点。这里涉及到的改造层面非常多，除了敦促开发人员习惯的转变以及进行更新流程的培训外，我们主要关心的是源码仓库的更新，触发持续集成步骤的方式。

第一步要面临的就是版本发布模式的取舍。在持续交付2.01书中提到，版本发布模式有三个要素，交付时间、特性、数量以及交付质量。这三者是相互制衡的，在开发人力与资源相对固定的情况下，我们只能对其中的两个要素进行保证。传统的项目制发布模式是牺牲了交付时间，等待所有的课进全部开发完成并经历完整人工测试后才发布一次新版本，但这样会使得交付周期变长，并且由于特性数量较多，在开发过程中的不可控风险变高，可能会导致版本无法按时交付，不符合一个成熟的大型项目对于持续交付的要求。对于持续集成的思想来说，当我们的集成频率足够高，自动化测试足够成熟且稳定时，完全可以不用一股脑的将特性全堆在一次发布中。每开发完一个。

的特性就自动进行测试，完成后合入等待发布，接下来只需要在特定的时间周期节点也自动将已经稳定的等待中台特性发布出去即可，这对于发布频率越来越高、发布周期越来越短的现代发型项目中无疑是一个最优解。第二步要考虑的就是分支策略，我们在以上限制本账号的coding公开课代码管理的发展工作流与新使命中有详细尝试四种常用的get工作流模型，感兴趣的同学可以翻阅本账号的课程回放。现在业界常用的是左图所示的get flow模式，可以看出该模式在特性开发、大修复、版本发布甚至是hot fix方面都已经考虑到位了，是一个能应用在生产环境中的工作流，但整体的架构也因此变得极为复杂，不便管理。例如进行一次office的操作流程是从最新。

先发布前使用的主干分支拉出hot fix分支修复后合入到develop分支中，等待下一次版本发布时拉出到release分支中，发布完成后才能合为主干。此外，对于flow的每一个特性分支来说，并没有一个严格的合入时间，因此对较大需求来说，可能合路时间间隔会很长，这样在合入主干时可能会有大量的冲突需要解决，导致项目工期不断延长。对此做大型改造与重构的同学应该深有体会。针对这一点，我们还有另外一种策略可以选择及右图所示的主干开发主干发布的分支策略，他要求开发团队的成员尽量每天将自己分支的代码提交到主干，在到达发布条件时，从主干直接拉出发布分支用于发布，若发现缺陷，直接在主干上修复，并根据需要CHP到对应版本的发布分支。

这样一来，对于开发人员来说，需要关注的分支就只有主干和自己working的分支两条，只需要进行push和两条液体命令就能完成所有分支操作。同时由于和入频率的提高，平均每个人需要解决的冲突量大大减少，这无疑解决了很多开发人员的痛点。需要说明的是，分支策略和版本发布模式没有赢荡，这个策略可能并不适合所有团队的项目，提高投入频率尽快能让产品快速迭代，但无疑会让新开发的特性很难得到充分的手工测试及验证。为了解决这一矛盾点，这背后需要有强大的基础设施及长期的习惯培养做支持。这里将难点分为以下几个类型，大家可以针对这些难点做一些考量，来确定是否有必要采用主干开发的方式。第一是完善且快速的自动化测试。只有在单元测。

是集成测试一图，于测试覆盖率提高且通过变例测试得到的测试用例质量较高的情况下，才能对项目质量有一个整体的保障。但这需要团队内所有成员喜观TDD测试驱动开发的开发方式，这是一个相当漫长的工程文化培养过程。第二是honor责任制的Co review机制，让开发人员具有owner意识，对自己负责的模块进行主行评审，可以在代码修改时规避许多架构设计上的破坏性修改与坑点，本质上难点还是开发人员的习惯培养。第三是大量的基础设施投入。高频的自动化测试其实是一个相当消耗资源的操作，尤其是一出于测试，每一个测试用力都需要启动一个无头浏览器来支撑。此外，为了提高测试的效率，需要多核的机器来并行执行，这里每一项都是较大的资源投入。

第四是快速稳定的回复能力和精确的线上及灰度监控等等，只有在高度自动化的全链路监控下，才能保障该机制下发布的新版本能够稳定运行。第三步就是编译并整理产物。在中小型项目中，这一步通常会被直接省略，直接将构建产物交由部署环节实现。但对于大型项目来说，多次频繁的提交构建会产生数量庞大的构建产物，需要得到妥善的管理。那这里以前端项目为例，我们可以做两点优化，第一，针对静态文件，如CSSJS等资源，使用C发布到云对象存储中，并以此为原站同步给CDN做访问速度优化，第二，针对HTML制品，需要使用CL指出服务做支撑，并打包成都可镜像与后端的微服务镜像同等级别，供上游的流量分发服务网关根据用户请求选择调取哪些服务复杂进行消费。对于一个好的工具来说，内部设计可以很复杂，但对于使用者来说，必须足够简单且好用。

在高频的持续集成下，集成速度及效率、流水线的执行时间毫无疑问是开发人员最关心的，也就是流水线是否好用的决定性指标。我们可以从几个方面着手，提高流水线执行效率，减少开发人员的等待时间。第一，流水线任务编排。对流水线各个阶段需要执行的任务，我们需要遵循一定的编排原则，无前置的任务优先执行，时间短的任务优先，五八年的任务并行。

根据这一原则，我们可以通过分析流水线中执行的各个任务，对每一个任务做一次最短路径依赖分析，最终得出该任务的最早执行时机。第二，采用docker catch docker提供了这样一个特性，在docker镜像构建过程中，Do file的每一条可执行语句都会构建出一个新的镜像层并缓存起来。在第二次构建时，都可会以镜像层为单位逐条检查自身的缓存，若命中相同镜像层，则直接复用该条缓存，使得多次重复构建的时间大大缩短。我们可以利用高可的这一特性，在流水线中减少通常可以重复执行的步骤，从而提高CI的执行效率。同理，我们也可以将这一特性扩展到cii过程中所有更新频率不高、生成时间较长的任务中。例如Linux中，环境依赖的安装单元测试。

是每条用例运行前的缓存，甚至是静态文件、数量极多的文件夹的复制等等，都能利用moca的特性，达到几乎跳过步骤减少集成时间的效果。由于原理大致相同，在此就不赘述了。第三，分级构建。众所周知，流水线的执行时间一定会随着任务数量的增多而变慢。大型项目中，随着各项指标计算的接入，各项测试用力的数量逐渐增多，运行时间迟早会达到我们难以忍受的地步。但是测试用力的数量一定程度上决定着我们项目的质量，质量检查绝不能少。那么有没有一种方法既可以让项目质量得到持续保障的同时减少开发者等待集成的时间呢？答案就是分级构建。

所谓分级构建，就是将CR流水线拆分为主构建和次构建两类。其中主构建需要在每次提交代码时都要执行，并且若检查不通过无法进行下一操作。而四级构建不会阻塞工作流，通过盘物的方式在代码合入后继续执行。但是一旦刺激构建验证失败，流水线将会立即发出通告告警并阻塞其他所有代码的合入，直到该问题被修复为止。对于某任务是否应该放入次级构建的过程，有如下几点建议，第一，次级构建可以包含执行时间长如超过15分钟，消耗资源多的任务，如自动化测试中的EV测试。第二，次级构建应当包含用力优先级低或者出错可能性低的任务，尽量不要包含重要链路。如果自动化测试中的一些测试用力，经过实践发现失败次数较高。

应当考虑增加相关功能单元测试，并移入主构建过程。若自己构建仍然过长，可以考虑用合适的方法分割测试用例，并行测试，最后做个小结。我们认为，从代码集成、功能测试到部署发布的每一个环节都应该有全面且完善的自动化手段，并尽量避免人工介入。只有这样，软件才能同时兼顾质量与效率，在提高发布频率的情况下保证可靠性。以下呢是我们为大家总结的关于持续集成的六个最佳实践。第一，透明单一的代码源，保证大家都使用相同的代码源，可以随时获取到最新的软件。第二，要频繁提交代码。每人每天都要向主干分支提交代码，并进行构建和测试。提交前要首先在本地完成构建和测试，因为每次变更都很小，所以提成起来也很轻松。使用此方式每完成一小段代码就能很快的更新给整个团队，而不是一次更新一大段。第三，使用高性能的集成服务器。公寓上骑士必先比其器，硬件首先要满足需求，同时还要优化构建过程，仅包含必要的任务下，如代码检查、编译构建、代码级的自动测试，加快构建的速度。第四，自动化的构建测试，相对于人工操作，自动化速度更快，避免误操作。

解放了人力资源，去做更重要的事情。第五，提升后的信息要准确及时反馈给团队成员，信息要准确、经验，避免冗余信息过多，致使开发人员渐渐忽略提示邮件，错过重要的反馈。第六，建立相应的工程师文化传统开发中代码长期在本地放置链条之前才提交到代码仓库，我们应该改正这种推迟风险的心理，要及早提交，并做到小步提交，代码完整，不影响已有功能等，并且每个人都要为自己提交的代码负责，集成失败要马上修复，修复成功后再继续其他工作。

众所周知，持续集成工具已经成为自动化和敏捷开关的核心支撑工具。然而，随着de set off里面的兴起，越来越多的企业开始意识到将安全集升到整个软件开发生命周期中的重要性。他们不在一昧的追求快速交付，而是希望在保证速度的情况下交付更安全的软件。也正是在这样的背景下，持续集成工具被赋予了新的使命。那么，如何打造一条更安全的持续集成流水线呢？这些年，有一个新的理念被提出来，那就是everyday next code、一切及代码。他被认为是从技术和流程角度来提高持续集成流水线安全性的一个重要武器。every平台code翻译过来就是一切级代码，意思是将一切都转换成代码来进行管理。一些具体的实践，包括pipeline code infrastructure as code和policy code等。这些内容。

在我们已上线的公开课代码管理的发展、工作流与新使命中已经介绍过了，需要学习的同学可以在本账号中翻阅课程回放了解相关内容，这里我就不再赘述了。在详细讲解coding持续集成解决方案之前，我们先来看看coding的能力全景图，如上图所示，Coding是一站式的off研发管理平台，涵盖了软件开发生命周期中的各个阶段。这里开始我们呼应一下开头所讲持续集成的使用场景，看看使用coding是如何实现的。借助coding CI，我们可以自动执行编译、单元、测试和推送都可镜像等操作快速构建应用。我们还可以使用coding CI来实现代码规范的检查工作。当开发人员创建一个合并请求以后，会先触发一个代码规范检查的流水线，对用户提交的代码进行检查。如果用户提交的代码未能通过代码规范检查，则禁止用户进行代码合并操作。借助Co cii，我们还可以实现测试工作的自动化。下面的截图就是一个实际的例子。在这个例子中，我们使用Python作为编程语言，Pypa作为测试执行器，通过sli web driver来模拟UI操作，并使用coding的持续集成流水线来实现测试工作的自动化。每日构建是将项目的最新代码拉取出来，并执行编译和单元测试，从而尽早发现错误并报告错误的完整过程。它。

他从每天至少构建软件一次，因为对于许多大型项目来说，每次构建花掉的时间可能高达几个小时。在白天进行构建可能会消耗计算机资源，还容易对开发造成一定的影响，造成时间的浪费。所以许多大型项目的每日构建是在夜间无人工作或者人比较少的时候进行的。解除coding CI所提供的定时触发功能，就能轻松实现每日构建流水线。

除了编译和构建都可镜像等操作以外，Holding虽然还支持部署应用到远端服务器，那有没有一种高效的方法能够实现getth top代码仓库与Co仓库的定时同步呢？答案是使用cii定时触发构建计划，这样便能够避免手动拉取get up仓库里的代码，然后再推送至托ing仓库的防琐操作，一劳永逸。在这里我们可以看到coding为我们准备了非常丰富的模板，并且根据编程语言和功能的不同进行了分类。借助coding提供的这些模板，可以快速创建可运行的流水线，节省大量时间。如果coding所提供的云主机不能满足需求时，我们还可以添加自己的服务器作为自定义构建节点来执行构建任务。接下来我们再来看看holding持续集成模块所提供的变量与缓存功能。在流程环境变量这里，我们可以通过可视化界面很方便的去为流水线添加环境变量。

除了环境变量以外，还支持缓存目录功能。开启缓存可以避免每次构建都重复下载相同的依赖文件，从而大幅提升构建速度，缩短构建时间。比如，如果单选的项目基于项目，那么就可以将never这个选项进行勾选，勾选完以后，流水线只有在首次执行时才会去拉取这些memory依赖，后续的其他构件都直接使用这些已经缓存好的依赖，而不是重复拉取相同的依赖。右下角的截图是coding所提供的云主机的一些配置信息。值得一提的是，Coding所提供的云主机默认就安装了大量主流的SDK和命令函工具，避免了用户自行安装的麻烦。

这就是coding的持续集成流水线截图支持文本编辑和可视化编辑两种模式。在可视化编辑模式下，用户可以通过右键菜单快速创建一个代码扫描步骤，再通过添加相关的触发器配置，可以实现用户每次提交代码都自动触发这个代码扫描的流水线，并将相应的扫描结果发送到企业微信群，方便相关人员快速做出响应。值得一提的是，Q的代码扫描功能支持增量扫描，可以大大节省扫描所需的时间。这就是这条代码扫描流水线的执行效果图。通过配置这么一条代码扫描流水线，我们不需要进入相关的界面去查看代码扫描结果，因为系统会自动将代码扫描的结果推送给我们，帮助实时跟踪代码质量问题及其发展趋势。holding的持续集成模块内置了大量的官方插件。前面已经提到过，流水线支持图形化编辑器，我们只要在弹出菜单中选择内置的各种插件就能完成常见任务。为了满足客户的各种使用场景，Co CI在设计之初就将灵活性和可拓展性作为产品设计的重要目标，它的体现在于用户不光可以使用官方插件，还可以开发自己的团队插件。coding还提供了丰富的open API，用户可以很方便的将coding与第三方应用进行集成。coding持续集成的完整演示视频将由来自腾讯coding。

团队的解决方案架构师钟启光为大家进行演示与解说。