现在的发布流程

这个博客是用 Hugo 生成的静态站点,使用 Transmit 上传到 Amazon S3,流程和原来的 FTP 上传没什么区别,比较源和目标,增量更新。Hugo 生成静态文件呢,建议把旧版本全部删除,再重新生成,原因大概是「Go 语言就是快」。结果就是新增一篇文章新增和更改的文件虽然不多,但所有文件的时间戳都变了,增量更新文件还得统统比较一遍。现阶段博客文章数量还不多,发布一篇文章已经需要十分钟左右候在那的手动操作,渐渐就不能忍了。

自动化发布

试用 Hugo 的时候,了解过从 GitHub 自动发布 S3 的玩法,但是示例用的是 TravisCI,需要 GitHub repo 是 public。虽然博客都没人看,但是把源码放入版本管理,改个错别字都得记录在案,光是想到有被人看到的可能性就觉得太羞耻了。

因为当时意识里 GitHub 一家独大,其实 GitLab CI 或 Bitbucket Pipelines 也是能用的,一叶障目了。

这类 CI / CD 服务的流程,简单归纳,你把代码提交到 git repo,编写一个配置文件(通常是 yaml),由 Service 自动运行,启动一个容器获取代码,编译,推送到发布服务器。

但是,这个配置文件怎么编写,还是得花时间学。然后,涉及到 AWS,用户验证、权限配置也挺麻烦的。

既然是静态网站,为什么不直接发布到 Netlify 或者 GitHub Pages,当初多少有些「我也是用过 AWS 的程序员」的意思。

Netlify

使用开放格式,把网站生成静态 HTML 文件的好处是我没有被紧密绑定到 S3(当然多少还是被绑定在 Hugo 上)

近来 Netlify 的评价很好,还是决定试一试。当然不是直接把静态 HTML 文件推送到 Netlify,而是它类似 CI 的功能。

登录 Netlify,点击 New site from Git

  1. Connect to Git provider: 支持 GitHub / GitLab / Bitbucket,支持 private repo
  2. Pick a repository: 选择你存放 Hugo 站点的 git repo
  3. Build options, and deploy!: Netlify 能识别出 Hugo 站点,如果没有特别需要,使用默认配置即可

点击 Deploy site ,稍等片刻,发布的站点就可以通过一个 netlify.com 的二级域名访问。之后可以再绑定域名,配置 HTTPS。

配置完成后博客发布的流程就变成了:本地编辑内容,git push,等一会让 Netlify 帮你完成其它工作。Netlify 和其它 CI 服务相比简化了配置的过程。

其它

为了编辑文章的便利,目前把图片和 markdown 文件放在一起,如果图片多了,可能会影响发布的速度。现在的想法是别多想,编辑流程照旧,之后再根据情况把比较吃资源的图片分离到 image.domain.com 就是了。

PS: macOS 平台上 ImageOptim 是很好用的图片压缩工具。