前端持续集成

时间:2021-1-18 作者:admin

一、定义

持续集成(continuous integration)是一种软件开发实践,即团队开发成员经常集成它们的工作(即将代码合并到公共分支上),通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

二、好处

1、减少风险,每天都进行集成并且每次集成都经过了相应的测试,可以较为快速的定位错误
2、防止分支大幅度偏离主分支,后期难以集成
3、减少手动发代码的重复工作量
4、增强项目的可见性,项目成员均可了解项目情况,有利于团队协作

三、集成工具

集成工具有比较多,本文介绍的是GitLab CI

GitLab CIGitLab内置的进行持续集成的工具,只需要在仓库根目录下创建.gitlab-ci.yml 文件,并配置GitLab Runner,每次提交的时候Gitlab将自动识别到.gitlab-ci.yml文件,并且使用Gitlab Runner执行该脚本。

GitLab CI由以下两个模块组成:
gitlab-ci server:负责调度、触发Runner,以及获取返回结果.
gitlab-ci-runner:则是主要负责来跑自动化CI(测试,编译,打包等)。

Gitlab Runner就是一个用来执行.gitlab-ci.yml脚本的工具,可以理解成GitLab-CI就像是管理中心,runner入职成为管理员,首先要办理入职手续(即注册),并说明自己负责哪个项目,后续当相应的项目发生变化时,GitLab-CI就会通知相应的runner响应变化(即执行对应的脚本)。

GitLab-Runner可以分成两种类型:
Shared Runner(共享型):所有工程都能够用的,且只有系统管理员能够创建。
Specific Runner(指定型):只有特定的项目可以使用。

四、GitLab CI实践

1、安装Runner

Runner安装步骤(linux为例):

// 下载
curl -LJO https://gitlab-runner-downloads.s3.amazonaws.com/latest/rpm/gitlab-runner_<arch>.rpm
// 安装
rpm -i gitlab-runner_<arch>.rpm

其余系统安装可参考官网文档

2、注册Runner
gitlab-runner register

之后会要求输入gitlaburltoken,进入gitlab仓库,点击左侧菜单栏的Settings -> CI/CD,展开Runners的设置项即可查找到相应的urltoken。再根据提示输入Runner的描述、tag以及运行平台(本文选择shell)。注册完成后可以在刚刚查找gitlaburltoken的地址看到新建立的tag

3、.gitlab-ci.yml

服务器上完成了gitlab-runner的安装和注册后,我们就需要在项目的根目录下建立一个.gitlab-ci.yml文件,.gitlab-ci.yml 文件定义GitLab runner要做哪些操作。基本示例如下:

# 定义 stages
stages:
    - dev
    - sit

# 定义变量
variables:
    project: projectName

# 定义 job
dev-job1:
    stage: dev
    only:
        refs:
            - /^dev$/
        variables:
            - $CI_COMMIT_MESSAGE =~ /\-\-build/
    script:
        - echo "I am the dev job "
        - sh xxx.sh
    tags:
        - dev

# 定义 job
sit-job1:
    stage: sit
    only:
        refs:
            - /^sit$/
        variables:
            - $CI_COMMIT_MESSAGE =~ /\-\-build/
    script:
        - echo "I am the sit job"
        - sh xxx.sh
    tags:
        - sit

stages

每个推送到Gitlab的提交都会产生一个与该提交关联的管道(pipeline),若一次推送包含了多个提交,则管道与最后那个提交相关联,管道(pipeline)就是一个分成不同阶段(stage)的任务(job)的集合。可以理解成pipeline就像是一条流水线,每条流水线上会有很多的阶段,每个阶段上会有相应的任务。

所有Stages会按照顺序运行,同一state中的job会并行执行,都执行成功了,该stage才会成功。当一个Stage完成后,下一个Stage才会开始,只有当所有 Stages完成后,该构建任务 (Pipeline) 才会成功。如果同一state中的任何一个job执行失败,则该state执行失败,如果任何一个Stage失败,那么后面的 Stages不会执行,该构建任务 (Pipeline) 失败。

variables

除了Runner自定义的变量之外,也可以根据自己的需求自定义构建变量。

jobs

每个job都必须有一个唯一的名字。它由一系列参数来定义job的行为。
stage:标明该job属于哪一个stage;
only:定义该job执行条件,示例中dev-job1执行的条件就是必须是dev分支,并且提交信息中要添加构建命令--build;
scriptrunner执行的命令或脚本,这里需要执行一个shell脚本,将项目构建打包,并将打包后的文件放到相应的域名文件夹下完成发布。

job的完整关键字可见参考官网

tags

可以从允许运行此项目的所有Runners中选择特定的Runners来执行该job。(第二步中注册runner的时候设置的tag)

4、构建发布

相应分支的代码提交时,在提交信息中增加--build指令,即可完成自动测试构建发布。

声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎进行举报,并提供相关证据,工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。