大型前端项目 DevOps 沉思录 —— CI 篇

摘要

DevOps 一词源于 Development 和 Operations 的组合，即将软件交给进程中开发与测验运维的环节通过东西链打通，并通过自动化的测验与监控，削减团队的时刻损耗，更加高效安稳地交给制品。

本篇文章将着重讨论 DevOps 在 继续集成阶段需求供给的才干，将对工作流的规划及流水线的优化思路做一个扼要解说。

跟着项目规划越来越大，功用特性与保护人员越来越多，特性交给频率与软件质量之间的对立日渐尖锐，怎么平衡两者成为了现在团队亟需关注的一个重点，所以，落地一个完善的 DevOps东西链便被提上日程。

咱们以为，从代码集成、功用测验，到布置发布、基础设施架构办理，每一个环节都应该有全面且完善的自动化监控手段，并尽量避免人工介入。只要这样，软件才干一起兼顾质量与功率，在提高发布频率的情况下确保可靠性。这是每一个成功的大型项目终究必定要完结的方针。

本篇文章将着重讨论 DevOps 在 继续集成阶段 需求供给的才干，将对工作流的规划及流水线的优化思路做一个扼要解说。

当咱们在议论 CI 时，咱们在议论什么

CI(Continuous Integration)，即继续集成，指频频地（一天屡次）将代码集成到骨干的行为。

留意，这儿既包括继续将代码集成到骨干的含义，也包括继续将源码生成可供实际运用的制品的进程。因而，咱们需求通过 CI，自动化地确保代码的质量，并对其构建产品转化生成可用制品供下一阶段调用。

因而，在 CI 阶段，咱们至少有如下阶段需求完结：

1. 静态代码查看

这其中包括，ESLINT/TSLINT 静态语法查看，验证 git commit message 是否契合标准，提交文件是否有对应 owner 能够 review 等等。这些静态查看不需求编译进程，直接扫描源代码就能够完结。

2. 单元测验/集成测验/E2E 测验

自动化测验这一环节是保障制品质量的关键。测验用例的掩盖率及用例质量直接决议了构建产品的质量，因而，全面且完善的测验用例也是完结继续交给的必备要素。

3. 编译并收拾产品

在中小型项目中，这一步一般会被直接省掉，直接将构建产品交由布置环节完结。但关于大型项目来说，屡次频频的提交构建会产生数量巨大的构建产品，需求得到妥善的办理。产品到制品的建立咱们接下来会有具体解说。

利于集成的工作流规划

在正式接入 CI 前，咱们需求规划好一种新的工作流，以适应项目切换为高频集成后或许带来的问题与难点。这儿涉及到的改造层面十分多，除了敦促开发人员习气的转变以及进行新流程的培训外，咱们首要关怀的是源码库房的更新触发继续集成过程的办法。

流水线的组织方式

咱们需求一个适宜的组织方式来办理一条 CI 流水线该在什么阶段履行什么使命。

市道上有十分多的 CI 东西能够进行选择，仔细观察就会发现，无论是 Drone 这样的新式轻量的东西，亦或是老牌的 Jenkins 等，都原生或通过插件办法支撑了这样一个特性： ConfigurationasCode，即运用配置文件办理流水线。

这样做的好处是适当大的。首要，它不再需求一个 web 页面专门用于流水线办理，这关于途径方来说无疑削减了保护成本。其次关于运用方来说，将流水线配置集成在源码库房中，享用与源码同步升级的办法，使得 CI 流程也能运用 git 的版别办理进行标准与审计溯源。

确立了流水线的组织方式后，咱们还需求考虑版别的发布方式以及源码库房的分支战略，这直接决议了咱们该以什么样的办法规划流水线进行代码集成。

版别发布方式的取舍

在《继续交给 2.0》一书中提到，版别发布方式有三要素： 交给时刻、特性数量以及交给质量。

这三者是相互制衡的。在开发人力与资源相对固定的情况下，咱们只能对其中的两个要素进行确保。

传统的项目制发布方式是献身了交给时刻，等候一切特性悉数开发完结并经历完好人工测验后才发布一次新版别。但这样会使得交给周期变长，而且因为特性数量较多，在开发进程中的不可控危险变高，或许会导致版别无法准时交给。不契合一个老练的大型项目关于继续交给的要求。

关于继续集成的思想来说，当咱们的集成频率满足高，自动化测验满足老练且安稳时，完全能够不必一股脑的将特性全堆在一次发布中。每开发完结一个特性就自动进行测验，完结后合入等候发布。接下来只需求在特定的时刻周期节点自动将现已安稳的等候中的特性发布出去即可。这关于发布频率越来越高，发布周期越来越短的现代大型项目中无疑是一个最优解。

分支战略

与大部分团队一样，咱们原有的开发方式也是 分支开发，骨干发布的思想，分支战略选用业界最老练也是最完善的 Git-Flow方式。

