一、背景

在携程的日常Web开发生命周期中，本地代码开发阶段可通过NFES框架（携程内部一个支持SSR框架，其中还包含许多公共基础业务模块及UI组件）来快速完成项目需求。但开发完代码之后常常会遇到如下几点问题：

• 环境问题：Web/Node资源本地构建/测试环境和生产环境差异化大，导致有些问题无法及时发现
• QA流程：Web/Node端提交代码流程没有规范的QA环节，代码质量不可控
• 构建流程：资源本地构建与镜像构建是独立的，版本易混淆
• 代码开发完后的各个步骤比较分散，难集中管理

二、目标

通过引入CI/CD解决方案，建立完善的准备环境/测试/资源构建/镜像构建一整个流程的链路，使它可帮助项目以更快的速度和更高的质量来交付。

三、实现与实践

NFES 的 Web CI/CD 的实现，简单来说就是通过管道化 (GitDev Pipeline) 的执行过程来完成持续集成和持续交付，这篇文章先不涉及持续部署。

其管道 (Pipeline) 中集成QA，资源构建，生成镜像等多个Stage，而每个Stage中都包含详细的Step来完成其功能。接下来我们来详细从管道 (Pipeline) 中的Stage/Step的角度来介绍下NFES的Web CI/CD。

管道在这里可以理解为实现目标的顶层组件，整个NFES Web CI/CD就是这样的组件组合而成。目前Web/Node相关的管道分为三个Stage：

1）Install Stage

a. Install Step，安装用户项目下的依赖模块

2）Verify Stage

这里集成了三个Step：

a. Lint Step，静态代码检测

b. Test Step，单元测试/UI测试

c. Build Step，资源构建

3）SonarAndImage Stage

a. Sonar Step，Sonar代码检测并上传，此步骤依赖于Verify Stage中的Lint/Test Step

b. Image Step，构建Docker镜像，此步骤依赖于Verify Stage中的Build Step

上面三个Stage是依次顺序执行，而在同个Stage中的多个Step则是并发执行的。这些执行顺序的控制可通过编写.gitlab-ci.yml文件来完成。这里先简单介绍下.gitlab-ci.yml CI/CD配置的编写。

.gitlab-ci.yml是放在仓库根目录中的文件，默认仓库会去这个文件中读取CI/CD的相关配置。在此文件配置中你可以定义如下：

• 定义环境变量
• 需要顺序或者并行运行的脚本命令
• 前后Step依赖关系
• 此Step所需使用缓存和设置缓存
• 触发的条件分支

具体常用配置代码如下：

#配置所需的基础镜像地址
image: xxxxxxxxx

#配置相关变量
variables:
  PROXY: http://proxy
  HTTP_PROXY: $PROXY

#配置Stages的名称及顺序
stages:
  - Install
  - Verify

