构建一次写入发布流水线

Source: Dev.to

问题

写内容是容易的部分。

在各平台上持续发布——包括正确的元数据、图片、标签、规范 URL 以及更新——往往是最容易出问题的环节。

大多数工作流仍然是这样：

• 在一个工具里写内容
• 复制/粘贴到 WordPress
• 为其他平台重新排版
• 忘记哪些内容已经发布到哪里
• 失去对更新和修复的追踪

我想要点不一样的东西：

一次编写，多处发布，安全更新，全部自动化。

这个目标促使我构建了一个完全自动化、基于 Git 的发布流水线。

核心理念

该系统的核心原则很简单：

Git 中的 Markdown 是唯一的真相来源。

其他所有东西——发布、更新、追踪、媒体处理——都从它衍生。

流水线的设计目标是：

• 幂等（可以安全重复运行）
• CI 级别无状态
• 通过数据库感知状态
• 可扩展到新平台
• 为容器化和 Kubernetes 做好准备

当前功能集

内容与元数据

• 带有 YAML frontmatter 的 Markdown
• 标题、slug、标签、特色图片
• 各平台的发布开关
• 可选的 force_update 标志

发布

• 通过 REST API 向 WordPress 发布（自动创建 以及 更新文章）
• 草稿或已发布状态
• 自动生成规范 URL

特色图片

• 通过 WordPress REST API 上传媒体
• 重用已有媒体（幂等）
• 在 Markdown 中直接声明图片

状态追踪

• 基于 PostgreSQL 的状态追踪：
  • 文章发布到的平台
  • 平台特定的文章 ID
  • 内容哈希
  • 发布时间戳
  • 自动检测内容变化

安全更新

• 内容哈希比较
• 当 Markdown 变化时自动更新文章
• 防止重复发布
• 无需手动编辑数据库

工作流

1. 编写或编辑 Markdown 文件
2. 提交并推送到 Git
3. Jenkins 流水线运行

发布器会：

• 解析 frontmatter
• 计算内容哈希
• 在 PostgreSQL 中检查平台状态
• 如有需要上传特色图片
• 创建或更新 WordPress 文章
• 在数据库中更新状态

流水线安全且可重复完成。

流程图

为什么这种架构有效

Git 是真相

所有内容和意图都存放在 Git 中。没有隐藏状态，没有仅在 UI 中的更改。

数据库是状态

数据库记录已经发生的事情，而不是应该发生的事情。这使得更新和修正更加安全。

CI 是无状态的

Jenkins 在每次运行之间不保存任何东西，使系统可移植且友好于容器化。

平台抽象

WordPress 只是一个发布目标。添加 Dev.to、Substack、Patreon 或其他目标无需对核心做任何修改。

未来方向

流水线已经表现得像一个后端服务。自然的下一步是：

• 增加更多发布目标（Dev.to、Substack 等）
• 引入分析和互动追踪
• 将发布器打包为容器
• 在 Kubernetes 中运行
• 在上层添加一个简易 UI

将其作为 Publishing as a Service 提供：一个仓库，一个工作流，一个真相来源——支撑多年内容创作。

最后感想

最初的想法是“我只想更轻松地发布”，结果演变成一个全自动的发布平台，具备：

• 基于 Git 的内容管理
• CI 驱动的执行
• 数据库支撑的状态
• 幂等且安全的更新发布

最棒的部分是？写内容现在是唯一需要手动完成的步骤。其余全部自动化。