博客的自动发布流程
从 2014 年年初写博客至今,四年多过去了。折腾了好些博客系统,也折腾了好些编辑器,发现博客的发布流程长短,严重影响着博客更新的频率与质量。鉴于此,谈谈我目前博客的发布流程是怎样的,欢迎讨论。
环境信息
node v9.8.0
ruby 2.5.0
在程序员的圈子里,不仅用什么语言要吵,用什么框架要吵,用什么编辑器要吵,用什么博客系统也要吵。众说纷纭当中,如果能找到适合自己的,也不枉摸鱼一天。
就拿写博客和 Markdown 编辑器(或者是笔记这类 App)来说,我用过以下几款:
- Wordpress,OneThink,Jekyll,Octopress,Hexo 等
- EverNote,AlterNote,Mou,MacDown,MWeb,Quiver,SnippetsLab,Bear,SublimeText,Atom,VSCode,Typora 等
其实,每换一次这些工具也好,系统也好,成本都非常高。这些应用或多或少会有些不满足需求,要不然就多个套用,互相弥补,要不然就砍掉自己的需求,适应某一个,当然,作为开发者,也可以选择自己写一个。
问题分析
从工具的过渡不难看出,博客系统再从「富文本 + 动态网站」逐渐变为「Markdown + 静态网站」。而编辑器也在从「零散 + App 自带云存储 + 编辑与预览双屏」到「纯文本编辑 + 独立存储 + 单屏」转变。目前我在用的几款应用如下:
- Hexo
- Bear,VSCode,Typora
博客不用多谈,编辑器之所以有三种,是因为他们的用途不同,并不是一款无法满足要求。
- Bear:主力摘抄
- VSCode:主力写代码,偶尔查看 Markdown 原格式
- Typora:主力 Markdown 编辑器
而备份,清一色的 Git。Bear 在出来的很长一段时间,我都不太喜欢。虽然界面让人眼前一亮,但是备份只能是 Bear 自己的格式,而且它的 tag 是用 #
,这和 Markdown 原有标签冲突,导出就会很丑,无法平滑迁移。但是它的同步、UI,以及 tag 的归类方式,真的挺好用,所以用来做摘抄了。
当我习惯 Markdown,但仍在用 Wordpress 发布的时候,发现 WP 对 Markdown 支持并不好,解析也会出现乱码。所以,我当时发布一篇博客,流程很长:
- 用 Typora 完成博客编写
- 压缩、上传图片到三方图床,替换相对路径
- 导出为不带样式的 HTML
- 登录 Wordpress 后台,复制粘贴富文本
- 设置文章描述、分类、关键字等,点击发布
经过在各种系统上的迁移后,发现博客万变不离其宗的几个特点,这也是在迁移过程中遇到的问题:
- 富文本 or Markdown?(富文本需要依赖渲染,而 Markdown 可读性更高)
- 动态 or 静态?(动态对站内检索支持更方便,如果实在需要,静态也不是不能实现)
- 自己搭 or 三方博客系统?(三方博客…基本上数据就被绑架了,以后别想换)
- 博客系统特定格式 or Markdown 原生格式?(如果用一种博客就改一种格式,多痛苦)
需求确定
对于以上问题,我更倾向于用纯 Markdown,并且就用原生的格式,当然,这其中还需要考虑信息的融合。举个 🌰。
从 Wordpress 中,可以导出的信息是最完整的,除以下信息外,还有发布时间、分类、标签、作者、固定链接等等。
<title>标题<title> |
而 Hexo 支持的格式为:
title: 标题 |
原生 Markdown 的信息最少:
# 标题 |
这就非常尴尬了,原生也太不友好了。那么还要用原生的吗?要!原生是对各个平台支持最好的,以后要迁移起来,也很方便。哪怕最后选择直接 push GitHub,显示起来也没问题。对此,可以对文件目录以及内容做些改动(比如当前这篇博客):
- 2018-09-05-design-a-singleton-block-callbak |
这样,日期与固定链接,就放到了文件夹名称当中,而且文章当中,可以以相对路径的形式引用图片,基本上可以沉浸式的写作,不用关心图片的压缩和上传这些问题。
而其他的信息,都放在了文章内部:
# 标题 |
文章中,采用 hidden
的方式,将附加信息补充上去,并不影响查看。而描述,则是在 more 标签之前。讲道理,more 之前本来也代表着表述。至此,原生的 Markdown 已经可以基本满足日常书写需求了。想要缩短发布的流程,还需要一些脚本的支持。
当然,大家写博客的时候,可能没这么复杂。我的之所以会比较麻烦,是因为最初是富文本,然后用七牛做的图床(辣鸡七牛,别用),私有 Repo,也不想用 GitHub Pages。除了发布博客以外,还会导出一下其他数据。整体来看,对原始数据的处理很多,干脆就自己写个流程了。
针对之前遇到过的问题,整理了一下目标:
- 专注写作,图片的压缩和上传服务器自动处理
- 博客的发布完全不用关注,本地只管 push
- 在发布之前,校验博客的格式以及必要参数,将错误前置
- 以前的发布脚本只针对有改动的文章处理,有很多漏洞,维护成本高
- 支持多个平台的发布
动手实现
首先,将资源分为了四类,放到了四个 repo 里面。除图床外,其他三个 repo 都是 private 的。
其中最为关键的,就是服务器的脚本。说来也不难,就是平时发博客需要手动处理的那几个步骤:
- 拉取原始文件 repo,处理图片并上传到图床。将原始文件中的图片相对路径,改为图床中的路径
- 读取基础信息,比如分类,关键字等,生成 Hexo 可用的格式
- 写个简单的服务,用于接收 repo 变更,push 时触发的 webhook
Rake
用 Rake 写了三个 Task:
desc "发布博客" |
Rack
其中,发布脚本随便用什么写都行。Webhook 的接收,我采用了 Rack 做服务,一个文件搞定。
require 'rack' |
当被监听的 repo 有改动时,触发 Webhook,执行 rake publish
,然后根据 publish
的脚本,自动生成静态文件。
Docker
整个服务器的环境,都做成了 Docker 镜像,方便处理服务器脚本与环境更新。
Slack
由于太穷,而且懒,就没有集成各种 CI 平台,从目前来看,三方平台值得一用的就只是日志查看而已。鉴于此,决定集成 Slack,用于部署结果以及全量日志的查看入口,而且桌面与移动端都能查看。
集成的流程很简单,看文档就基本能搞定。部署脚本需要导出日志,并且上传,最后一步就是发送消息了。
log_path = "/Users/xxx/logs/20181015101010.log" |
效果大概是这样的:
最后
折腾这么久,整个部署流程其实还有可以优化的地方:
- 图片的压缩的还是应该本地处理,毕竟除了图床,原始文件的 repo 里面还有一份呢,会导致这个 repo 越来越大。
- 不带 alpha 通道的图片完全可以处理为 JPG。
欢迎大家分享自己的流程,一起讨论。