CI/CD 基础概念与流水线

这一章我们来聊聊 CI/CD 到底是个啥。说白了两件事：持续集成（CI） 和 持续部署（CD）。很多团队把 CI/CD 挂嘴边，但真到上线时才发现“我 Jenkins 跑完了手动点个部署按钮也叫 CD？”。嗯，这里要把概念先捋清楚。

持续集成（CI），你代码合进去了没？

持续集成不是某个工具，是一种开发实践。它要求开发人员频繁地将代码合并到主干，每次合并都触发自动化构建和测试，第一时间发现集成错误。

我记得刚入行时，公司还是两周一合并，Merge 时冲突能改一下午。后来我强行推了 CI，每天至少合两次，冲突几乎消失了，质量反而更稳。避坑指南：我曾经见过团队把 CI 当作“只编译不测试”的流水线，结果线上跑炸了才发现单元测试全失败。所以我建议——CI 流水线至少要包含：编译、单元测试、代码静态检查、安全扫描。

持续部署（CD），代码自动上线的最后一公里

持续部署是在 CI 的基础上，把通过测试的构建产物自动推送到生产环境。注意是自动，不需要人去点鼠标。很多人会把“持续交付”和“持续部署”混着用。我习惯这么区分：

你想想看，如果是金融支付类业务，你敢不敢全自动部署？我个人的经验：密码改造这种敏感改动，前期走持续交付更安全，灰度放量一两周后再切到持续部署。

CI/CD 流水线长什么样？

一条典型的 CI/CD 流水线包含下面几个阶段。我把它画成了一张图，方便你建立整体认识。

你看，从代码提交到生产发布，中间插入了安全基线扫描。密码改造正是在这个环节嵌入的。我参与的项目里，很多团队把安全扫描放在最后一步，结果发现问题时回滚成本巨大。我个人建议：“安全左移”，比如把密码静态扫描放到编译步骤之后、测试之前。

常用工具选型，怎么挑？

现在 CI/CD 工具多如牛毛，我挑几个主流的给你列一下。不是要你全用，而是根据团队规模和场景选。

选型时我会问三个问题：

• 团队有没有运维能力？有的话上 Jenkins 或 Drone，自定义强；没有就选 GitLab CI 或 GitHub Actions。
• 密码改造需要引入第三方安全插件，工具对自定义插件的支持怎么样？Jenkins 插件市场最全，GitLab CI 可以通过自定义镜像解决。
• 能不能和现有的密码管理平台（比如 HashiCorp Vault、CyberArk）集成？直接影响改造工程化程度。

流水线配置示例（GitLab CI 片段）

下面是一个包含密码安全扫描的极简 .gitlab-ci.yml 示例。你复制到项目中就能跑起来。

stages:
  - build
  - test
  - security-scan
  - deploy

build-job:
  stage: build
  script:
    - echo "编译代码..."
    - npm ci

test-job:
  stage: test
  script:
    - echo "运行单元测试..."
    - npm test

security-scan-job:
  stage: security-scan
  image: registry.gitlab.com/security-tools/secrets-scanner:latest
  script:
    - secrets-scanner scan --path . --exclude node_modules
  artifacts:
    paths:
      - security-report.json
  only:
    - master

deploy-job:
  stage: deploy
  script:
    - echo "部署到 staging..."
  environment:
    name: staging
  needs:
    - test-job
    - security-scan-job

项目中的选型决策清单

好了，说了这么多，接下来我给你一个可以直接抄作业的决策表。当你接到密码改造任务时，按照下表对号入座：

1. 团队人数 < 20 人 → 选 GitLab CI 或 GitHub Actions，开箱即用，不必折腾。
2. 团队人数 20-100 人 → 选 Jenkins 或 Drone CI，可定制、可审计、可集成密码扫描插件。
3. K8s 环境占比高 → Drone CI + ArgoCD，真正的云原生流水线。
4. 监管要求严格（金融、政务） → 自建 Jenkins，全部离线部署，安全扫描 stage 必须有强制阻断。
5. 需要引入动态凭据管理 → 无论选哪个工具，确保它支持 Vault 或 CyberArk 的 secret 注入。