使用Gitlab实现monorepo多项目CICD

CI/CD是什么

CI/CD（Continuous Intergration/Continuous Delpoy），即持续集成/持续部署，或称为持续集成/持续交付，作为一套面向开发和运维团队的解决方案，CI/CD 主要解决集成新代码和向用户频繁交付应用的问题。更直接地说，就是可以解放开发人员的双手，将时间和精力专注于代码本身。

传统的前端部署往往都要经历：本地代码更新 => 本地打包项目 => 清空服务器相应目录 => 上传项目包至相应目录 几个阶段，这些都是机械重复的步骤，并且手动操作非常容易出错。对于这一过程，我们往往可以通过CI/CD 方式进行优化。

从前端的角度看，CICD的流程中涉及：

CI：代码push到托管平台之后的lint测试、单元测试
CD：将build后的项目丢到远端 Nginx 的静态资源目录下

自动化部署的好处

按照传统方式

时间成本高：手动部署占用开发时间。

沟通效率低：开发与测试间沟通频繁且易出错。

错误风险高：人为操作易导致配置错误等问题。

难以追踪：缺乏统一的日志记录和追踪。

灵活性差：难以快速响应紧急部署需求。
使用自动化部署

节省时间：自动完成部署流程，提升开发效率。

提高沟通效率：实时共享部署状态，减少沟通成本。

减少错误：降低人为错误，提高部署稳定性。

增强代码质量：集成代码检查，确保代码质量。

提高灵活性：快速响应代码变更和紧急部署。

增强可追溯性：记录详细日志，便于问题追踪。

支持CI/CD：加速产品迭代和交付。

构建/部署

说的简单点，就是先利用 webpack 或者 gulp 这类的工具把工程打包，然后把打包得到的文件放在服务器上某个托管静态资源的 Web 容器里，像 Java 就可以放在 Tomcat，不过现在流行用 Nginx 托管静态资源。有了 Web 容器，前端打包的那些文件（比如index.html, main.js等等）就可以被访问到了。

手动档

1、本地执行 npm run build构建项目

2、使用 FileZilla 或其他支持 sftp 的软件上传打包后的项目（当然也有其他方式）

3、修改 Nginx 的 nginx.conf 文件，配置项目的访问路径

手动部署操作起来很简单，但缺点也很明显，每次构建完都要人为地进行部署的动作，一方面减少了实际敲代码的时间，另一方面，人工操作免不了会有疏忽出错的时候。

半自动挡

1、本地配置好脚本

2、使用 package.json 中配置的命令执行

3、等待自动打包上传流程结束

虽然这样的操作也很方便且不易出错，但每次都要等待代码打包上传完了才能下机，还是挺浪费时间的。

自动挡

随着工程化 的发展和工具链 的成熟，项目部署不再像以前简单粗暴。前端代码的健壮性 、可靠性 越来越被重视，项目发布前往往需要 代码约束 和 代码测试 ，校验通过后服务器拉取最新的代码，进行 build 和 nginx 配置后才算完成整个部署的过程。

1、代码扫描 npm run lint检查代码是否规范

2、npm run unit进行单元测试

3、git push提交更改到远端仓库

4、登录服务器，git pull拉取最新代码

5、npm run build构建项目

6、配置 nginx 访问路径

6、配置 nginx 访问路径这个阶段，我们借助一些工具，能够减少代码不规范或隐藏bug的问题。

但所有的操作还是得一行一行命令去敲，项目真正的部署也还是需要手动去操作服务器。也可以将上面的操作细节都集成到一个 shell 脚本里，通知执行 shell 也能减少很多重复的工作。

CI/CD 做了什么

一个版本发布的过程主要分为以下几个步骤：

代码合并：测试环境或生产环境都有独立的分支，等所有待发版的代码都合并到对应分支后，就可以考虑发版了。
打包：或者叫构建。以生产环境部署为例，我们切到生产环境分支并 pull 最新代码后，就可以开始打包步骤了。这一步主要是通过一些 bundler 完成的，比如 webpack。而打包命令一般都是定义在package.json的scripts中了，比如定义的命令是build:prod，那么只要运行npm run build:prod就行了。
部署：把打包得到的文件放在 web 容器中，而 web 容器通常在 Linux 服务器上，这涉及到远程传输文件，这个时候我们一般要借助 shell 脚本或者 xftp。

