gitlab之配置文件.gitlab-ci.yml

自动化部署給我们带来的好处

自动化部署的好处体现在几个方面

1.提高前端的开发效率和开发测试之间的协调效率

Before

如果按照传统的流程，在项目上线前的测试阶段，前端同学修复bug之后，要手动把代码部署之后。才能通知测试同学在测试环境进行测试。

这会造成几个问题：本身手动部署服务的工作是比较繁琐的，占用了开发时间。同时开发-测试之间的环节的耦合问题，则会增加团队沟通成本。

After

通过gitlab-ci，前端开发在提交代码之后就不用管了，ci流程会自动部署到测试或集成环境的服务器。很大程度上节约了开发的时间。

同时，因为开发和测试人员可以共用gitlab里的pipeline界面, 测试同学能够随时把握代码部署的情况，同时还可以通过交互界面手动启动pipeline，自己去部署测试，从而节约和开发之间的沟通时间。

2.从更细的粒度把握代码质量

我们可以把eslint或其他的代码检查加到pipeline流程中，每当团队成员提交和合并一次，pipeline都会触发一次并对代码做一次全面检测，这样就从一个更细的粒度上控制代码质量了。

1.Pipeline & Job

Pipeline是Gitlab根据项目的.gitlab-ci.yml文件执行的流程，它由许多个任务节点组成, 而这些Pipeline上的每一个任务节点，都是一个独立的Job

Job在YML中的配置我们将会在下面介绍，现在需要知道的是：每个Job都会配置一个stage属性，来表示这个Job所处的阶段。

gitlab-ci的运行机制, 在项目根目录下配置.gitlab-ci.yml文件, 控制ci流程的不同阶段, 一般会包含

• install  安装
• eslint  检查
• build  编译
• deploy 部署

先看示例:

stages:  # 定义任务执行阶段
  - build  # 编译
  - deploy  # 部署

cache:  # 设置缓存, 默认一次任务完成, 会将产物进行删除
  key: module-cache  # 设置缓存键
  paths:  # 需要缓存的路径
    - node_modules
    - build

build:
  stage: build  # 当前所属阶段
  tags:  # 对应gitlab-runner中注册的tag(支持多个, 匹配任务 可以找到对应runner)
    - docker-vue
    - vue
  only:  # 限制指定分支,执行
    - test
    - master
  script:  # 执行shell命令
    - cd ${CI_PROJECT_DIR}
    - npm install
    - npm run build
  artifacts:  # 生成制品并上传, gitlab中可供下载
    paths:
      - dist/

delopy-test:
  stage: deploy
  tags:
    - docker-vue
    - vue
  only:
    - test
  script:
    - rm -rf /data/www/docker-vue-test/*
    - cp -rf ${CI_PROJECT_DIR}/dist/* /data/www/docker-vue-test

deploy-prod:     stage: deploy   tags:     - docker-vue   only:     - master   script:  # 上线执行命令, 远程同步代码     - rsync -avzH -e 'ssh -p 2222' --delete ${CI_PROJECT_DIR}/dist/ root@xx.xx.xx.xx:/opt/docker-vue/

触发时机: 每当你push/merge, gitlab-ci都会检查项目下有没有.gitlab-ci.yml文件,存在则执行里面的任务

不同push/merge所触发的CI流程不会互相影响，也就是说，你的一次push引发的CI流程并不会因为接下来另一位同事的push而阻断，它们是互不影响的。这一个特点方便让测试同学根据不同版本进行测试。

注意点:

　　1. 部署的时候 可以使用scp 将本地代码远程拷贝到云服务

因为这一命令需要输入密码，所以通过 sshpass 命令携带密码再执行scp：

sshpass -p $PASSWORD scp -r ./build $CUSTOM_USERNAME@$CUSTOM_IP:/var/www/html

这里说明一下，Gitlab有自定义变量的功能，例如我们觉得直接在YML中写入密码/账号等信息不太好，那么可以通过美元符号$写入一个预定义的变量，然后在Gitlab面板上输入它

　　当然也可以只用免密认证的方式, 这样就不需要输入密码了

重要参数:

　　cache:

用作缓存,

为什么要做缓存呢？当然是为了重复运行pipeline的时候不会重复安装全部node_modules的包，从而减少pipeline的时间，提高pipeline的性能。

但是，这并不是cache关键字唯一的功能！

在介绍cache的另外一个功能之前，我要先说一下gitlab-ci的一个优点“恶心人”的特点：

它在运行下一个Job的时候，会默认把前一个Job新增的资源删除得干干静静

没错，也就是说，我们上面bulid阶段编译生成的包，会在deploy阶段运行前被默认删除！

而cache的作用就在这里体现出来了：如果我们把bulid生产的包的路径添加到cache里面，虽然gitlab还是会删除bulid目录，但是因为在删除前我们已经重新上传了cache，并且在下个Job运行时又把cache给pull下来，那么这个时候就可以实现在下一个Job里面使用前一个Job的资源了

总而言之，cache的功能体现在两点：

• 在不同pipeline之间重用资源

• 在同一pipeline的不同Job之间重用资源

虽然cache会缓存旧的包，但我们并不用担心使用到旧的资源，因为npm install还是会如期运行，并检查package.json是否有更新，npm build的时候，生成的build资源包也会覆盖cache,并且在当前Job运行结束时，作为**"新的cache"**上传

artifacts关键字

这个关键字的作用是：将生成的资源作为pipeline运行成功的附件上传，并在gitlab交互界面上提供下载

例如我们新增以下YML

Build-job:
  stage: build
  script:
  - 'npm run build'
  artifacts:
    name: 'bundle'
    paths: 
      - build/

only/except

这两个关键字后面跟的值是tag或者分支名的列表。

故名思义

• only的作用是指定当前Job仅仅只在某些tag或者branch上触发

• 而except的作用是当前Job不在某些tag或者branch上触发

job:
  # use regexp
  only:
    - /^issue-.*$/
    - develop
    - release

allow_failure

值为true/false, 表示当前Job是否允许允许失败。

• 默认是false,也就是如果当前Job因为报错而失败，则当前pipeline停止

• 如果是true，则即使当前Job失败，pipeline也会继续运行下去。

1.  

job1:
  stage: test
  script:
    - execute_script_that_will_fail
  allow_failure: true

retry

顾名思义，指明的是当前Job的失败重试次数的上限。

但是这个值只能在0 ～2之间，也就是重试次数最多为2次，包括第一次运行在内，Job最多自动运行3次

timeout

配置超时时间，超过时间判定为失败

Job:
  script: rspec
  timeout: 3h 30m

When

表示当前Job在何种状态下运行，它可设置为3个值

• on_success: 仅当先前pipeline中的所有Job都成功（或因为已标记，被视为成功allow_failure）时才执行当前Job 。这是默认值。

• on_failure: 仅当至少一个先前阶段的Job失败时才执行当前Job。

• always: 执行当前Job，而不管先前pipeline的Job状态如何。