能够看出，该方式在特性开发，bug 修正，版别发布，乃至是 hotfix 方面都现已考虑到位了，是一个能应用在出产环境中的工作流。但全体的结构也因而变得极为复杂，不便办理。例如进行一次 hotfix 的操作流程是：从最新发布前运用的骨干分支拉出 hotfix 分支，修正后合入到 develop 分支中，等候下一次版别发布时拉出到 release 分支中，发布完结后才干合回骨干。

此外，关于 Git-Flow的每一个特性分支来说，并没有一个严格的合入时刻，因而关于较大需求来说或许合入时刻间隔会很长，这样在合入骨干时或许会有大量的抵触需求解决，导致项目工期无端延伸。对此，做大型改造与重构的同学应该深有体会。

针对这一点，咱们决议大胆选用 骨干开发，骨干发布的分支战略。

咱们要求，开发团队的成员尽量每天都将自己分支的代码提交到骨干。在抵达发布条件时，从骨干直接拉出发布分支用于发布。若发现缺点，直接在骨干上修正，并依据需求 cherry pick 到对应版别的发布分支。

这样一来，关于开发人员来说需求关注的分支就只要骨干和自己 working 的分支两条，只需求 push 与 merge 两条 git 命令就能完结一切分支操作。一起，因为合入频率的提高，平均每人需求解决的抵触量大大削减，这无疑解决了许多开发人员的痛点。

需求说明的是，分支战略与版别发布方式没有银弹。咱们选用的战略或许并不适宜一切团队的项目。提高合入频率赶快能让产品快速迭代，但无疑会让新开发的特性很难得到充沛的手艺测验及验证。

为了解决这一对立点，这背面需求有强壮的基础设施及长期的习气培育做支撑。这儿将难点分为如下几个类型，咱们能够针对这些难点做一些考量，来确定是否有必要选用骨干开发的办法。

1. 完善且快速的自动化测验。只要在单元测验、集成测验、E2E 测验掩盖率极高，且通过变异测验得出的测验用例质量较高的情况下，才干对项目质量有一个全体的确保。但这需求团队内一切开发人员习气 TDD（测验驱动开发）的开发办法，这是一个适当漫长的工程文明培育进程。

2. Owner 责任制的 Code Review 机制。让开发人员具有 Owner 认识，对自己负责的模块进行逐行查看，能够在代码修改时规避许多规划架构上的破坏性修改与坑点。本质上难点其实还是开发人员的习气培育。

3. 大量的基础设施投入。高频的自动化测验其实是一个适当耗费资源的操作，尤其是 E2E 测验，每一个测验用例都需求发动一个无头浏览器来支撑。另外，为了提升测验的功率，需求多核的机器来并行履行。这儿的每一项都是较大的资源投入。

4. 快速安稳的回滚才干和精准的线上及灰度监控等等。只要在高度自动化的全链路监控下，才干确保该机制下发布的新版别能够安稳运转。这儿的建造我会在之后的文章里具体介绍。

大型项目中产品->制品的建立

关于大多数项目来说，在代码编译完结生成产品后，布置项目的办法便是登录发布服务器，将每一次生成的产品张贴进发布服务器中。生成的静态文件因为 hash 不同能够一起寄存，html 选用直接掩盖的办法进行更新。

直接运用仿制张贴的办法来操作文件的更新与掩盖，这样既不便利对更新前史的审计与追溯，一起这样的更改也很难确保正确性。

除此之外，当咱们需求回滚版别时，因为服务器上并没有寄存前史版别的 html，因而回滚的办法其实是从头编译打包生成前史版别的产品进行掩盖。这样的回滚速度显然不是令人满意的。

一个解决办法是，不要对文件进行任何的掩盖更新，一切的产品都应该被上传持久化存储。咱们能够在恳求上游增设一个流量分发服务，来判别每一条恳求应该回来哪一个版别的 html 文件。

关于大型项目来说，回来的 html 文件也不必定不是一成不变的。它或许会被注入途径、用户自定义等标识，以及 SSR 所需求的首屏数据，然后改变其代码方式。因而，咱们以为 html 文件的制品供给方应该是一个独自的动态服务，通过一些逻辑完结对模板 html 的替换并终究输出。

总结一下，在每次编译完结后，产品将会进行如下的收拾以生成终究的前端制品：

1. 针对静态文件，如 CSS、JS 等资源将会发布到云目标存储中，并以此为源站同步给 CDN 做拜访速度优化。

2. 针对 HTML 制品，需求一个直出服务做支撑，并打包成 docker 镜像，与后端的微服务镜像同等等级，供上游的流量分发服务（网关）依据用户恳求选择调起哪些服务负载进行消费。

速度即功率，流水线优化思路

关于一个好的东西来说，内部规划能够很复杂，但关于运用者来说有必要满足简略且好用。

在骨干开发这样高频的继续集成下，集成速度即功率，流水线的履行时刻毫无疑问是开发人员最关怀的，也是流水线是否好用的决议性指标。咱们能够从几个方面着手，提高流水线履行功率，削减开发人员的等候时刻。