而 CI/CD 做的事情就是：用自动化技术接管流程。

核心工具

GitLab Runner

GitLab Runner是配合GitLab CI/CD完成工作的核心程序，出于性能考虑，GitLab Runner应该与Gitlab部署在不同的服务器上（Gitlab在单独的仓库服务器上，GitLab Runner在部署web应用的服务器上）。GitLab Runner在与GitLab关联后，可以在服务器上完成诸如项目拉取、文件打包、资源复制等各种命令操作。

Git

web服务器上需要安装Git来进行远程仓库的获取工作。

Node

用于在web服务器上完成打包工作。

NPM or Yarn or pnpm

用于在web服务器上完成依赖下载等工作（用yarn,pnpm亦可）。

Gitlab CI/CD是如何工作的

从 GitLab 8.0 开始，GitLab CI 就已经集成在 GitLab 中，我们只要在项目中添加一个 .gitlab-ci.yml 文件，然后添加一个 Runner，即可进行持续集成。而且随着 GitLab 的升级，GitLab CI 变得越来越强大。

Pipeline

Pipeline 是 CI/CD 的最上层组件 ，它翻译过来是管道，也可理解为流水线 ，每一个符合.gitlab-ci.yml触发规则的 CI/CD 任务都会产生一个 Pipeline。这个概念有点像工厂中的车间流水线，我们知道车间中有很多条流水线，不同的流水线可能会处理同一类型的生产任务，也可能处理不同类型的生产任务。当一条流水线空闲的时候，就有可能会被用来安排执行其他的生产任务。而 Gitlab 的 Pipeline 虽然没有空闲的概念，一个 Pipeline 执行结束后也不会被复用，但是会将资源让出来给其他的 Pipeline，所以和车间流水线也有异曲同工之妙。

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

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

Stages

Stages 表示构建阶段，其实就是上面提到的流程。我们可以在一次 Pipeline 中定义多个 Stages，每个Stage可以完成不同的任务。一个 Pipeline 有若干个stage，每个 stage 上有至少一个 Job。Stages 有下面的特点：

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

Jobs

Jobs 表示构建工作，就是某个 Stage 里面执行的工作。Job是pipeline的任务节点，它构成了pipeline的基本单元。 我们可以在 Stages 里面定义多个 Jobs，**每个Job都会配置一个stage属性，表示这个Job所处的阶段。**Jobs 有以下特点：

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

Runner

有了流水线，还必须有辛勤的工人进行生产作业，Runner 在 Gitlab Pipeline 中就扮演着工人角色，根据我们下达的指令进行作业。

它是脚本执行的承载者，.gitlab-ci.yml 的 script 部分的运行就是由 Runner 来负责的。GitLab-CI 浏览过项目里的 .gitlab-ci.yml 文件之后，根据里面的规则，分配到各个 Runner 来运行相应的脚本 script。这些脚本有的是测试项目用的，有的是部署用的。

Runner的类型

在 Gitlab 中，Runner 有很多种，分为 Shared Runner , Group Runner , Specific Runner。

Shared Runner 是所有项目都可以使用的，可以理解为机动人员，他可能会在工厂的各个流水线机动作业，随时支援！在整个 Gitlab 应用中，可以服务于各个 Project。使用受运行时间的限制。
Specific Runner 只服务于指定的项目，也就是 Project 级别，别的项目咱都不去。使用完全自由。
Group Runner 就比较好理解了，他只在这个组上班，别的组他是不会去的。在 Gitlab 中，我们是可以建立不同的 Group 的，比如前端一个 Group，后端一个 Group，甚至前端里面还可以分 N 个 Group。所以，Group Runner 只服务于指定的 Group。

注册Runner

工人是要持证上岗的，同样，Runner 有一个注册的过程，就相当于在工厂中入职登记的意思。具体见 Registering Runners。只有合法注册的 Runner，才有资格执行 Pipeline。

.gitlab-ci.yml

流水线和工人都安排好之后，就必须制定车间生产规章制度 了，一条流水线到底怎么干活，总要有个规矩。而.gitlab-ci.yml文件就是用来制定规则的！它是流水线执行的流程文件，Runner 会据此完成规定的一系列流程，保存并推送至 gitlab 后即可自动开始构建部署，构建中可在 gitlab CI/CD 面板查看构建进程。

