【gitlab】认识 持续集成与部署

持续集成（CI）与持续部署（CD）

1. 什么是持续集成（CI）？

持续集成（Continuous Integration，CI）是一种软件开发实践，强调开发人员频繁地将代码提交到共享代码库，并通过自动化构建和测试快速反馈问题。

CI 的关键特性

2. 什么是持续部署（CD）？

持续部署（Continuous Deployment，CD）是将构建后的制品自动部署到不同环境（测试、预生产、生产）的过程。它的目标是让开发的功能尽快交付给用户。

CD 的关键特性

3. 为什么要使用 CI/CD？

CI/CD 提供了一套高效的软件交付方式，带来了多种优势：

• 加快产品研发进程：减少手动构建和部署的时间。
• 更早发现问题：频繁集成和测试，避免大版本合并时的冲突。
• 降低人为错误：自动化流程减少手动干预，提高稳定性。
• 提高团队协同效率：产品、开发、测试、运维团队更高效协作。
• 更专注于业务逻辑：减少开发人员在集成和部署上的额外工作。

4. CI/CD 存在的问题

尽管 CI/CD 有诸多优点，但在落地时可能面临以下挑战：

5. 三种常见的发布策略

CI/CD 体系下，有三种常见的发布策略，分别是蓝绿发布、A/B 测试和金丝雀发布。

5.1 蓝绿发布（Blue-Green Deployment）

• 思路：将服务集群分为两组（蓝色和绿色），新版本在一组部署后，切换流量至该组，旧版本作为热备。
• 优点：
  • 结构简单，部署方便。
  • 切换和回滚速度快，影响面小。
• 缺点：
  • 需要双倍资源，以支持两个版本的运行。
  • 如果新版本故障，仍可能影响全部用户。

5.2 A/B 测试（A/B Testing）

• 思路：根据 HTTP 头部或 Cookie，将部分用户流量定向到新版本，观察效果后再决定全量发布。
• 优点：
  • 影响范围可控。
  • 适合 UI/UX 变更的逐步测试。
• 缺点：
  • 需要流量监控和用户行为分析能力。
  • 发布周期较长。

5.3 金丝雀发布（Canary Deployment）

• 思路：最初只让少部分用户使用新版本，逐步增加流量，最终完全替换旧版本。
• 优点：
  • 资源利用率高。
  • 风险最小，新版本故障影响范围小。
• 缺点：
  • 发布周期长。
  • 可能会影响关键用户。

6. 基于 GitLab 的持续集成案例

以下是一个基于 GitLab 的持续集成（CI）案例详解

案例背景

假设你有一个简单的 Node.js Web 项目，项目结构如下：

my-web-app/
  ├── src/
  │   └── index.js
  ├── test/
  │   └── index.test.js
  ├── package.json
  └── .gitlab-ci.yml

目标：通过 GitLab CI/CD 实现自动化测试、构建和部署。

一、GitLab CI 基础知识

1. 核心概念：

   • Pipeline：一次 CI/CD 流程的完整过程。
   • Stage：Pipeline 的阶段（如 test, build, deploy）。
   • Job：每个阶段中的具体任务（如运行测试、打包代码）。

2. 配置文件：.gitlab-ci.yml
   定义 CI/CD 流程的规则，需放在项目根目录。

二、配置持续集成流程

步骤 1：创建 .gitlab-ci.yml 文件

# 定义 Pipeline 的阶段（按顺序执行）
stages:
  - test
  - build
  - deploy

# 定义缓存 node_modules 加速后续流程
cache:
  paths:
    - node_modules/

# 定义全局环境变量
variables:
  NODE_VERSION: "18"

# 1. 测试阶段
test_job:
  stage: test
  image: node:$NODE_VERSION  # 使用 Node.js 官方镜像
  before_script:
    - npm install  # 安装依赖
  script:
    - npm test     # 运行测试

# 2. 构建阶段
build_job:
  stage: build
  image: node:$NODE_VERSION
  script:
    - npm run build  # 假设 package.json 中有 build 脚本
  artifacts:
    paths:
      - dist/       # 将构建产物传递给后续阶段

# 3. 部署阶段（示例：部署到 GitLab Pages）
deploy_job:
  stage: deploy
  image: alpine:latest
  script:
    - echo "将 dist/ 目录部署到 GitLab Pages..."
    - mv dist/ public/  # GitLab Pages 默认从 public 目录部署
  rules:
    - if: $CI_COMMIT_BRANCH == "main"  # 仅 main 分支触发部署

步骤 2：配置 GitLab Runner

1. 什么是 Runner：
   一个执行 CI/CD 任务的程序，需注册到 GitLab 项目。

2. 如何配置：

   • 进入 GitLab 项目 → Settings → CI/CD → Runners。
   • 选择 Shared Runner（GitLab 提供）或手动安装 Specific Runner。
   • 本地安装 Runner 示例（需服务器或本地机器）：

     # 下载 Runner 并安装
     curl -LJO "https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_amd64.deb"
     sudo dpkg -i gitlab-runner_amd64.deb
     
     # 注册 Runner（按提示填写 GitLab URL 和 Token）
     sudo gitlab-runner register
     

步骤 3：触发 Pipeline

1. 将代码推送到 GitLab 仓库。
2. 进入 GitLab 项目 → CI/CD → Pipelines，查看运行状态。
3. 点击 Jobs 可查看详细日志。

三、流程详解

1. 测试阶段：

   • 使用 Node.js 镜像安装依赖并运行测试。
   • 若测试失败，Pipeline 终止并通知。

2. 构建阶段：

   • 生成静态文件（如 dist/ 目录）。
   • artifacts 将产物传递给后续阶段。

3. 部署阶段：

   • 仅当提交到 main 分支时触发。
   • 将 dist/ 重命名为 public/，自动部署到 GitLab Pages。

四、优化与注意事项

1. 缓存依赖：

   cache:
     key: ${CI_COMMIT_REF_SLUG}  # 按分支缓存
     paths:
       - node_modules/
   

2. 环境变量管理：
   敏感信息（如 API 密钥）应在 GitLab 项目 → Settings → CI/CD → Variables 中配置。

3. 仅针对特定分支：

   job_name:
     rules:
       - if: $CI_COMMIT_BRANCH == "main"
   

4. 手动部署：

   deploy_job:
     when: manual  # 手动点击触发
   

https://github.com/0voice