Jenkins

概述 用 Jenkins 的人分两派：一派在网页上填表单配任务，点几下就跑起来了，简单粗暴；另一派在代码仓库里写 Jenkinsfile，把构建流程变成代码，版本控制、评审、回滚一条龙。 前者叫 Freestyle Project（自由风格项目），后者叫 Pipeline Project（流水线项目）。 这两种风格不是"谁取代谁"的关系。很多团队两个都在用——简单的脚本任务用 Freestyle，复杂的多阶段发布用 Pipeline。但如果你刚开始搞 CI/CD，或者在犹豫要不要从 Freestyle 迁到 Pipeline，这篇文章帮你把两种风格的配置流程、核心差异、选型策略一次性捋清楚。 我先说结论：能用 Pipeline 就用 Pipeline。但别急着全盘迁移，得看场景。下面从零开始配。 Jenkins 项目到底是个什么东西 Jenkins 本身是个任务执行引擎。你给它一组指令——去哪拉代码、怎么编译、往哪部署——它照着干。这组指令的载体就是 Jenkins 项目（Jenkins 内部叫 Job）。 打个比方，Jenkins 是厨师，项目就是菜谱。菜谱写了先切菜、再炒、最后装盘，厨师按步骤做。Freestyle 和 Pipeline 就是两种不同格式的菜谱——一个是填表式，一个是代码式。 Jenkins 原生支持好几种项目类型，实际干活最常用的就两种： 项目类型 怎么配 适合谁 Freestyle Project 在网页上填表单 刚接触 Jenkins 的团队，简单构建场景 Pipeline Project 写 Jenkinsfile 代码 需要多阶段编排、长期维护的团队 还有 Maven 项目（Java Maven 专用的 Freestyle 特化版）和多配置项目（同一任务跑多套参数），用得越来越少，这里不展开。 两种风格的本质区别 先看一个直观的例子。假设要配一个"拉代码 → 编译 → 部署"的任务。 Freestyle 版本：打开 Jenkins 网页，在源码管理填 Git 地址，构建步骤填 mvn clean package，构建后操作填部署脚本。保存，点构建，跑起来了。...

概述 Pipeline as Code 是 Jenkins 从"拖拽式配置"走向"代码化"的分水岭。把流水线定义写在 Jenkinsfile 中，纳入 Git 版本控制，意味着每次流水线变更都有 diff 可审查、有历史可追溯、有分支可回滚。从 Jenkinsfile 语法到生产级流水线设计，详细梳理 Pipeline as Code 的核心实践。 参考来源：Jenkins Pipeline 官方文档 一、Jenkinsfile 语法 1.1 声明式 vs 脚本式 Jenkins Pipeline 有两种语法风格： 维度 声明式（Declarative） 脚本式（Scripted） 语法 结构化 DSL Groovy 代码 可读性 高，接近配置文件 低，需要 Groovy 知识 灵活性 受限于 DSL 约束 完全自由 输入验证 内置 post、when 等结构 需手动实现 推荐场景 标准流水线、团队协作 复杂逻辑、条件分支多 // === 声明式 Pipeline === pipeline { agent any stages { stage('Build') { steps { sh 'make build' } } } } // === 脚本式 Pipeline === node { stage('Build') { sh 'make build' } } 实践建议：优先用声明式，仅在声明式无法表达的复杂逻辑处用 script {} 块嵌入脚本式代码。...