持续集成（CI）与持续部署（CD）
1. 什么是持续集成（CI）？
持续集成（Continuous Integration，CI）是一种软件开发实践，强调开发人员频繁地将代码提交到共享代码库，并通过自动化构建和测试快速反馈问题。
CI 的关键特性
| 特性 | 说明 |
|---|---|
| 代码频繁提交 | 确保集成的代码及时合并，减少冲突。 |
| 自动化构建 | 每次代码提交触发构建，确保代码能正确编译。 |
| 自动化测试 | 运行单元测试、代码规范扫描等，保证质量。 |
| 快速反馈 | 及时发现错误，尽早修复，提高团队协作效率。 |
2. 什么是持续部署（CD）？
持续部署（Continuous Deployment，CD）是将构建后的制品自动部署到不同环境（测试、预生产、生产）的过程。它的目标是让开发的功能尽快交付给用户。
CD 的关键特性
| 特性 | 说明 |
|---|---|
| 自动化部署 | 代码通过 CI 流程后，自动化推送到部署环境。 |
| 版本管理 | 明确版本控制，支持回滚。 |
| 快速反馈 | 让测试和运维团队尽早介入，降低风险。 |
| 最终用户可见 | 生产环境部署后，用户可以直接使用新功能。 |
3. 为什么要使用 CI/CD？
CI/CD 提供了一套高效的软件交付方式，带来了多种优势：
- 加快产品研发进程：减少手动构建和部署的时间。
- 更早发现问题：频繁集成和测试，避免大版本合并时的冲突。
- 降低人为错误：自动化流程减少手动干预，提高稳定性。
- 提高团队协同效率：产品、开发、测试、运维团队更高效协作。
- 更专注于业务逻辑：减少开发人员在集成和部署上的额外工作。
4. CI/CD 存在的问题
尽管 CI/CD 有诸多优点，但在落地时可能面临以下挑战：
| 问题 | 说明 |
|---|---|
| 需要一定技术门槛 | 需要有 CI/CD 经验的团队支持。 |
| 不是所有测试都能自动化 | 例如 UI 测试、部分人工测试仍需手动干预。 |
| 需要良好的协作 | 开发、测试、运维需要明确职责，避免影响彼此流程。 |
| 需要较长时间实践 | 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 基础知识
-
核心概念：
- Pipeline：一次 CI/CD 流程的完整过程。
- Stage：Pipeline 的阶段（如
test,build,deploy）。 - Job：每个阶段中的具体任务（如运行测试、打包代码）。
-
配置文件：
.gitlab-ci.yml
定义 CI/CD 流程的规则，需放在项目根目录。
二、配置持续集成流程
gitlabciyml__110">步骤 1：创建 .gitlab-ci.yml 文件
# 定义 Pipeline 的阶段（按顺序执行）
stages:- test- build- deploy# 定义缓存 node_modules 加速后续流程
cache:paths:- node_modules/# 定义全局环境变量
variables:NODE_VERSION: "18"# 1. 测试阶段
test_job:stage: testimage: node:$NODE_VERSION # 使用 Node.js 官方镜像before_script:- npm install # 安装依赖script:- npm test # 运行测试# 2. 构建阶段
build_job:stage: buildimage: node:$NODE_VERSIONscript:- npm run build # 假设 package.json 中有 build 脚本artifacts:paths:- dist/ # 将构建产物传递给后续阶段# 3. 部署阶段（示例：部署到 GitLab Pages）
deploy_job:stage: deployimage: alpine:latestscript:- echo "将 dist/ 目录部署到 GitLab Pages..."- mv dist/ public/ # GitLab Pages 默认从 public 目录部署rules:- if: $CI_COMMIT_BRANCH == "main" # 仅 main 分支触发部署
步骤 2：配置 GitLab Runner
-
什么是 Runner：
一个执行 CI/CD 任务的程序，需注册到 GitLab 项目。 -
如何配置：
- 进入 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
- 将代码推送到 GitLab 仓库。
- 进入 GitLab 项目 → CI/CD → Pipelines，查看运行状态。
- 点击 Jobs 可查看详细日志。
三、流程详解
-
测试阶段：
- 使用 Node.js 镜像安装依赖并运行测试。
- 若测试失败，Pipeline 终止并通知。
-
构建阶段：
- 生成静态文件（如
dist/目录）。 artifacts将产物传递给后续阶段。
- 生成静态文件（如
-
部署阶段：
- 仅当提交到
main分支时触发。 - 将
dist/重命名为public/，自动部署到 GitLab Pages。
- 仅当提交到
四、优化与注意事项
-
缓存依赖：
cache:key: ${CI_COMMIT_REF_SLUG} # 按分支缓存paths:- node_modules/ -
环境变量管理：
敏感信息（如 API 密钥）应在 GitLab 项目 → Settings → CI/CD → Variables 中配置。 -
仅针对特定分支：
job_name:rules:- if: $CI_COMMIT_BRANCH == "main" -
手动部署：
deploy_job:when: manual # 手动点击触发
https://github.com/0voice
