更新说明：本文原本配了 GitHub Actions 自动部署流程，后来还是觉得手动部署更顺手，所以已移除工作流文件。不过 CI/CD 的思路和配置方法本身没问题，如果你感兴趣依然可以参考。

CI/CD 配置指南：让你的 Hexo 博客自动部署

什么是 CI/CD？

CI/CD 是 持续集成（Continuous Integration） 和 持续部署（Continuous Deployment） 的缩写。说白了就是：你只管写代码推上去，剩下的构建、测试、部署全都自动完成。

以前更新博客的流程是：

1

本地写文章 → hexo generate → hexo deploy → 等待上传完成

有了 CI/CD 之后变成：

1

本地写文章 → git push → 剩下全自动

GitHub 收到你的推送后，会自动拉取代码、安装依赖、生成静态页面、部署到 Pages。整个过程在 GitHub 的服务器上完成，你本地连 Node.js 都不用装。

核心概念

持续集成（CI）

每次你推送代码到仓库，CI 会自动执行一系列任务：

• 拉取最新代码
• 安装项目依赖（npm install）
• 运行构建命令（hexo generate）
• 验证构建是否成功

如果构建失败（比如依赖出问题、模板语法错误），你会立刻收到通知，不会把坏代码部署上线。

持续部署（CD）

CI 验证通过后，CD 会自动把构建产物发布到生产环境。对于 Hexo 博客来说，就是把生成的 public/ 目录推送到 GitHub Pages 的分支上，网站就自动更新了。

我的 Hexo 博客是怎么配置的？

我的博客源码托管在 GitHub，使用 GitHub Actions 作为 CI/CD 平台。GitHub Actions 是 GitHub 自带的免费自动化服务，对于公开仓库完全没有使用限制。

工作流程文件

在项目根目录创建 .github/workflows/deploy.yml，内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

name: Deploy Hexo to GitHub Pages

on:
  push:
    branches: [master]
  workflow_dispatch:

permissions:
  contents: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout source
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Generate site
        run: npx hexo generate

      - name: Deploy to GitHub Pages
        env:
          GIT_USER: github-actions[bot]
          GIT_PASS: ${{ secrets.GITHUB_TOKEN }}
        run: |
          git config --global user.name 'github-actions[bot]'
          git config --global user.email 'github-actions[bot]@users.noreply.github.com'
          npx hexo deploy

流程拆解

这个工作流定义了 5 个步骤：

1. Checkout — 把源码拉到 GitHub 的虚拟服务器上
2. Setup Node.js — 安装 Node.js 20 并启用 npm 缓存加速后续构建
3. Install dependencies — 执行 npm ci，根据 package-lock.json 精确安装依赖（比 npm install 更快更稳定）
4. Generate site — 运行 hexo generate 生成静态页面
5. Deploy to Pages — 通过 hexo deploy 将生成的页面推送到 GitHub Pages

触发条件写的是 push: branches: [master]，也就是只要往 master 分支推送代码，流水线就会自动启动。

分支策略

为了配合这个 CI/CD 流程，我的博客采用了两个分支：

以前我需要在本地跑 hexo g && hexo d，现在只要：

1
2
3

git add -A
git commit -m "新文章：xxx"
git push origin master

然后去 GitHub 仓库的 Actions 标签页就能看到流水线正在运行。等跑完（一般 1-2 分钟），网站就自动更新了。

CI/CD 的好处

1. 告别环境依赖

本地换电脑了？重装系统了？只要 GitHub 上有源码，随时可以写文章推上去，构建环境是云端统一管理的，不会出现”在我电脑上是好的啊”这种尴尬。

2. 构建过程可追溯

每次部署的记录都保存在 GitHub Actions 的日志里，构建成功还是失败、用了多少时间、输出了什么内容，一目了然。

3. 多人协作友好

如果你的博客有多位作者，每个人只需要往 master 推送文章，GitHub Actions 会自动处理后续的构建和部署，不需要每个人都配置部署密钥。

4. 免费且稳定

GitHub Actions 对公开仓库完全免费，每月有 2000 分钟的免费运行时长。对于个人博客的更新频率来说，根本用不完。

如何验证 CI/CD 是否运行正常？

代码推送后，打开 GitHub 仓库页面，点顶部的 Actions 标签：

1. 如果流水线显示绿色 ✅，说明构建和部署成功
2. 如果显示红色 ❌，点进去查看具体的报错日志，通常 npm ci 或构建步骤出问题会有明确提示

你也可以手动触发：在 Actions 页面找到你的工作流，点 Run workflow → 选择分支 → 绿色按钮，不需要推送代码也能触发。

写在最后

配置 CI/CD 是我博客搭建以来最值得的投资之一。每次更新博客从原来的多步操作变成一行 git push，这种体验的提升是实实在在的。

如果你的 Hexo 博客还没配 CI/CD，花 10 分钟搞定它，往后每次更新都能省下一两分钟。积少成多，省下的时间够多写好几篇文章了。