过去，Psono.com 是由 Odoo v11 驱动的。Odoo 是一个很棒的 CMS，但正如我们所学到的那样，更新非常困难。尤其是他们的网站模块在我们的测试过程中产生了很多问题。Odoo v11 将在 2020 年年底达到其生命周期的终点，所以我们被迫寻找解决方案。
我们考虑过不同的选项，或者是更新到 Odoo v13 并手动迁移所有内容和自定义，或者是雇佣别人为我们进行迁移，或者是完全迁移到一个新的 CMS。我们决定将 Psono.com 完全迁移，并继续在防火墙后使用 v11，稍后再进行迁移（我们尚未决定）。
做出这个决定的原因是：
- 我们只有很少量的内容需要为 Psono.com 迁移。主要是一些博客帖子。
- 迁移到 Odoo v13 将在两年后重现同样的问题，当 v13 到达其生命周期终点时，可能会有更多的数据需要迁移。
- 我们对 Odoo v11 的网站定制能力不太满意。所有东西都非常复杂，他们的模板存储在数据库中。
- 成本。雇佣别人进行迁移至少会花费我们 5000 美元，可能更多。
- Odoo 的社区非常活跃，但随着过去几年中许可证的变更以及功能和插件迁移到付费解决方案并将所有内容都放在付费墙后面，社区已经死了。
- Psono.com 主要是一个静态网站，具有静态内容。如果我们需要动态内容，我们可以通过 API 拉取。
旅程
在做出迁移决定后，我们不得不决定使用哪个框架。有经典的框架，例如我们使用过的 hugo，但它们的功能有限。在寻找替代方案时，我们在 node / react 世界中找到了些许解决方案。
我本想在这里写“优秀的解决方案”，但我认为在当前前端开发的破碎状态下，没有什么值得那个称号。你问破碎在哪里？还记得开发者们可以用一个 index.html 和 script 标签加载 jquery，然后开始开发网站的时代吗？现在你需要 npm 或 yarn，你需要理解 package.json，webpack 脚本，像 angular 或 react 这样的现代框架，它们都带有自己的客户端。JSX 或 typescript。功能如热重载无法可靠地工作（文件未被监控，有些修改需要完全重启，或者热重载触发过早，所以你不得不手动刷新）， 结果是你不断地杀死开发服务器并等待它们重新启动（至少在较大的项目中）。 （我怀念按下 F5 然后所有内容都在那里，没有任何问题的时光！）。更不用说每半年至少一个新框架或工具，旧工具每天都被弃用。 我可以轻易填满几页内容来抱怨当前前端开发的状态。不过，回到实际话题。
在缺乏理智替代方案的情况下，最好的选择（在我写这篇文章时）是 next.js 和 gatsby。 至少有些文章是这样推广它们的。两者在 Github stars 或 commits 上一样受欢迎。我们在初步评估中唯一能够发现的区别是 next.js 需要一个服务器组件，而 gatsby 创建的是静态网站（请现在不要杀我，如果有运行 next.js 而无需活动服务器的选项！:D）
所以我们玩了一会儿 Gatsby，看起来不错。下一步我们去寻找一个主题。Gatsby 是一个“新”工具，所以我们能找到的所有主题都还处于非常基础的状态。30 分钟和第三代预算后，我们有一个视觉吸引力的主题，至少覆盖了一些所需组件，我们开始修改它。
作为托管选项，您现在可以在多家提供商之间选择，主要有 Firebase、Netlify、Cloudflare、Vercel、简单的 GCP 云存储或 AWS Cloudfront、自有服务器、在 Kubernetes 上运行的 Docker 容器（我必须提一下！），…… （还记得每月花费 $5 租用一个带 PHP 和 MySQL 数据库的虚拟空间的旧时光吧 :D ……但这是另一个话题……）
在对它们进行比较、阅读一些评论并检查可能的组合（如云火在 Firebase 前面）后， 我们最初尝试了 Cloudflare。作为他们服务的超级粉丝，这是一个自然的选择，但遗憾的是他们的 wrangler 工具有问题。首先，它总是抛出错误，然后我们无法认证……初始错误第二天就消失了（可能一个新的 bash 起了作用），但认证问题还是存在。我相信我一定犯了一些错误，经过几个小时阅读他们的文档和尝试不同的解决方案后我放弃了。
Netlify 是另一个候选者，但你要么将它连接到 git 提供商并让他们构建它（我们想使用 Gitlab CI），要么手动上传构建输出。也许他们在某个地方有一个选项，可通过 API 上传构建输出，但我找不到一个。另一种选择是一个仓库，我们实际推送构建输出，但那看起来不必要地复杂……另一个对我来说的问题是他们的定价模式。他们按成员（!!!）收取相当可观的费用。记住，这只是一个静态网站。诸如“4× 带宽”这样的声明触发了“公平使用虚拟主机”时代的不良回忆，人们在你使用过多流量时会踢你……
作为第四种服务，我们尝试了 Firebase（它有一个好处，是免费的，适用于我们的目标带宽和请求）并且所有东西都开箱即用。他们的重定向功能有点有限，因此将旧 URL 映射到更漂亮的 URL 变得有点繁琐，但几个重定向规则之后一切正常。他们的定价看起来合理，你充费用服务器资源。应远离他们的所有额外服务以避免供应商锁定，我们只需要托管。
我们还简要检查了 Vercel，但他们要求使用 GitHub 账号登录，然后许可“在我名下操作”，在我注册前就让我却步了。
博客是最困难的迁移部分。最终我们手动复制了所有内容。对于一个较大的博客这是不可取的，但我们的博客只有十五篇文章。Gatsby 支持多种机制，但我们想要一种简单的方法，非技术背景的人也能创建新的博客文章。 我们决定使用 markdown，因此我们得学习如何指示 gatsby 读取 markdown 页面。实际机制花了我们大约半天时间，包括所有图像处理。一个不错的博客主题和图片又花了半天。
在迁移了所有内容并进一步大幅修改了主题后，我们用 Gitlab CI 自动化我们的部署，所以一个简单的推送就会触发我们的构建管道并部署到 Firebase。
为什么选择 Gitlab 而不是 GitHub？GitHub 出于历史原因处于领先地位。目前他们拥有至少 80% 的开发人员和项目。Gitlab 则提供功能。这就是为什么在过去我们选择了 Gitlab，因为 GitHub 多年没有真正的功能开发。自从微软收购 GitHub 并推出 GitHub Actions 后，这种情况已经发生了巨大变化，但如果 GitHub 想与 Gitlab 竞争，仍有很长的路要走。 所以对于我们来说，把所有项目托管在 Gitlab 上，是自然的选择。
结论
这就是我们现在的情况：
- Gatsby 作为 CMS
- 商业主题
- Markdown 驱动的博客
- Gitlab CI 自动化部署
- Firebase 托管
我们对这一结果非常满意，新网站看起来好多了！