......
# Install Stage的详细配置
Test:          #Step的名称
  stage: Verify  #属于哪个Stage
  artifacts:      #配置产物存档文件,可在Pipeline运行界面取到配置的文件,但此存档只能保存默认一周
    paths:
     - reports/
    exclude:      #忽略某些文件不作为产物存档文件
      - .git
      - .git/**
    when: always 
  cache:          #配置缓存
    key: keyName
    paths:
      - node_modules  #所需缓存的文件/文件夹
    policy: pull      #如需获取缓存的文件,这里定制policy属性为pull
  allow_failure: true #此步骤是否允许失败,如果允许,即使步骤执行失败,仍旧可执行下个Stage
  dependencies:       #配置此Step依赖哪个Step
    - Install
  script:             #配置所需执行的命令
    - cd /testFolder  
    - node index
  only:
    - master          #配置分支 只有配置的分支才会执行相关的Pipeline

......

在日常开发使用中，携程的GitDev CI/CD则提供公用的配置模版，如用户没有特殊Step的需求，可通过选择Step模版或者选择应用类型模版来自动生成上面的配置文件，无需关注yml的详细配置。

接下来我们详细看下NFES Web CI/CD的Install，Verify和SonarAndImage三个Stage做了哪些事情？

3.1 Install Stage

Install Stage中只包含一个Step，即执行安装用户项目下的模块依赖。此阶段安装结束后的nodemodules则会作为缓存给之后的Step使用，可节省很多不必要的重复安装模块的时间。当然如果在同一个commitID的情况下，多次执行这个Install Stage，则后面几次安装的nodemodules其实就是取第一次安装的缓存。

3.2 Verify Stage

Verify Stage默认会包含三个步骤Lint，Test，Build。这个Stage其实是一个规范的QA环节，而Build的Step为什么要放在此处，就是想构建与测试并发执行，从而缩短整个Pipeline的运行时间。

详细的各个Step的实现如下：

1）Lint Step集成了eslint静态代码检测功能

静态代码检测功能通过封装的全局模块来完成代码检测，其默认使用eslint:recommended推荐规则。如用户需要自定义eslint规则可以直接把规则写在当前项目的eslintrc.json文件中，模块会自动整合其默认规则。如想要忽略检查某些文件，则把规则写在.eslintignore文件中。执行完成后会生成eslint-report.json，此文件会作为artifacts可在pipeline的step任务页面中直接下载查看，也会通过后面的Sonar Step上传到Sonar。

2）Test Step集成了单元测试以及UI测试

集成的单测框架又可分为mocha和jest，Web端统一使用jest，NFES测试镜像中默认已有jest相关模块，如无特殊需求则不需要在用户项目的依赖中安装测试相关依赖的模块。如需自定义jest相关配置可写在用户项目下的jest.config.js中。单元测试的运行命令统一为：npm run test，其执行结果会以html/json/clover/lcov输出，输出结果中lcov和clover.xml文件与GitDev做集成，使其结果与代码的commitID进行绑定，这样每次代码提交就可在界面上直接查看本次提交代码的具体单测运行结果。这里也可设置对每次代码提交的单元测试覆盖率的要求，如其覆盖率不低于60%，否则不能进行下一步骤。

每次代码提交的CommitID的单元测试结果展示如下：

集成的UI测试是作为一个可选Step，我们提供了集成puppeteer/cucumber的镜像，用户如有UI测试的需求可自行在Test Stage中添加该UI Test Step。在UI测试中增加了视频录制的功能，每个Case对应一个视频，等用户的UI Cases执行完成后，则会自动生成报表并发布到资源站点上，方便用户查看及排查问题。

UI测试报表结果中录制视频（部分截图）展示如下：

3）Build Step集成页面的资源构建

这里的构建其实就是把在线构建搬到了Pipeline的Build Step中。首先是构建环境的搭建，分为两块：框架所需的依赖模块环境和用户项目依赖的模块环境。

关于NFES框架的依赖模块环境，Build Step使用的构建镜像中已经集成了NFES项目所需的开发态模块（我们对开发态模块加载做了些优化，把如Babel插件，webpack，loader等通用的模块全都集成到cli的全局模块中，然后预装到构建镜像)。执行构建时，更改构建时项目所需开发态模块路径指向预装路径，这样就可以不需要安装框架依赖模块。而对于用户项目依赖的模块环境则可以重用Install Stage中的node_modules中的缓存，这两点使用户项目安装模块的时间大幅度减少。

搭建完构建环境后，执行相关在线构建命令开始构建，构建的过程及日志都可通过Pipeline界面得到。构建完成后接下来是构建产物的处理。这里的NFES项目构建产物可分为Web端资源/node服务端资源。Web端的资源可以直接发布并获得相应的资源地址，此Web资源地址也会及时更新到node服务端资源中的资源路径。最后通过配置中artifacts属性来确定哪些node端的资源文件需要上传给下一步Image Stage来构建发布镜像。

3.3 SonarAndImage Stage

SonarAndImage包含了Sonar和Image两个Step， 这个Stage是目前管道中最后一个专门收集与处理前面依赖Step产物的Stage。

1）Sonar Step

此步骤是依赖于Test和Lint这两个Step， 用来收集依赖的这两个Step执行的结果并上传至Sonar中。用户可以在sonarqube的网站查看历史的代码质量报告。

2）Image Step

此步骤是依赖于Build Step，它是获取Build的构建产物与基础镜像一起构建出发布镜像并推送到Hub中，为接下来的应用发布做准备。到此步骤整个NFES Web CI/CD的流程就结束了。

四、小结

以上就是整个NFES Web CI/CD的实现与实践。目前几乎所有的NFES项目都已经切到CI/CD的流程上，它带来了集中式流程化管理，一站式对用户透明的资源构建与镜像构建更简单快捷，开发效率得到了很大的提高。

团队招聘信息

我们是平台研发中心，一个为携程快速发展提供各类基础产品和服务的平台，我们以技术驱动提升客户体验，提升跨团队协作效率。

我们拥有优秀而强大的团队，引导你学习业内领先的开发技术，与技术高手交流对话，学习切磋。在亿级用户严苛的品质要求中，激发你脑中不断涌现的创新思维，带领你体验飞速成长的惊喜快乐，并在各种机遇与挑战中发展自我，成就自身。

目前我们前端、后台、算法、测试等技术岗位均有职位。简历投递：tech@trip.com，邮件标题：【姓名】-【携程平台研发中心】-【投递职位】

【作者简介】西杰，携程软件技术专家，关注前端技术及其生态，致力于提升前端开发效能及质量。