Jenkins Pipeline交付工程 - 第1节

1. CI/CD概述

1.1 核心概念定义

在 DevOps 实践中,CI/CD 是支撑软件交付自动化的三大核心实践。理解三者的定义与边界,是配置 Jenkins 流水线的前提。

实践 英文全称 核心目标 典型触发时机
持续集成 Continuous Integration 频繁合并代码变更,自动构建并验证 每次代码推送(Push / Merge Request)
持续交付 Continuous Delivery 确保每次变更都可部署到生产环境(需人工审批) CI 通过后自动部署到预发布环境
持续部署 Continuous Deployment 每次变更自动通过流水线直达生产环境 所有自动化测试通过后直接上线
关键区分:持续交付与持续部署的唯一区别在于“生产环境部署是否需人工审批”。持续交付保留“一键部署”的决策权,持续部署则完全自动化。

1.2 三者的流程关系

下图展示了从代码提交到生产上线的完整 CI/CD 流程,以及三个实践覆盖的阶段范围。

CI/CD 流程覆盖范围 CI / CD 流程覆盖范围 代码提交 自动构建 单元测试 预发布部署 生产上线 持续集成(CI)范围 持续交付(CD) 持续部署 CI:开发阶段自动化验证 CD:从验证通过到生产就绪的自动化 持续部署 = 持续交付 + 自动生产发布(无人工门禁)

1.3 三者的核心区别

  • 自动化程度不同:CI 只覆盖构建与测试;持续交付覆盖到预发布环境;持续部署覆盖到生产环境。
  • 人工干预节点:CI 无人工干预;持续交付在预发布→生产之间保留审批按钮;持续部署完全无人值守。
  • 风险控制策略:CI 通过快速反馈降低集成风险;持续交付通过“随时可发布”降低发布风险;持续部署通过全自动化降低操作风险。
  • 适用场景:CI 适合所有项目;持续交付适合需要发布节奏控制的企业;持续部署适合测试覆盖率高、回滚机制成熟的团队。
常见误区:很多团队将“自动部署到测试环境”误认为持续部署。持续部署特指生产环境的自动化发布,测试环境部署属于持续交付的范畴。

2. Jenkins 在 DevOps 生态中的定位

2.1 DevOps 工具链全景

DevOps 生态包含计划、编码、构建、测试、发布、部署、运维、监控等环节。Jenkins 作为编排引擎,处于工具链的枢纽位置。

Jenkins 在 DevOps 工具链中的定位 Jenkins 在 DevOps 工具链中的定位 Git / GitLab SonarQube Docker / K8s Nexus / Harbor Ansible / Salt Prometheus Jenkins CI/CD 编排引擎 Jenkins 作为调度中枢 从代码仓库拉取 → 静态分析 → 构建镜像 → 制品管理 → 环境部署 → 监控反馈 通过 Pipeline 插件串联所有工具,形成端到端自动化流水线

2.2 Jenkins 的核心能力

能力维度 具体说明 对应插件/功能
流水线编排 通过 Jenkinsfile 定义构建、测试、部署阶段 Pipeline、Declarative Pipeline
多源集成 支持 Git、SVN、Gerrit 等版本控制系统 Git Plugin、Multibranch Pipeline
触发机制 支持 Webhook、定时轮询、参数化触发 Generic Webhook Trigger、Build Trigger
分布式执行 通过 Master/Agent 架构实现负载均衡 Swarm Plugin、Kubernetes Plugin
结果反馈 构建日志、测试报告、代码质量看板 JUnit Plugin、HTML Publisher

2.3 Jenkins 与其他 CI/CD 工具的对比

对比维度 Jenkins GitLab CI GitHub Actions
部署方式 自托管(可私有化) SaaS / 自托管 SaaS(自托管 Runner)
流水线定义 Jenkinsfile(Groovy) .gitlab-ci.yml(YAML) .github/workflows(YAML)
插件生态 1800+ 插件,高度可扩展 内置功能丰富,扩展有限 Marketplace 持续增长
适合场景 复杂流水线、多工具集成 GitLab 原生生态团队 GitHub 原生生态团队
课程定位:本课程聚焦 Jenkins 的服务目录参数配置,即如何通过参数化构建、Active Choices 插件、配置化 Pipeline 等手段,让 Jenkins 流水线具备“服务目录”式的可复用能力,支撑多项目、多环境的 CI/CD 标准化交付。