laiyuquan

博客

Gitlab-CI/CD 持续集成

Gitlab CI/CD:  Gitlab 提供了 continuous integration (含自动化 构建、测试、部署)的服务。

本地服务器 ==》 gitlab 服务器 :通过git push 进行操作;

本地服务器 ==》线上服务器 : 之前都是tcp 或者直接用scp 、sync 远程同步文件;

设想一下:如果本地push代码到 gitlab服务器时 也能自动部署到 线上服务器(甚至完成 构建,

单元测试等功能)那就非常方便了。。。

解决:Gitlab CI 就是在本地commit or push时 自动化执行 gitlab runner , 可以直接将代码

部署到线上服务器(顺便完成构建 单元化测试…);


概念理解

.gitlab-ci.yml

官方定义:The .gitlab-ci.yml file is where you configure what CI does with your project.It lives in the root of your repository

三个要点:1、位于应用项目根目录下   2、加在版本控制中   3、该文件定义ci 具体执行的代码

GitLab-Runner

gitlab ci 脚本的执行者,关系理解如下图:

《Gitlab-CI/CD 持续集成》

Pipeline
一次 Pipeline 其实相当于一次构建任务,里面可以包含多个流程,如安装依赖、运行测试、编译、

部署测试服务器、部署生产服务器等流程。

任何提交或者 Merge Request 的合并都可以触发 Pipeline,如下图所示:

《Gitlab-CI/CD 持续集成》
Stages
Stages 表示构建阶段,一次 Pipeline 中定义多个 Stages。

  • 所有 Stages 会按照顺序运行,即当一个 Stage 完成后,下一个 Stage 才会开始
  • 只有当所有 Stages 完成后,该构建任务 (Pipeline) 才会成功
  • 如果任何一个 Stage 失败,那么后面的 Stages 不会执行,该构建任务 (Pipeline) 失败

《Gitlab-CI/CD 持续集成》

Jobs
Jobs 表示构建工作,表示某个 Stage 里面执行的工作。一个Stages 里面定义多个 Jobs, Jobs 会有以下特点:

  • 相同 Stage 中的 Jobs 会并行执行
  • 相同 Stage 中的 Jobs 都执行成功时,该 Stage 才会成功
  • 如果任何一个 Job 失败,那么该 Stage 失败,即该构建任务 (Pipeline) 失败

《Gitlab-CI/CD 持续集成》

 

理解这些概念有助于你对 gitlab 整体的理解,当然最好的方式就是将官方文档仔细读一遍:

网址:https://gitlab.com/help/ci/quick_start/README


安装Gitlab-Runner

$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash
$ sudo apt-get install gitlab-ci-multi-runner

 

注册 Runner

安装好以后就是注册Runner,就是让Runner 和 你的Gitlab服务进行绑定,你的服务器 和 Gitlab服务就能相关管理了

  • 运行 sudo gitlab-ci-multi-runner register
  • 输入 CI URL ;                   https://gitlab.com/
  • 输入 Token ;                     setting->CI/CD->Runners settings
  • 输入 Runner 的名字;        随便起
  • 输入tag shell,web,deploy
  • 选择是否untagged,          选择是true,方便测试
  • 其他默认;                           就ok
  • 选择 Runner 的类型;       简单起见还是选 Shell 吧
当注册好 Runner 之后,可以用 sudo gitlab-ci-multi-runner list 命令来查看各个 Runner 的状态

编写.gitlab-ci.yml

before_script:
- whoami

stages:
  - deploy
deploy:
    stage: deploy
    environment:
        name: test
    script:

      - /var/www/composer/vendor/bin/envoy run list

    only:
      - master
    tags:
      - shell

 

原理就是:每次commit 或者 合并代码时,然后push到gitlab时,gitlab通过检测 .gitlab-ci.yml 触发执行里面的脚步; 这里最关键的执行脚步就是:Envoy  run list,这个其实套用了 Envoy 实现远程代码方式,只是这里用本地 去拉取gitlab上的代码,@server改成本地执行就成 @servers(['localhost' => '127.0.0.1'])  ;

 

这样的做法有一个弊端:就是初始化上传代码时 远程并没有 Envoy.blade.php 文件 执行不了?

解决:实际上的做法是:

· Envoy 文件 会提前先放入服务器;

· 先本地执行远程Envoy,后续每次都gitlab-ci 自动执行;

· 自己新建的一个shell 脚本,用来拉取代码(本质上跟第一种类似);

 

关于.gitlab-ci.yml 里面具体的语法,参考手册:https://gitlab.com/help/ci/yaml/README.md


 

Gitlab CI/CD 还是非常博大精深,如果想要深入了解,还是多看gitlab的手册;(国外人写的说明还是非常详细的!)

 

 

点赞

发表评论