流水线使命编列

对流水线各个阶段需求履行的使命咱们需求遵循必定的编列准则： 无前置的使命优先， 履行时刻短的使命优先， 无关联的使命并行。

依据这一准则，咱们能够通过剖析流水线中履行的各个使命，对每一个使命做一次最短路径依靠剖析，终究得出该使命的最早履行时机。

巧用 Docker Cache

Docker 供给了这样一个特性：在 Docker 镜像的构建进程中，Dockerfile 的每一条可履行句子都会构建出一个新的镜像层，并缓存起来。在第2次构建时，Docker 会以镜像层为单位逐条查看本身的缓存，若射中相同镜像层，则直接复用该条缓存，使得屡次重复构建的时刻大大缩短。

咱们能够使用 Docker 的这一特性，在流水线中削减一般会重复履行的过程，然后提高 CI 的履行功率。

例如前端项目中一般最耗时的依靠装置 npm install，改变依靠项关于高频集成来说其实是一个较小概率的事情，因而咱们能够在第一次构建时，将 node_modules这个文件夹打包成为镜像供下次编译时调用。Dockerfile 示例编写如下：

FROM node:12 AS dependencies
WORKDIR /ci
COPY . .
RUN npm install
ENV NODE_PATH=/ci/node_modules

咱们给流水线增加一条查看缓存射中的战略：在下次编译之前，先查找是否有该镜像缓存存在。而且，为了确保本次构建的依靠没有更新，咱们还有必要比对本次构建与镜像缓存中的 package-lock.json文件的 md5 码是否共同。若不共同，则从头装置依靠并打包新镜像进行缓存。若比对成果共同，则从该镜像中直接取到 node_modules文件夹，然后省去大量依靠装置的时刻。

流水线拉取镜像文件夹的办法示例如下，其中 --from 后跟的是之前缓存构建镜像的别名：

COPY --from=dependencies node_modules/ .# 其他过程履行

同理，咱们也能够将这一特性扩展到 CI 进程中一切更新频率不高，生成时刻较长的使射中。例如 Linux 中环境依靠的装置、单元测验每条用例运转前的缓存、乃至是静态文件数量极多的文件夹的仿制等等，都能使用 Docker cache 的特性到达简直跳过过程，削减集成时刻的效果。因为原理大致相同，在此就不赘述了。

分级构建

众所周知，流水线的履行时刻必定会跟着使命数量的增多而变慢。大型项目中，跟着各项指标计算的接入，各项测验用例的数量逐步增多，运转时刻迟早会到达咱们难以忍受的境地。

可是，测验用例的数量必定程度上决议着咱们项目的质量，质量查看决不能少。那么有没有一种办法既能够让项目质量得到继续保障的一起，削减开发者等候集成的时刻呢？答案便是分级构建。

所谓分级构建，便是将 CI 流水线拆分为主构建和次级构建两类，其中主构建需求在每次提交代码时都要履行，而且若查看不通过无法进行下一步操作。而次级构建不会堵塞工作流，通过旁路的办法在代码合入后继续履行。可是，一旦次级构建验证失利，流水线将会当即发出通知告警，并堵塞其他一切代码的合入，直到该问题被修正为止。

关于某使命是否应放入次级构建进程，有如下几点准则：

1. 次级构建将包括履行时刻长（如超过 15 分钟）、耗费资源多的使命，如自动化测验中的 E2E 测验。

2. 次级构建应当包括用例优先级低或者犯错或许性低的使命，尽量不要包括重要链路。如果自动化测验中的一些测验用例通过实践发现失利次数较高，应当考虑增加相关功用单元测验，并移入主构建进程。

3. 若次级构建仍然过长，能够考虑用适宜的办法切割测验用例，并行测验。

结语

工欲善其事，必先利其器。腾讯文档项目高频安稳发布的背面，必定需求拥有强壮基础设施的支撑。

本篇文章仅首要介绍了继续集成阶段对项目进行的改造，继续布置、继续运营等阶段的具体改造思路将在笔者接下来的文章中具体说明。也欢迎咱们多多讨论，对其中需求改进或有误的部分提出建议与指正。

参考资料

1. 《继续交给 2.0》—— 乔梁 著
2. www.redhat.com/zh/topics/d…
3. www.36kr.com/p/121837544…

关于咱们

更多关于云原生的事例和知识，可关注同名【腾讯云原生】大众号~

福利：

①大众号后台回复【手册】，可获得《腾讯云原生路线图手册》&《腾讯云原生最佳实践》~

②大众号后台回复【系列】，可获得《15个系列100+篇超有用云原生原创干货合集》，包括Kubernetes 降本增效、K8s 功能优化实践、最佳实践等系列。

③大众号后台回复【白皮书】，可获得《腾讯云容器安全白皮书》&《降本之源-云原生成本办理白皮书v1.0》