在前后端分离以后,前端项目一般基于nodejs配合webpack等打包进行开发,在进入生产环境之前,需要经过打包,测试等过程,这些流程费时费力,应该利用自动化工具来帮助完成。

相比于jenkins,travisci等工具,gitlab-ci的优势是集成性好,一般企业内部都会选用gitlab来作为内部仓库,另外就是轻量,在前端或者一些内部工具的持续构建的场景下,配合git-flow开发流,gitlab-ci能很好的发挥优势。

CI流程

在整个开发周期内,gitlab-ci的工作区间位于提交代码之后,部署之前。它定义了一个流水线,在流水线内配置多个JOB,可自由配置job的顺序来完成一个完整的构建,打包,部署的过程。定义流水线的文件叫 .gitlab-ci.yml

gitlab-runner

gitlab-runner是一个服务,用来监听指定的git仓库的变化,然后执行.gitlab-ci.yml文件中定义的job。 gitlab-runner最好单独部署在一台服务器上,安装教程参考 https://docs.gitlab.com/runner/install/
安装成功以后,需要为代码仓库注册runner,也可以为一个gitlab组分配一个runner
注册成以后可以命令行查看状态

.gitlab-ci.yml

用来配置ci的pipeline流程,比如自动build,自动部署

stage 用来配置ci的流水线,以job为执行单位,以stage为执行流程 例如对于一个典型的前端项目,常见执行流程是

   stages:
   	- build
   	- test
   	- deploy

job 对于build流程,执行Job的内容通常是

build_job:
  stage: build
  script:
    - npm install
    - npm run build
  only:
    - master

如果流水线需要有多个job按顺序执行,那么就需要定义stage,并在job中指定它所处的stage 每个任务执行内容用script来定义

job的触发时机用only字段指定,这是一个比较常用的功能。通常发布时,会单独切一个release_xxxx的分支出来,而测试环境部署的是相应的开发的分支,测试环境和生产环境的部署是不同的job和不同的分支,only字段就通过指定分支将不同的job区分开来,例如

test_deploy_job:
  stage: deploy
  script:
    - ./deploy-test.sh
  only:
    - /^dev/
prod_deploy_job:
  stage: deploy
  script:
    - ./deploy-prod.sh
  only:
    - /^release/

only字段可以使用正则表达式,上面的例子中,所有以dev开头的分支的改动都会触发测试环境部署,所有以release开头的分支的改动都会触发生产环境部署。

总结下整个流程为

实际应用场景

内部系统的自动化部署

内部系统接入gitlab-ci,然后每次发布时,切一个release分支,自动触发构建 结合gitlab的分支保护和角色功能可以做到权限控制,只允许特定的人员review代码后再切release分支,这一套流程相比使用jenkins,对开发人员更加友好快捷。

自动发布内部npm包

这是我在公司内部推行的一套npm包发布规范,需要配合自研的npm命令行工具来初始化npm包,并自动创建npm仓库,开发人员提交代码到仓库的开发分支,然后联系管理员review,审核通过后合并到master,并触发ci构建,然后自动npm publish