GitLab CI/CD 实践

XingChao
2,071 阅读5分钟

image.png

日常开发中，我们经常使用 GitLab 进行项目管理，但是对于一些自动化流程，可能只是了解一部分，对整体的流程缺乏认识，所以决定梳理一下。

  • 为什么要做CI/CD
  • GitLab CI/CD 介绍
  • GitLab Runner
  • 实践 GitLab CI/CD

为什么要做CI/CD

传统应用发布模式

image.png

开发团队 在开发环境中完成软件开发，自测，测试通过，提交到代码版本管理库。

运维/服务团队 把应用部署到测试环境，供测试团队测试，测试通过后部署生产环境。

测试团队 进行测试，测试通过后通知部署人员发布到生产环境。

存在问题

  • 错误发现不及时  很多 错误在项目的早期可能就存在，到最后集成的时候才发现问题。
  • 人工低级错误发生 产品和服务交付中的关键活动全都需要手动操作。
  • 团队工作效率低 需要等待他人的工作完成后才能进行自己的工作。
  • 开发与运维   开发人员想要快速更新，服务/运维人员追求稳定，各自的针对的方向不同。

持续集成与持续交付

持续集成 Continuous Integration（CI）

  • 持续合并开发人员正在开发编写的所有代码的一种做法
  • 通常一天内进行多次合并和提交代码
  • 从存储库或生产环境中进行构建和自动化测试，以确保没有集成问题并及早发现任何问题

持续交付 Continuous Delivery（CD）

  • 超越持续集成的一步
  • 不仅会在推送到代码库的每次代码更改时都进行构建和测试，而且，作为附加步骤，即使部署是手动触发的，它也可以连续部署
  • 此方法可确保自动检查代码，但需要人工干预才能从策略上手动触发更改的部署

持续部署Continuous Deployment（CD）

  • 通常可以通过将更改自动推送到发布系统来随时将软件发布到生产环境中
  • 持续部署 会更进一步，并自动将更改推送到生产中
  • 与持续交付类似，但不同之处在于，你无需将其手动部署，而是将其设置为自动部署。完全不需要人工干预即可部署你的应用程序

CI/CD的价值体现

  • 尽早反馈，尽早发现错误。
  • 减少集成问题，每次发现问题当时解决，避免问题堆积。
  • 每次更改都能成功发布，降低发布风险。
  • 更加频繁的交付价值，客户反馈。

常用的CI/CD工具

  • Jenkins
  • GitLab

GitLab CI/CD 介绍

GitLab CI/CD 是一个内置在GitLab中的工具，用于通过持续方法进行软件开发我们只要在项目根目录中添加一个.gitlab-ci.yml文件，然后添加一个 Runner，即可进行持续集成。

基本概念

Pipeline

一次 Pipeline 其实相当于一次构建任务，里面可以包含多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。 任何提交或者 Merge Request 的合并都可以触发 Pipeline

image.png 如图所示：提交 develop/master 分支，均会触发Pipeline

Stages

Stages 表示构建阶段，说白了就是上面提到的流程。 我们可以在一次 Pipeline 中定义多个 Stages，这些 Stages 会有以下特点：

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

image.png 示例-.gitlab-ci.yml 文件 Stages

Jobs

Jobs 表示构建工作，表示某个 Stage 里面执行的工作。 我们可以在 Stages 里面定义多个 Jobs，这些 Jobs 会有以下特点：

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

image.png

最后，如果出现任何问题，可以轻松地回滚所有更改

GitLab Runner

理解了上面的基本概念之后，有没有觉得少了些什么东西 —— 由谁来执行这些构建任务呢？ 答案就是 GitLab Runner 了，GitLab Runner 用来运行 Pipeline 构建任务的进程

Gitlab 采用的是 构建任务 和 执行构建任务 Runner 分离的架构

这么做的好处是：

  • 分工明确：GitLab 负责管理构建状态，GitLab Runner 执行构建任务
  • 运行构建任务会消耗系统资源，所以将 Runner 拆分，提高 GitLab 性能

GitLab CI 最大的作用是管理各个项目的构建状态，因此，运行构建任务这种浪费资源的事情就交给 GitLab Runner 来做。 因为 GitLab Runner 可以安装到不同的机器上，所以在构建任务运行期间并不会影响到 GitLab 的性能

image.png

GitLab Runner 类型

  • shared ： 运行整个平台项目的作业（gitlab）
  • group： 运行特定group下的所有项目的作业（group）
  • specific: 运行指定的项目作业（project）
  • locked： 锁定runner到当前项目，当运行程序被锁定时，它不能分配给其他项目
  • paused： 不会运行作业

实践 GitLab CI/CD

应用场景：假设一个应用场景，我们需要开发一个页面组件，开发完成后推送develop 分支，在测试环境构建并推送至测试服务器。合并 master 分支，自动构建，并推送至正式服务器

... 组件开发过程忽略，编写.gitlab-ci.yml文件

variables:
  BASE_DIR_PATH: 'base'
  CONTAINER_NAME: '${CI_PROJECT_NAMESPACE}-${CI_PROJECT_NAME}'

# 基础镜像, 包含 upload 工具包, 内部原理，使用 sftp 实现文件上传至服务器
image: docker-registry.xxx.com/node:1.0.0 

before_script:
  - echo $CONTAINER_NAME
  - echo "ready to start! " $(date +'%Y-%m-%d %H:%M:%S')
  - pwd
  - npm install

stages:
  - deploy_fat
  - deploy_pro

# 测试环境
deploy_fat:
  stage: deploy_fat
  tags:
    - docker
    - build
  only:
    - develop
  script:
    - npm run build
    - upload online ${BASE_DIR_PATH}/${CI_PROJECT_NAMESPACE}/${CI_PROJECT_NAME}/dev

# 正式环境
deploy_pro:
  stage: deploy_pro
  tags:
    - docker
    - build
  only:
    - master
  script:
    - echo $CI_JOB_STAGE
    - echo ${BASE_DIR_PATH}
    - npm run build
    - upload online ${BASE_DIR_PATH}/${CI_PROJECT_NAMESPACE}/${CI_PROJECT_NAME}/master

提交Git仓库，合并 develop 分支，自动触发构建

image.png

至此，GitLab CI/CD 实践流程结束。

作为对梳理整体的Gitlab-CI/CD 流程的总结，部分信息脱敏处理，见谅！

参考资料

gitlab-ci 详解

GitLab Runner 安装及注册过程请参考

推荐

Gitlab CICD自动构建- .gitlab-ci.yml详细配置解读

avatar
文章
阅读
粉丝