首发于 樊浩柏科学院
之前一直在使用 Hexo 推荐的发布方案,缺点是本地依赖 Hexo 环境,无法随时随地地更新博客。为了摆脱 Hexo 环境约束进而高效写作,有了下述的发布方案。
本文的发布方案中,Git 仓库只是托管 md 文件,通过 Webhook 通知服务器拉取 md 文件,然后执行构建静态文件操作,完成一个发布过程。
我的写作环境为 Typora(Win10),博客发布在阿里云的 ECS(CentOS)上,文章托管在 GitHub。
需求迭代
随着时间成本的增高,只能利用碎片时间来进行写作。因此,我的写作场景变成了这样:
- 习惯使用 MarkDown 写原稿,有 MarkDown 编辑器就行;
- 写作场地不限定,有电脑就行;
- 写作时间不确定,有灵感就写;
新的问题
之前(包括 Hexo 推荐)的发布方案,都是先本地编写 MarkDown 源文件,然后本地构建静态文件,最后同步静态文件到服务器。发布流程图如下:
显而易见,若继续使用之前的发布方案,那么每当更换写作场地时都需要安装 Hexo 环境,写作场地和时间都受到限制,不满足需求。
新的方案
问题主要是,本地受制于构建静态文件时需要的 Hexo 环境,那么是否可以将构建静态文件操作放到服务器端?
发布流程
首先,看下新方案的发布流程图:
如流程图所示,整个发布系统共涉及到 3 个环境,分别为本地(写作)、Git 仓库(托管 md 源文件)、服务器(Web 服务)环境。在服务器环境构建静态文件,因此只需要在服务器端安装 Hexo 环境。
一个完整的发布流程包含 3 个部分:
写作流程
采用按分支开发策略,当写作完成后,只需要 push 修改到对应分支即可。只要有 MarkDown 编辑器,以及任何文本编辑器,甚至 马克飞象 都可以随时随地写作。
当然,你可能说还需要 Git 环境呀?好吧,如果你是一名合格的 Coder,竟然没有 Git,你知道该干嘛了!再说没有 Git 环境,还可以通过 GitHub 来完成写作。
发布流程
采用 master 发布策略,当需要发布时,需要将对应开发分支 merge 到 master 分支,然后push master
分支,即可实现发布。
构建流程
这里使用到 Webhook 机制,触发服务器执行构建操作,构建脚本见 Webhook 脚本 部分。
当流程 ① 和 ② 结束后,Git 仓库都会向服务器发起一次 HTTP 请求,记录如下:
当收到构建请求后,执行构建操作。构建流程图如下:
首先检查当前变更分支,只有为 master 分支时,执行 pull 操作拉取 md 文件更新,然后再执行 hexo g
完成静态文件的构建。
Webhook脚本
Webhook 脚本使用 PHP 实现,代码如下:
主流程方法如下:
public function run()
{
//校验token
if ($this->checkToken()) {
echo 'ok';
} else {
echo 'error';
}
fastcgi_finish_request(); //返回响应
if ($this->checkBranch()) { //校验分支
$this->exec(); //执行操作逻辑
}
}
这里使用 shell 脚本实现构建所需的所有操作,方便扩展。执行操作方法如下:
public function exec()
{
//shell文件
$path = $this->config['bash_path'];
$result = shell_exec("sh $path 2>&1");
$this->accessLog($result);
return $result;
}
构建 shell 脚本如下:
#!/usr/bin/env bash
export NODE_HOME=/usr/local/node
export PATH=$NODE_HOME/bin:$PATH
pwd='/data/html/hexo'
cd $pwd/source
git pull
cd $pwd
$pwd/node_modules/hexo/bin/hexo g
总结
新发布方案与之前方案的区别是:前者只需本地编写 md 文件,博客服务器构建静态文件;后者本地编写 md 文件后,需要本地构建静态文件,然后博客服务器只同步静态文件。
当然,有很多办法可以解决当前问题,比如可以使用 持续集成。本文只是提供一个发布思路,在项目的生成环境中,我们也很容易应用上这种发布思路,开发出自己的发布系统。
相关文章 »
- 启用Hexo开源博客系统(2017-03-01)
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。