.gitlab-ci.yml 是在 git 项目的根目录下的一个文件，记录了一系列的阶段和执行规则。GitLab-CI 在 push 后会解析它，根据里面的内容调用 Runner 来运行。简单来讲，就是当我们 push 了本地代码到 Remote 上(这里就是 gitlab.com)，然后 Gitlab就通知服务器，即 Gitlab-Runner 来运行构建任务。然后跑测试用例，测试用例通过了就 build 出相应的环境的代码，自动部署到不同的环境服务器上面去。

配置好 Runner 后，我们要做的事情就是在项目根目录中添加 .gitlab-ci.yml 文件了，可以控制 CI 流程的不同阶段 ，例如install/检查/编译/部署服务器，gitlab 平台会扫描.gitlab-ci.yml文件，并据此处理ci流程。当我们添加了 .gitlab-ci.yml 文件后，每次提交代码或合并 MR 都会自动运行构建任务了。

CI 流程在每次 push/merge 之后触发，每当 push/merge 一次，gitlab-ci 都会检查项目下有没有 .gitlab-ci.yml 文件，如果有，它会执行里面编写的脚本，并完整地走一遍从 intall => eslint检查 => 编译 => 部署服务器 的流程。

变量 Variables

Gitlab 通过 Variables 为 CI/CD 提供了更多配置化的能力，方便我们快速取得一些关键信息，用来做流程决策。上述示例中的$CI_COMMIT_REF_NAME和$CI_PROJECT_DIR就是 Gitlab 的预定义变量。

除了预定义变量，我们也可以自行定义一些环境变量，比如服务器 ip，用户名等等，这样就免去了在配置文件中明文列出私密信息的风险；另一方面也方便后期快速调整配置，避免直接修改.gitlab-ci.yml。

授信问题

在不同主机间通过scp传输文件需要建立信任关系，在 CI/CD 中最好选择免密方式，其基本原理就是把 ssh公钥 交给对方。

在 GitLab 的 CI/CD 流程中，使用 scp 或任何基于 SSH 的命令来在不同的主机之间传输文件时，需要建立一种安全的免密登录方式。这通常通过 SSH 密钥认证来实现，即将一个 SSH 公钥添加到远程服务器的 ~/.ssh/authorized_keys 文件中，这样持有相应私钥的用户就可以无密码登录该服务器了。

使用Gitlab实现多项目CICD

背景

有一个 monorepo 微前端项目，需要一次构建3个项目，放在根目录下的packages文件夹下，分别是rdm、rdm-old、rdm-new，在测试分支打包，分别生成自己的 dist/test，正式服则是 dist/prod，正式服构建到 A 服务器的 rdm、rdm-old、rdm-new 文件夹，测试服到 B 服务器的 rdm、rdm-old、rdm-new 文件夹。现在，我们希望在一次CI/CD流程中构建并部署多个子应用（rdm, rdm-new, rdm-old），同时这些应用需要被部署到不同服务器上的不同的 FTP 目录。

用直观的方式呈现如下图：

方案

为了实现这个需求，我们可以在.gitlab-ci.yml文件中设置一个共同的构建阶段，然后针对不同的环境（测试服和正式服）和不同的子应用设置不同的部署阶段。

bash 复制代码

# 定义CI/CD的阶段 
stages:  
  - build   # 构建阶段 
  - deploy  # 部署阶段  
  
# 定义一些全局变量，用于SSH连接和部署  
variables:  
  SSH_USER: "用户名"  
  SSH_PASSWORD: "用户密码"  
  SSH_OPTIONS: "-o StrictHostKeyChecking=no"  
  
