[DevOps] 重构 Hexo 工作流：从手动部署到 GitHub Actions 自动化

发表于 更新于 分类于 ，
深度复盘博客发布流程的重构过程。分析旧有手动部署的脆弱性，对比不同同步方案，最终确立基于 Git + GitHub Actions 的 CI/CD 自动化工作流。

一、起因：一次电脑迁移引发的“折腾”

最近我换了新电脑，在迁移数据时，翻出了一个部署了好几年的 Hexo 博客。
时过境迁，一方面工作了几年，确实有东西想沉淀和输出；另一方面，“AI+自动化”的概念正火。
我突然想到：能不能把这个古老的博客发布流程也“自动化”一下？

二、Legacy 流程分析：脆弱且低效

我以前的发布流程非常原始，可以说是“手工作坊”：

  1. 本地执行 hexo new 创建文章。
  2. 本地开启 hexo server 预览。
  3. 本地执行 hexo generate 生成 public 静态文件。
  4. 手动 hexo deploy (或 scp) 上传到服务器。

RCA (缺陷分析)：

  • 无版本控制 (No Version Control): 源文件 (.md) 只存在于本地。电脑坏了 = 数据丢失。
  • 环境脆弱 (Environment Fragility): 依赖本地 Node.js 环境。我是做嵌入式开发的，环境混杂，Node 版本一变，博客就崩。
  • 心流中断 (Flow Interruption): 每次发布都要敲一堆命令，非常繁琐。

三、方案探索：架构决策过程

我的初始目标是：让主力机保持“纯净”，尽量不安装 Node.js 环境。

方案一：构建机分离 (Build Server)

  • 架构： 主力机只写 .md -> 通过 SMB 传给旧电脑 -> 旧电脑执行 hexo g。
  • 否决原因： 链路太长，依赖旧电脑实时在线，维护成本高。

方案二：Git + 手动双机协作

  • 架构： 主力机 Push -> 旧电脑 Pull -> 旧电脑 hexo g。
  • 否决原因： 演变成了 “Push/Pull Hell”，依然需要人工干预两台设备。

四、最终架构：Git + GitHub Actions (CI/CD)

既然无论如何都要用 Git，为什么不把“构建和部署”这个“脏活”交给云端？

核心决策：

  1. Single Source of Truth: Git 仓库作为唯一事实来源。
  2. Automation: GitHub Actions 作为构建机器人。
  3. Compromise: 为了便利，我在主力机安装了 Node.js，但只用于 hexo new 和 hexo server (预览)，构建压力全部上云。

1. 解决了什么痛点？

  • 源码安全: .md 和 _config.yml 全部上云。即使本地环境崩了，git clone + npm install 即可恢复。
  • 环境解耦: 真正的构建（hexo generate）在 GitHub 的干净容器里跑，不受我本地嵌入式开发环境的干扰。
  • 部署自动化: push 即发布。

2. 新的工作流 (The New Workflow)

现在的发布流程简化为 “只关心内容创作和 Git 提交”：

1
2
3
4
5
6
7
8
# 1. 创建与预览 (Local)
npx hexo new "我的新文章"
npx hexo server

# 2. 提交 (Trigger)
git add .
git commit -m "feat: new post"
git push origin source

Behind the Scenes (自动化后台): GitHub Actions 收到 Push 后自动执行：

  1. Checkout source 分支。

  2. Setup Node.js 环境。

  3. Run hexo generate。

  4. Deploy public/ to Server / Pages.

五、总结：复杂度守恒定律的胜利

坦白说，新流程（add -> commit -> push）在本地操作步骤上并不比旧流程（hexo d）少。

但这是一种良性的复杂度转移：我们把复杂度从“人工操作”转移到了“架构设计”上。

ROI (投资回报):

  1. Data Safety: 版本控制保证了数据零丢失。

  2. Reproducibility: 换 10 台电脑也能在 5 分钟内恢复写作环境。

  3. Mobility: 我甚至可以用 iPad 的 Git 客户端改错别字，云端自动构建发布。

这，才是一个 2025 年该有的自动化工作流。