CI/CD 流程：构建、测试、部署

CI/CD（持续集成/持续部署）的核心在于将繁琐的人工操作转化为自动化的脚本执行。通过标准化的流程，开发者提交代码后，系统自动完成一系列检查和发布工作。以下是基于通用 Web 项目（以 Node.js 为例）的实操指南。

第一阶段：持续集成与构建

构建阶段的目标是将源代码转换为可运行的产物，并确保基础环境的一致性。

1. 初始化项目仓库。
   在项目根目录下创建一个名为 .gitlab-ci.yml 或 Jenkinsfile 的配置文件，用于定义整个流水线的逻辑。

2. 定义构建脚本。
   在配置文件中指定构建阶段所需的运行环境。使用 Docker 镜像可以保证环境隔离，避免“在我机器上能跑”的问题。

   编写如下基础配置代码：

   stages:
     - build
     - test
     - deploy
   
   build_job:
     stage: build
     image: node:16
     script:
       - npm install
       - npm run build
     artifacts:
       paths:
         - dist/

3. 执行依赖安装。
   脚本运行时，系统会自动执行 npm install 命令。这一步会将 package.json 中定义的所有依赖包下载到本地环境中。

4. 生成产物。
   运行 npm run build 命令。该命令会将源代码编译、压缩，并输出到 dist 目录。配置中的 artifacts 关键字告诉系统将这个目录打包保存，供后续阶段使用。

第二阶段：自动化测试

测试阶段用于拦截错误的代码，防止低级 Bug 流入生产环境。

1. 配置测试作业。
   在构建阶段之后，添加测试阶段的配置。确保测试作业依赖于构建产生的 artifacts。

   添加以下代码到配置文件：

   test_job:
     stage: test
     image: node:16
     script:
       - npm install
       - npm test
     dependencies:
       - build_job

2. 运行单元测试。
   执行 npm test 命令。系统会自动运行项目中编写的所有测试用例（通常使用 Jest 或 Mocha 框架）。

3. 判断测试结果。
   如果测试通过，退出码为 0，流水线继续；如果测试失败，退出码非 0，流水线立即终止，并向开发者发送失败通知。

第三阶段：持续部署

部署阶段将通过测试的代码发布到服务器或生产环境。

1. 设定部署环境变量。
   在系统设置中配置服务器的 IP 地址、SSH 密钥以及登录用户名。切勿将这些敏感信息直接写在代码文件中。

2. 编写部署脚本。
   添加部署作业，使用 SSH 连接远程服务器并执行更新命令。

   编写如下部署逻辑：

   deploy_job:
     stage: deploy
     image: alpine:latest
     before_script:
       - 'which ssh-agent || ( apk add --update openssh-client )'
       - eval $(ssh-agent -s)
           - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
       - mkdir -p ~/.ssh
       - chmod 700 ~/.ssh
     script:
       - ssh -o StrictHostKeyChecking=no user@your-server-ip "cd /var/www/html && git pull && npm install --production && pm2 restart all"
     only:
       - main

3. 连接远程服务器。
   脚本利用 SSH 协议登录到目标服务器。StrictHostKeyChecking=no 参数用于避免首次连接时的主机确认提示，实现全自动登录。

4. 更新代码与服务。
   在服务器端执行一系列命令：

   • 切换到项目目录。
   • 拉取最新代码。
   • 安装生产环境依赖。
   • 重启进程管理器（如 PM2），使新代码生效。

流程可视化

为了更直观地理解各阶段的关系与流转逻辑，以下是 CI/CD 流水线的状态流转图。

效率对比分析

实施 CI/CD 前后，发布效率有显著差异。我们可以通过以下公式计算每次发布节省的时间：

$$ T_{saved} = (T_{manual\_build} + T_{manual\_test} + T_{manual\_deploy}) - T_{pipeline} $$

其中 $T_{pipeline}$ 通常是一个固定且极短的常量（主要是机器执行时间），而手动操作时间 $T_{manual\_...}$ 则随着项目复杂度呈指数级增长。

下表详细对比了两种模式的关键差异：

通过以上步骤，你已经建立了一条从代码提交到线上运行的自动化高速公路。