Jenkins集成CICD服务目录的参数配置 - 第1节
1. CI/CD 概述：持续集成、持续交付、持续部署的概念与区别
1.1 核心概念定义
在 DevOps 实践中，CI/CD 是支撑软件交付自动化的三大核心实践。理解三者的定义与边界，是配置 Jenkins 流水线的前提。
| 实践 | 英文全称 | 核心目标 | 典型触发时机 |
|---|---|---|---|
| 持续集成 | Continuous Integration | 频繁合并代码变更，自动构建并验证 | 每次代码推送（Push / Merge Request） |
| 持续交付 | Continuous Delivery | 确保每次变更都可部署到生产环境（需人工审批） | CI 通过后自动部署到预发布环境 |
| 持续部署 | Continuous Deployment | 每次变更自动通过流水线直达生产环境 | 所有自动化测试通过后直接上线 |
关键区分：持续交付与持续部署的唯一区别在于“生产环境部署是否需人工审批”。持续交付保留“一键部署”的决策权，持续部署则完全自动化。
1.2 三者的流程关系
下图展示了从代码提交到生产上线的完整 CI/CD 流程，以及三个实践覆盖的阶段范围。
1.3 三者的核心区别
- 自动化程度不同：CI 只覆盖构建与测试；持续交付覆盖到预发布环境；持续部署覆盖到生产环境。
- 人工干预节点：CI 无人工干预；持续交付在预发布→生产之间保留审批按钮；持续部署完全无人值守。
- 风险控制策略：CI 通过快速反馈降低集成风险；持续交付通过“随时可发布”降低发布风险；持续部署通过全自动化降低操作风险。
- 适用场景：CI 适合所有项目；持续交付适合需要发布节奏控制的企业；持续部署适合测试覆盖率高、回滚机制成熟的团队。
常见误区：很多团队将“自动部署到测试环境”误认为持续部署。持续部署特指生产环境的自动化发布，测试环境部署属于持续交付的范畴。
2. Jenkins 在 DevOps 生态中的定位
2.1 DevOps 工具链全景
DevOps 生态包含计划、编码、构建、测试、发布、部署、运维、监控等环节。Jenkins 作为编排引擎，处于工具链的枢纽位置。
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 标准化交付。