0%

Hexo 博客自动部署指南：GitLab CI/CD 与 Jenkins 两种方案对比

发表于 更新于 分类于
本文字数： 2.7k 阅读时长 ≈ 5 分钟
Hexo 博客自动部署完整指南，对比 GitLab CI/CD 与 Jenkins 两种方案，覆盖构建、部署、质量检查、缓存、回滚和企业级发布建议。

Hexo 是一个轻量、高效的静态博客框架，非常适合技术博客、团队知识库和产品文档站。但只要站点进入长期运营，部署方式就应该从“本地手工命令”升级为 CI/CD 自动发布。

本文对比 GitLab CI/CD 与 Jenkins 两种常见方案，并给出一套更适合企业长期维护的实践建议。

1. 自动部署的基本流程

无论使用 GitLab CI/CD 还是 Jenkins，核心流程都类似：

1
2
3
4
5
6
7
提交内容
  -> 触发流水线
  -> 安装依赖
  -> Hexo 生成 public
  -> 检查产物
  -> 发布到服务器 / 对象存储 / Docker 容器
  -> 运行时验证

关键不是“能不能部署”，而是能否做到：

  • 每次发布可追踪；
  • 每次失败可定位；
  • 每次回滚有依据；
  • 内容、主题、部署配置边界清晰。

2. 方案一：GitLab CI/CD

GitLab CI/CD 适合仓库与流水线都托管在 GitLab 的团队。一个简化 .gitlab-ci.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
stages:
  - check
  - build
  - deploy

cache:
  paths:
    - node_modules/

content_check:
  stage: check
  script:
    - bash .ci/check-content.sh source

build:
  stage: build
  script:
    - npm ci
    - npx hexo clean
    - npx hexo generate
    - bash .ci/check-public.sh public
  artifacts:
    paths:
      - public/
    expire_in: 7 days

deploy:
  stage: deploy
  script:
    - rsync -avz public/ user@server:/data/www/blog/
    - bash .ci/check-runtime.sh https://blog.example.com
  only:
    - main

优点：

  • 与 GitLab MR 集成自然；
  • 配置文件跟随仓库；
  • 适合轻量静态站点；
  • artifact 管理方便。

不足：

  • 复杂部署、内网环境、Docker 编排能力不如 Jenkins 灵活；
  • 私有网络和凭据管理需要额外规划；
  • 多仓库 / 子模块场景要谨慎处理。

3. 方案二：Jenkins

Jenkins 更适合已有内网部署、复杂发布流程和多环境管理的团队。典型 Jenkins stage：

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
pipeline {
  agent any

  stages {
    stage('Checkout') {
      steps {
        checkout scm
        sh 'git submodule update --init --recursive --remote'
      }
    }

    stage('Content Check') {
      steps {
        sh 'bash .ci/check-content.sh source'
      }
    }

    stage('Build') {
      steps {
        sh 'npm ci'
        sh 'npx hexo clean && npx hexo generate'
      }
    }

    stage('Public Check') {
      steps {
        sh 'bash .ci/check-public.sh public'
      }
    }

    stage('Deploy') {
      steps {
        sh 'docker build -t blog:${BUILD_NUMBER} .'
        sh 'docker run -d --name blog --restart unless-stopped blog:${BUILD_NUMBER}'
      }
    }
  }
}

优点：

  • 对内网环境友好；
  • Docker、Nginx、SSH、私有镜像仓库集成灵活；
  • 适合复杂发布和多环境管理。

不足：

  • Jenkinsfile 容易变长；
  • 插件和节点环境需要维护；
  • 凭据、权限和日志要做好治理。

4. 质量闸门设计

Hexo 博客的 CI/CD 不能只跑 hexo generate，建议至少加三层质量闸门：

4.1 内容检查

检查：

  • Front Matter；
  • 关键页面；
  • 冲突标记；
  • 内部路径或敏感信息；
  • CTA / 服务入口。

4.2 产物检查

检查：

  • public/index.html 是否存在；
  • sitemap.xml 是否生成；
  • 产品页、服务页、专题页是否生成；
  • 静态资源路径是否正确。

4.3 运行时检查

检查：

  • 首页 HTTP 200；
  • 关键页面 HTTP 200；
  • 标题、关键词、CTA 是否命中；
  • 容器日志是否异常。

5. SEO 注意事项

自动部署和 SEO 也有关：

  • sitemap 必须随构建更新；
  • 文章 permalink 要稳定，避免频繁改 URL；
  • 重复内容要合并或做差异化定位；
  • 产品页、服务页、专题页要进入 sitemap；
  • 标题、description、keywords 要针对搜索意图优化；
  • 404 页面和旧链接要有处理策略。

这也是为什么博客内容整改时，要把“内容质量”和“发布链路”一起做。

6. 架构师点评

GitLab CI/CD 和 Jenkins 没有绝对优劣。轻量团队可以用 GitLab CI/CD 快速起步；内网部署、多仓库、多环境和 Docker 发布复杂度上来后，Jenkins 仍然有很强的控制力。

真正的关键是：流水线要沉淀工程规则，而不是堆命令。内容检查、产物检查、运行时检查、镜像清理、回滚方案，这些才是长期稳定运营的核心。

7. 企业落地建议

如果你正在做博客、知识库或文档站自动化发布，可以按这个顺序推进：

  1. 先把本地构建命令迁移到 CI；
  2. 增加内容检查和产物检查；
  3. 接入运行时健康检查；
  4. 加入 Docker 镜像清理和回滚；
  5. 再做 SEO、CTA 和商业化入口治理。

需要把技术博客或企业知识库建设成获客入口和 AI 内容运营平台，可以查看 企业 AI Agent / AI Coding 落地咨询。