搭建 CI/CD 流水线

适用场景

从代码提交到构建、测试、安全扫描、制品发布和部署的自动化。以 GitHub Actions 为例，思路适用于 GitLab CI 等。

前置条件

• 代码仓库、构建环境、制品仓库和目标环境。
• 明确分支策略、发布审批和回滚流程。
• 凭据用 OIDC/Secrets 管理，不硬编码。
• 准备测试、扫描和部署脚本。

步骤

1. 定义流水线阶段：

lint → test → build → scan → package → deploy-staging → approve → deploy-prod

2. 编写 workflow：

name: ci-cd
on:
  push:
    branches: [main]
  pull_request:
permissions:
  contents: read
  packages: write
concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm test
  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t app:${{ github.sha }} .
      - run: docker push registry.example.com/app:${{ github.sha }}

3. 加入安全扫描：

- uses: aquasecurity/trivy-action@...
  with:
    image-ref: registry.example.com/app:${{ github.sha }}
    exit-code: '1'

4. 部署到 staging，跑冒烟测试。

5. 生产部署加 environment 审批和 OIDC 凭据。

6. 配置回滚：保留上一个镜像 tag，部署失败自动回滚。

验证

• PR 触发测试，main 触发构建和部署。
• 制品 tag 与 commit 对应，可追溯。
• 扫描失败能阻断发布。
• 生产审批、部署和回滚正常。

回滚

• 重新部署上一个已知良好的镜像 tag。
• 数据库变更要有向下兼容/回滚脚本。
• 保留构建日志和制品。

常见坑

• Secrets 泄露和 fork PR 安全；不要用 pull_request_target 执行不可信代码。
• 缓存 key 不含 lockfile 哈希会拿到旧依赖。
• 构建不可复现（浮动 tag、未锁版本）。
• 部署凭据长期有效；优先 OIDC/短期令牌。
• 没有回滚方案，失败只能手工救火。
• 流水线过长会拖慢反馈；并行化和缓存要平衡。

相关命令

• github-actions — 工作流
• docker-buildx — 镜像构建
• trivy — 镜像扫描
• kubectl / helm — 部署

读完自测

合上页面，先回答，再展开对照。

1. 为什么不能用 pull_request_target 执行 fork PR 的不可信代码？
2. 镜像扫描失败要阻断发布，配置上靠什么实现？
3. 回滚方案应包含哪些内容？