首发于范浩博科学院。之前一直在用Hexo推荐的releaseplan。缺点是我本地依赖Hexo环境，无法随时随地更新博客。为了摆脱Hexo环境的束缚，高效编写，有如下发布方案。在本文的发布方案中，Git仓库只托管md文件，通过Webhook通知服务器拉取md文件，然后执行构建静态文件的操作，完成一次发布过程。我的写作环境是Typora（Win10），博客发布在阿里云的ECS（CentOS）上，文章托管在GitHub上。随着需求迭代时间成本的增加，只能用碎片化的时间来写。于是，我的写作场景变成了这样：习惯用MarkDown写稿子，只需要一个MarkDown编辑器；写作空间不受限制，只要我有电脑；写作时间不确定，有灵感就可以写；在新题（包括Hexo推荐）的发布计划之前，先在本地编写MarkDown源文件，然后在本地构建静态文件，最后将静态文件同步到服务器。发布流程图如下：很明显，如果继续沿用之前的发布方案，每次更换写站点都需要安装Hexo环境，而且写站点和时间是有限制的，不符合需求.新方案的主要问题是本地受限于构建静态文件所需的Hexo环境，那么构建静态文件的操作是否可以放在服务端？发布流程首先看一下新方案的发布流程图：如流程图所示，整个发布系统涉及3个环境，分别是本地（写入）、Git仓库（托管md源文件）、服务器（web服务）环境。在服务端环境构建静态文件，所以只需要在服务端安装Hexo环境即可。一个完整的发布流程包括3个部分：流程①：编写流程；流程②：发布流程；过程③：施工过程；写作过程采用分枝开发策略。写入完成后，只需要将修改推送到相应的分支即可。.只要有MarkDown编辑器，任何文本编辑器，甚至Marko，你都可以随时随地写作。当然，你可能会说还需要Git环境？好吧，如果你是一个合格的编码员并且没有Git，你知道该怎么做！另外没有Git环境，也可以通过GitHub写。发布过程采用master发布策略。当需要发布时，需要将对应的开发分支合并到master分支中，然后再pushmaster分支实现发布。构建过程在这里使用了Webhook机制来触发服务器执行构建操作。对于构建脚本，请参阅Webhook脚本部分。当①和②流程完成后，Git仓库会向服务器发起HTTP请求，记录如下：收到构建请求后，执行构建操作。构建流程图如下：首先查看当前change分支，只有是master分支，执行pull操作拉取md文件更新，然后执行hexog完成静态文件的构建。Webhook脚本Webhook脚本是用PHP实现的，代码如下：主要流程方法如下：publicfunctionrun(){//checktokenif($this->checkToken()){echo'ok';}else{echo'错误';}fastcgi_finish_request();//返回响应if($this->checkBranch()){//检查分支$this->exec();//执行操作逻辑}}这里使用shell脚本来实现构建所需的所有操作，便于扩展。执行方法如下：publicfunctionexec(){//shellfile$path=$this->config['bash_path'];$result=shell_exec("sh$path2>&1");$this->accessLog($result);return$result;}构建shell脚本如下：#!/usr/bin/envbashexportNODE_HOME=/usr/local/nodeexportPATH=$NODE_HOME/bin:$PATHpwd='/data/html/hexo'cd$pwd/sourcegitpullcd$pwd$pwd/node_modules/hexo/bin/hexog总结了新发布方案和之前方案的区别：前者只需要在本地写md文件，博客服务器构建静态文件；后者在本地写md文件，需要在本地构建静态文件，然后博客服务器只同步静态文件。当然，有很多方法可以解决当前的问题，比如持续集成。本文仅提供发布思路。在项目生成环境中，我们可以很方便的应用这种发布思路，开发自己的发布系统。相关文章?启用Hexo开源博客系统(2017-03-01)
