前言
在使用 Wordpress 的过程中，我经常会担心一个问题，就是 IDC 服务商突然倒闭，或者因为某些问题被突然强制闭站（虽然微乎其乎），导致网站备份无法拷贝到本地，数据丢失。所以我都会设置日历，定期手动备份到本地。
而且在网站迁移的过程中，需要打包目录，导出导入数据库，还要考虑数据库版本及字符格式是否兼容。各种 Apache 配置， Nginx 配置，也要备份和还原。每个组件的升级，也都要考虑兼容性。
总之，如果是自行搭建的环境，升级和迁移都面临着很多的坑要填。故很多公司看到了商机，推出了集成管理平台，比如 Plesk ， cPanel 等。使用集成平台可以很方便地进行一键部署，定期备份，一键还原，快捷配置等功能，还有很多其他的附加功能。总之比自行部署少折腾了很多事情。不过价格嘛……
后来发现有人使用 Github 的 Pages 功能来搭建网站，刚开始感觉是不屑的，因为 Github 是存放代码的地方，即使是 Pages ，也应该是存放跟项目相关的文档，不应该薅羊毛似地用来搭建博客。
但随着对 Git 的使用越来越频繁，感觉如果将博客内容也用 Git 来做版本控制，分布管理，这样就能避免因为服务提供商的问题而导致的数据丢失，即使提交错了什么，也可以方便及时地进行回退修改。也不用担惊受怕地定期进行异地备份。
再后来就入坑了，既然有这么个大带宽，多线路的平台可以免费使用，何乐而不为呢？而且 Gitlab 本身似乎也并不抵触在其平台上搭建博客的行为。故找了个时间，对比 Hexo 和 Jekyll 后，最终选择了 Hexo 作为博客静态化框架工具。（各种优缺点就不说了，网上大把。）
方案
网上的各种 Hexo + Github Pages 的搭建方案也不说了，官方也有详细的搭建文档。主要是分享一下我结合工作上持续集成所搭建的方案：Hexo + Gitlab + Runner + Github Pages。
其中 Gitlab + Runner 是著名的开源 CI/CD 方案，就是传说中的持续交付，持续集成。
部署流程
编写好文章或改好配置后，将 Hexo 的博客文件夹提交到 Gitlab ， Runner 检测到 Gitlab 上的源码变动后，触发预先设置好的脚本，执行 hexo d -g , 将文章发布到 Gitlab Pages 上。
优势
这种方案相比于普通的 Hexo + Github 的优势在于：
- Hexo 和文章源码保存在两个地方：
Gitlab.com和本地。相当于异地存储，保证安全性。 - Runner 可以接手静态生成及文章发布，可以实现提交后不管的便捷。（即文章写好提交后，就可以去喝咖啡了。）
- 如果 Runner 部署在远程服务器上，文章提交后，可以直接关机走人。
- 灵活自由，可以预设 Runner 需要执行的命令，一步到位。
不足
当然这种方案的也有不足的地方，那就是配置略为麻烦，而且需要一定的 Gitlab + Runner 持续集成的知识及配置经验。
如果 Runner 部署在远程服务器，还需要付费购买远程主机（也可以将家里不用的 PC 作为远程服务器使用）。
其他
不熟悉 Gitlab + Runner 作为持续集成的话，也可以选择使用 Hexo + Github + Jenkins + Github Pages 的方式进行集成部署。各种集成的流程都是一样的，不一样的是使用的工具。
总结
磨刀不误砍柴工 ，项目持续集成化是一个趋势，博客也用持续集成虽然显得大材小用，但也正是因为如此，才让便捷更加便捷。