博客 Jenkins 发布链路三层质量闸门实践

博客系统做商业化升级之后，发布链路的目标不能再停留在“Jenkins 构建成功”。

对一个承载内容资产、产品入口和企业咨询入口的技术博客来说，更重要的是：

内容仓库是否真的拉取完整？
Hexo 是否生成了关键静态页面？
部署后的容器是否真的能访问？
/services/、/products/、PR 审查官等商业入口是否还在？
sitemap、专题页、CTA 样式是否没有被误删？

这次改造的目标，就是把博客发布链路从“流程跑完”升级为“关键结果被验证”。

一、原来的问题

原来的 Jenkins 流程主要关注：

拉取总仓库和子模块
执行 Hexo 构建
构建 Docker 镜像
启动或热更新 Nginx 容器

这些步骤能证明“流程执行过”，但不能充分证明“博客真的发布正确”。

例如下面这些问题，以前不一定能及时暴露：

source 内容子模块没有正确更新
关键页面没有生成，但镜像仍然构建成功
首页能打开，但产品页或服务页 404
sitemap 缺失，影响搜索引擎收录
商业 CTA 样式丢失，导致转化入口不可见
容器启动了，但 Nginx 实际返回异常页面

所以我们需要在发布流程里增加质量闸门。

二、三层质量闸门设计

这次加固分成三层。

1. 内容检查：拉取代码后立即检查

第一层发生在 Jenkins 拉取总仓库和子模块之后。

检查目标是 source 内容仓库，重点确认：

内容目录存在
文章目录存在
服务页、产品页等关键页面存在
重要内容结构没有明显缺失

这样可以尽早发现内容子模块没有拉下来、目录结构异常、关键页面丢失等问题。

2. 产物检查：Hexo 构建后检查 public

第二层发生在 Hexo 生成静态文件之后。

检查目标是 public 目录，重点确认：

index.html 存在
sitemap.xml 存在
/services/ 页面生成
/products/ 页面生成
/products/pr-reviewer/ 页面生成
AI Agent、AI Coding、Claude Code、MCP、OpenClaw 等专题页生成
商业 CTA 样式存在

这一层可以发现“源码存在，但构建结果不完整”的问题。

3. 运行时检查：部署后访问真实 HTTP 地址

第三层发生在容器部署或热更新之后。

检查目标是运行中的博客服务，例如：

1	http://localhost:4000

检查内容包括：

首页 HTTP 200
服务页 HTTP 200
产品页 HTTP 200
PR 审查官页面 HTTP 200
sitemap HTTP 200
首页包含产品和服务入口
Footer 或 Sidebar 中的商业入口仍然存在

这一层解决的是“构建成功、容器启动成功，但线上页面不可用”的问题。

三、为什么要在 Jenkinsfile 里接入

博客部署采用“总仓库 + 内容仓库 + 主题仓库”的结构。

Jenkins 实际读取的是总仓库 site.git 的 main 分支里的 Jenkinsfile，因此这类发布流程加固应该放在总仓库侧，而不是内容发布流程里。

这样做有几个好处：

发布质量规则集中维护
内容仓库只负责内容变更
主题仓库只负责模板和样式
Jenkins 作为统一发布入口，负责最后的质量兜底

这也符合仓库职责边界：内容、主题、部署流程分开管理。

四、这类检查的价值

质量闸门的价值不是“让构建更容易失败”，而是让失败更早、更明确。

以前的问题可能是：

Jenkins 显示成功，但访问页面才发现产品页没有了。

现在的问题会变成：

check-public.sh 明确提示 /products/pr-reviewer/index.html 缺失。

这对排障非常重要。

它让问题从“线上事故”前移成“构建阶段错误”。

五、后续优化方向

这次三层检查只是第一版，后续还可以继续增强：

检查规则配置化
把关键页面、关键词、CTA 标记放到配置文件里，避免写死在脚本中。
按环境区分检查强度
测试环境可以只做基础检查，生产环境执行完整检查。
增加链接巡检
对首页、产品页、服务页中的内部链接做递归检查，发现死链。
增加性能基线
检查首页响应时间、HTML 大小、关键资源加载情况。
输出结构化报告
将检查结果输出为 Markdown 或 JSON，方便回写 MR 或归档。

六、发布验证记录

本次文章也作为内容仓库合并后的发布验证样本，用来触发 Jenkins 重新拉取最新 site/main、最新内容仓库和最新主题子模块，验证内容检查、public 产物检查、运行时健康检查以及全站自动 CTA 是否全部生效。

七、总结

这次 Jenkins 发布链路加固，本质上是一次博客工程化升级。

它解决的不是单个脚本问题，而是发布质量标准问题：

不是 Jenkins 跑完就算成功，而是内容、产物、运行时页面都通过检查，才算真正发布成功。

对于正在商业化升级的技术博客来说，这类质量闸门非常关键。

因为博客不只是文章归档，而是产品入口、服务入口和长期信任资产。