自从 2017 年使用 Hexo+NexT 作为博客框架以来，已经过去好几个年头。就如前面那篇hexo使用Artalk评论系统 博客所言，由于 Alliot 之前对 NexT 主题与部分插件做了许多侵入式的魔改，基本没有对其做过日常的版本升级维护，因此，已经没有平滑升级的可能性。在一次插件失效的契机下，终于下定决心推倒重建。 本文记录了这一次重建的过程以及在维护模式上相比旧版本的改进。

旧版本

　　使用到的主要组件版本如下：

1
2
3

nodejs: 6.9.4
hexo: 3.2.2
hexo-theme-next: 5.1.0

日常维护

　　使用 NPM 作为包管理工具， 主题为文件形式置于 hexo 的 theme 目录下， 主题配置与主题资源文件同级。
　　代码仓库在 Github 与 Coding 同时托管， 提交时双写。
　　各组件几乎是装好就没有做过维护更新， 一堆的 deprecated 包。（PS: 符合许多公司老旧项目的现状）

持续集成

　　使用 Coding 托管的 Jenkins， 通过编写 Jenkinsfile， 实现在云端构建后发布静态文件到自己的 Web 服务器， pipeline 可见： hexo使用CODING CI部署静态文件到服务器。

痛点

　　正如前文所说， 我无法非常便捷的面对各种依赖更新， 长期以往，整个项目将变得非常难维护， 这不符合我写作的初衷。

新版本

　　所有组件均使用当下的最新版本， 代码仓库托管在 Github， 镜像到 Coding，仅在 Github 提交。

主题管理

　　使用 PNPM 作为包管理工具， Next 主题以 NPM 包的形式安装在 hexo 中。 这样的好处是我们可以像管理 NPM 包一样来管理主题的版本。
　　新版本的主题配置文件在 hexo 根目录下， 不再置于主题文件同级。
　　同时，我们对主题的自定义修改也通过Data Files 与Injector特性，以非侵入式的形式来完成。
这里可以参考 Next 主题的官方文档: Custom Files以及Injects

nodejs版本管理

　　类似 asdf管理多版本Terraform，这里同样使用 asdf-vm 来管理 nodejs 的版本， 可以参考 asdf-nodejs。

组件日常维护

　　Renovate 是一个专注于解决依赖问题的库，自动化的依赖项更新，支持多平台和多语言。
　　目前在 Github 上以 Github Apps 的形式，可以为接入此 Apps 的项目提供依赖更新监控相关的服务。
我们可以通过在 Github 仓库中启用 RenovateBot 机器人来自动管理依赖更新。

持续集成

　　使用 Github Actions 来实现， 基本流程与旧的 pipeline 区别不大。
　　不过由于 Alliot 的 Web 服务器在国内， Github Actions 的 Runner 在传输制品时因为网络原因导致传输速率十分慢（Github 的免费 Runner 均在海外）， 偶然的发现 Coding 制品库居然连通性还不错，因此 Github Actions 的发布流程改为了先传输到 Coding 的制品库，再远程 Web 服务器从制品库拉取， 这样就将发布时间降低到了秒级。
　　此外，这次还在 Github Actions 加入了 CDN 缓存刷新的逻辑，现在是在构建过程中刷新 CDN 缓存，相比之前的定时刷新更合理。
　　至于说为什么不再用 Coding Jenkins，有如下两个原因：
　　首先是由于 Coding 在镜像 Github 私有仓库时，需要的权限太大了，全 Full Access， 这也让人有点犹豫。
　　其次是 Coding Jenkins 自带的构建节点组件版本都比较低，在 pipeline 中构建自定义的环境需要花费一些时间，这会让整体构建时间变长。
　　最后，这 Github Actions 实在是太好用了，相比老前辈 Jenkins， Github Actions 简化了很多编写 pipeline 的流程， YAML 虽然有点费眼，但比起 Jenkinsfile 与 Groovy 还是好太多了，社区丰富的 action 拿来就用，优雅得不行。

优势

　　以上这样一通操作下来的得到的好处就是， 我再也不用担心太懒导致的博客各个组件的更新维护问题了。
　　当出现某个组件/包(包括 asdf-vm 管理的 NPM)有更新时， 依赖管理机器人都会帮我在仓库中提交 PR， 我只需要 review 一下，Github Actions 就会自动帮我完成更新发布等一系列操作，你，对这样的船新版本的 hexo 心动了吗？