博客架构分拆

令人瑟瑟发抖的寒冬中，时间迈入了 2019 年。一片萧条的大环境下，人们注定要为今后的生活付出更多艰辛与努力。微软，大洋彼岸的 IT 巨头，似乎觉察到这点，于是大手一挥送温暖：于今年 1 月 8 日宣告 GitHub 对个人开发者免费提供私密仓库服务，数量无限制。要知道，此前私密仓库是要每月耗费 7 刀巨资啊。

收到这份新禧礼物后，我激动地把分散到各处小作坊平台的仓库统一迁移到 GitHub 上，逛 GitHub 的频率随之陡增。就是在这样的背景下，发现 GitHub 有人 Fork 我的博客仓库。像本站这种不走量不推广，且国内不备案的边缘博客，理论上没人关注的，于是好奇地进到那货的 GitHub 主页，一看 ID 是新注册的，而且每天大批量的搜索 GitHub 并 Fork 开源的仓库，一天几十上百的 Fork，典型的自动化脚本操作。

没图你会说我吹牛逼，下面就是那个账户的异常活动：

既然我把博客仓库开源了，自然没有什么敏感数据在上面。不过对于这种扫库行为，心里依然略有芥蒂，于是微微一笑，把那个马甲账户 Block 了。

一个小思考

这件趣事也引发了我的一个思考，如果某个项目真的存在一些敏感数据，怎样在保证开源的情况下隐藏这些数据呢？在梦中我找到了答案：把项目的仓库分拆。基础框架和敏感数据拆分，后者移出到新的私有仓库，刚好可以合理用上 GitHub 无限免费私仓服务。

借助这个思路，顺便可以把文章和博客框架也分拆开，包括需要隐藏的元数据（Google-ID, Disqus 等）在内，可以把原始仓库分成三部分：

• Framework
• Posts
• Meta

拆分细节

Framework

作为通用模版而存在，方便别人对本站架构进行复用（虽然可能性约等于零），进一步贴近开源精神。

Posts

主要是文字创作内容，这可以很好的把 post 的更新记录从站点架构中分离出来，使两边的提交历史更加清晰明了。

Meta

对外透明，定义那些高度私人化、零复用价值的数据，即便这样，编译后的静态文件还是包含了这些数据，隐藏起来只是为了满足心里的仪式感，正所谓防君子不防小人。

工作流变化

分拆是个双刃剑，方便了内容管理，也给本地开发和线上的 CI 产生了阻力。为了解决这两个问题，我的解决方案如下：

1. 更新基础架构或者修改文章后，用脚本把三个零散仓库通过拷贝合并起来，成为一个完整的项目，再进行构建和测试。
2. 持续集成可以由 Framework 和 Posts 两个仓库触发。
3. Travis CI 的只对公开仓库提供免费服务，所以 Meta 私有仓库是不能够触发线上 CI 的，必要时，可以到 Travis CI 上手动触发 Framework 或 Posts 的构建，即可把 Meta 的更新进行部署。由于此部分内容更新频率极低，所以影响不大。

后话

分拆的作业看着简单，但是耗费了整整一天。仓库内容分离以及 Travis CI 的脚本修改需要点耐心。最后顺利成功了，自然也是小有成就感，博客的项目演进又往前迈进了一小步。