2、流水线基础：CI/CD流水线概念、常见阶段与工具链概述

2.1 从“手动交付”到“流水线自动化”

在讨论异常定位与自动回滚之前，必须先建立对流水线本身的清晰认知。CI/CD（Continuous Integration / Continuous Delivery，持续集成与持续交付）流水线，本质上是将软件从代码提交到生产环境部署的整个过程，拆解为一系列可自动执行、可观测、可控制的阶段。每一个阶段接收上游产物，执行特定类型的验证或转换，并将结果传递给下游。

流水线的核心价值不在于“自动化”本身，而在于可重复性与可审计性。手动操作最大的问题是“环境差异”和“人为失误”——开发机可以构建，但服务器上可能缺少依赖；测试环境通过，但生产环境配置不同。流水线将构建、测试、部署的动作固化到统一的执行环境中，确保每次执行都基于相同的输入和步骤，从而让“异常”变得可以被复现和定位。

2.2 流水线的常见阶段与职责边界

一条典型的CI/CD流水线通常包含以下五个核心阶段。理解每个阶段的输入、输出和失败模式，是后续进行异常定位的基础。

上图中，质量闸门是流水线中最关键的控制点。它通常设置在测试阶段之后，只有满足预设条件（如测试覆盖率不低于80%、关键用例全部通过）的制品才能进入部署阶段。当闸门拦截时，流水线应自动停止并发出告警，而不是带着已知问题继续向下游传递。

2.3 工具链全景：从代码到监控的生态

流水线的落地依赖一套完整的工具链。下表梳理了各阶段常用的工具类型与代表产品，便于在实际项目中建立工具选型的基本框架。

工具链的选择需要遵循“流程驱动工具”的原则，而不是“工具驱动流程”。例如，如果团队已经使用GitLab进行代码管理，那么GitLab CI/CD可以天然地与MR（Merge Request）流程集成，在代码评审的同时触发流水线，减少上下文切换的成本。

2.4 案例：一次典型的流水线执行过程

以下是一个基于GitLab CI + Kubernetes的简化流水线配置片段，展示了各阶段如何串联：

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - mvn clean package -DskipTests
  artifacts:
    paths:
      - target/*.jar

test-job:
  stage: test
  script:
    - mvn test
    - python3 scripts/check_coverage.py  # 自定义质量闸门
  needs: ["build-job"]

deploy-job:
  stage: deploy
  script:
    - kubectl set image deployment/my-app my-app=myregistry/my-app:${CI_COMMIT_SHA}
  environment: production
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  needs: ["test-job"]

在这个案例中，artifacts关键字将构建产物传递给测试阶段；needs声明了阶段间的依赖关系；rules则限制了只有main分支的提交才会触发生产部署。当测试阶段的check_coverage.py脚本返回非零退出码时，流水线会立即终止，部署阶段不会执行。

2.5 常见误区与复盘