五分钟快速入门Gitlab持续集成功能

发表于 2019-04-09 更新于 2020-09-22 分类于研发流程

Gitlab持续集成功能介绍

1554791055072

1554791078503

Pipelines

管道是持续集成，交付和部署的上层组件。

1554812695677

管道包括：

定义要运行的作业。例如，代码编译或测试运行；
定义何时以及如何运行作业。例如，该测试仅在代码编译后运行；
如果有足够的并发Runners，则Runners并行执行同一阶段中的多个作业；

如果一个阶段的所有工作：

成功，管道进入下一阶段；
失败，下一阶段没有（通常）执行，管道提前结束；

Jobs

即管道中定义的要运行的作业。

Schedules

管道通常基于特定的某些条件触发运行。例如：将分支推送到存储库时。

而管道计划也主要用于以特定间隔运行管道。例如：

每个月22日为某个分支机构；
每天一次；

除了使用GitLab UI之外，还可以使用Pipeline schedules API维护管道计划

管道计划对于可以用来自动触发每日构建测试任务。

Charts

主要是一些管道执行的统计图表。

如何配置Pipeline

在项目根目录中新建一个.gitlab-ci.yml文件，用来配置Pipeline，例如：

stages:
  - build
  - deploy

before_script:
  - echo "Jobs运行前会执行的脚本..."

build:
  stage: build
  script:
    - mvn clean install

deploy:
  stage: deploy
  # 设为手动触发
  when: manual
  only:
    # 只有master分支才推送Jar包和同步api文档到YAPI
    - master
  script:
    - deploy xxx

具体配置文档：GitLab CI/CD Pipeline Configuration Reference

管道执行原理

1554862951221

如上图，默认的，我们推送代码之后，gitlab会请求Runner运行项目中配置的Pipeline，Runner把执行结果返回给gitlab。

GitLab Runner是开源项目,用于运行您的任务并将结果发送回GitLab。与GitLab一起使用CI（GitLab中的持续集成服务）；

其中runner可以是：ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell，在向Gitlab注册runner的时候可以指定。

具体Runner服务器配置可以参考：Configuring a Runner

示例演示

gitlab持续集成工作流

参考：Facebook代码评审机制与版本管理

如何确保代码质量？

Gitlab提供了Review Apps可以用来做版本的审查(比代码审查更有效)

Review App(审核应用)程序是一种协作工具，可以通过提供一个运行环境来展示版本的变更：

通过为合并请求启动动态环境，提供功能分支中所做更改的自动实时预览；

无需检出您的分支，即可让设计人员和产品经理查看您的更改，并在沙箱环境中运行您的分支；

与GitLab DevOps LifeCycle完全集成；

允许您随时随地部署更改；

以下是加入了Review App的分支流程协作图：

1554865226773

References

官网手把手教你配置Gitlab CI/CD功能：Getting started with GitLab CI/CD，一步一步从创建yml文件，推送代码，安装runner教你配置CI/CD。

CI/CD配置文件配置详解：GitLab CI/CD Pipeline Configuration Reference

Runner安装教程：