laiyuquan

博客

Gitlab-CI/CD 持续集成

2018-04-09 0条评论 1,652次阅读 0人点赞

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的手册；（国外人写的说明还是非常详细的！）

 

 

点赞

发表评论