从 0 到 1 搭建 CI/CD：让部署像提交代码一样简单｜策略拆解

部署应该是流水线，而不是手工仪式。

开篇

这篇文章面向多环境交付团队，从协作视角深入拆解从 0 到 1 搭建 CI/CD。当前定位为「进阶」阶段，核心目标是稳定可复用，开始处理边界。我们会从实际场景出发，结合具体代码示例，把关键知识点拆解为可落地的行动步骤。衡量标准：交付周期/回滚次数。

问题拆解

还记得手动部署的日子吗？SSH 登录服务器，git pull，npm install，pm2 restart——每次都提心吊胆，生怕漏了哪一步。CI/CD 的核心价值不是”自动化”本身，而是”可重复、可追溯、可回滚”。当部署变成一条流水线，你就能把精力从”怎么发布”转移到”发布什么”上。

手动部署有三个致命问题：不可重复（每次操作可能有细微差异）、不可追溯（谁在什么时候部署了什么版本？）、不可回滚（出了问题只能手动修复）。CI/CD 流水线把这三个问题一次性解决。更重要的是，它降低了发布的心理门槛——当你知道随时可以安全回滚时，你会更愿意频繁发布小改动，而不是攒一大堆改动一次性上线。

解决方案

一条基本的 CI/CD 流水线包含以下阶段：

代码检查：ESLint/Prettier 格式化检查，TypeScript 类型检查。
自动化测试：单元测试、集成测试，确保改动没有破坏已有功能。
构建打包：生成生产环境产物，记录构建版本号。
产物存储：将构建产物上传到制品库（如 Docker Registry、S3），确保产物可复用。
部署发布：将产物部署到目标环境，支持灰度发布和快速回滚。

以 GitHub Actions 为例，一个基本的 Node.js 项目流水线只需要一个 YAML 文件。关键是把环境差异抽象为配置变量，而不是硬编码在代码或脚本中。

代码实战

在业务增长带来的容量压力的实际场景中，下面的代码模式非常实用：

# .github/workflows/ci.yml
name: CI/CD Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage
      - run: npm run build

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - name: Deploy to production
        run: echo "Deploy version $GITHUB_SHA"

工程化落地

建议从最小可用流水线开始：代码推送 → 跑测试 → 自动部署到测试环境。等流程稳定后，再逐步加入代码质量门禁（测试覆盖率、代码扫描）、多环境发布（staging → production）、灰度策略等。每次发布都应该生成一个可追溯的版本号，并保留至少最近 5 个版本的回滚能力。

对于多环境交付团队来说，建议从最小可行方案开始，先跑通核心流程，再逐步完善边界处理和监控告警。不要试图一次性做到完美，稳定可复用，开始处理边界才是当前阶段的重点。

避坑清单

常见错误包括：流水线没有质量门禁，测试不通过也能部署；构建产物没有版本化，无法精确回滚；环境配置硬编码在代码中，导致”在我机器上能跑”的问题；以及流水线执行时间过长（超过 10 分钟），导致开发者不愿意等待而绕过流程。

总结与展望

本文从协作视角梳理了从 0 到 1 搭建 CI/CD在进阶阶段的关键实践。核心指标是交付周期/回滚次数，最大风险是规范缺失造成返工。希望这些经验能帮你少走弯路，在业务增长带来的容量压力中更从容地推进。