CI/CD

概述 用 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，构建后操作填部署脚本。保存，点构建，跑起来了。...

CI/CD 是现代软件交付的命脉。手动构建、手动部署不仅效率低下，更是事故的温床——“在我机器上能跑"的悲剧几乎都源于缺乏自动化流水线。GitHub Actions 作为 GitHub 原生的 CI/CD 平台，与代码仓库无缝集成，免费额度对开源项目友好，已成为最流行的 CI/CD 工具之一。从核心概念出发，结合 Go 项目和 Hugo 站点两个实战场景，完整讲解流水线设计。 参考来源：GitHub Actions 官方文档 一、GitHub Actions 核心概念 GitHub Actions 的架构围绕五个概念展开，理解它们的关系是设计流水线的基础： Workflow（工作流） │ ├── Job A（任务） │ ├── Step 1 → Action: checkout 代码 │ ├── Step 2 → Action: setup Go 环境 │ └── Step 3 → Shell: go test ./... │ └── Job B（任务） ├── Step 1 → Action: 下载构建产物 └── Step 2 → Shell: 部署到服务器 概念 说明 类比 Workflow 一个 ....