# 定义一个模板，用于SSH部署  
.deploy_template: &deploy_template  
  stage: deploy  
  script:  
    - echo "Deploying to $TARGET_SERVER in $DEPLOY_PATH"  
    - sshpass -p "$SSH_PASSWORD" ssh $SSH_USER@$TARGET_SERVER "mkdir -p $DEPLOY_PATH"  
    - sshpass -p "$SSH_PASSWORD" scp -r $SSH_OPTIONS ./dist/$DEPLOY_TYPE/* $SSH_USER@$TARGET_SERVER:$DEPLOY_PATH  
  

# RDM 构建和部署  
rdm-build:  
  stage: build  
  script:   # 构建脚本
    - cd packages/rdm  
    - pnpm install  
    - pnpm run build:$CI_COMMIT_REF_NAME  # 假设你有一个脚本来根据分支构建到不同的目录  
    - |  # 使用管道符来在单行中写多条命令,如果是主分支,将dist目录重命名为dist/prod    
      if [ "$CI_COMMIT_REF_NAME" == "main" ]; then  
        mv dist dist/prod   
      else  
        mv dist dist/test  
      fi  
  artifacts:  # 指定要保留的构建产物 
    paths:  
      - packages/rdm/dist/prod/  # 如果需要包含主分支的产出  
      - packages/rdm/dist/test/  # 如果需要包含非主分支的产出  
  
rdm-deploy-prod:  
  <<: *deploy_template  
  variables:  # 覆盖模板中的变量 
    TARGET_SERVER: "正式服-服务器 A 地址"  
    DEPLOY_PATH: "/rdm"   # 部署路径  
    DEPLOY_TYPE: "prod"   # 部署类型
  only:   # 仅当提交到prod分支时运行
    - prod  
  
rdm-deploy-test:  
  <<: *deploy_template  
  variables:  
    TARGET_SERVER: "测试服-服务器 B 地址"   
    DEPLOY_PATH: "/rdm"  
    DEPLOY_TYPE: "test"  
  except:  
    - main  


# RDM-OLD  
rdm-old-build:  
  stage: build  
  script:  
    - cd packages/rdm-old  
    - pnpm install  
    - pnpm run build:$CI_COMMIT_REF_NAME  # 假设你有一个脚本来根据分支构建到不同的目录  
    - |  # 使用管道符来在单行中写多条命令  
      if [ "$CI_COMMIT_REF_NAME" == "main" ]; then  
        mv dist dist/prod  
      else  
        mv dist dist/test  
      fi  
  artifacts:  
    paths:  
      - packages/rdm-old/dist/prod/  # 如果需要包含主分支的产出  
      - packages/rdm-old/dist/test/  # 如果需要包含非主分支的产出  
  
rdm-old-deploy-prod:  
  <<: *deploy_template  
  variables:  
    TARGET_SERVER: "正式服-服务器 A 地址"  
    DEPLOY_PATH: "/rdm-old"  
    DEPLOY_TYPE: "prod"  
  only:  
    - prod  
  
rdm-old-deploy-test:  
  <<: *deploy_template  
  variables:  
    TARGET_SERVER: "测试服-服务器 B 地址"  
    DEPLOY_PATH: "/rdm-old"  
    DEPLOY_TYPE: "test"  
  except:  
    - main  
  

# RDM-NEW  
rdm-new-build:  
  stage: build  
  script:  
    - cd packages/rdm-new  
    - pnpm install  
    - pnpm run build:$CI_COMMIT_REF_NAME  # 假设这个脚本会根据分支名称构建到不同的目录，但实际上它不会改变dist的目录名  
    - |  # 使用管道符来在单行中写多条命令  
      if [ "$CI_COMMIT_REF_NAME" == "main" ]; then  
        mv dist dist/prod  
      else  
        mv dist dist/test  
      fi  
  artifacts:  
    paths:  
      - packages/rdm-new/dist/prod/  # 如果需要包含主分支的产出  
      - packages/rdm-new/dist/test/  # 如果需要包含非主分支的产出  
  
rdm-new-deploy-prod:  
  <<: *deploy_template  
  variables:  
    TARGET_SERVER: "正式服-服务器 A 地址" 
    DEPLOY_PATH: "/rdm-new"  
    DEPLOY_TYPE: "prod"  
  only:  
    - prod 
  
rdm-new-deploy-test:  
  <<: *deploy_template  
  variables:  
    TARGET_SERVER: "测试服-服务器 B 地址"  
    DEPLOY_PATH: "/rdm-new"  
    DEPLOY_TYPE: "test"  
  except:  
    - main

参考资料：

Tutorial: Create and run your first GitLab CI/CD pipeline | GitLab

🛫 前端自动化部署：借助Gitlab CI/CD实现 - 掘金 (juejin.cn)

前端的gitlab的ci初尝试 - 掘金 (juejin.cn)

花半天时间，轻松打造前端CI/CD工作流 - 掘金 (juejin.cn)