Content management system 如何实现大型网站的连续迁移？

我在一个每天更新3000多页的网站上工作。它已经建立在开源CMS上。但是，我们不能简单地继续定期应用热修复程序。我们需要更换整个系统，我预计需要在1-2年的基础上更换整个系统。当另一个系统正在运行时，我们没有工作人员来运行替换系统，因为这会导致重复工作。当我们在新网站上工作时，我们也不能有“代码冻结”

因此，这相当于驾驶时更换轮胎。或者在飞行中固定翅膀。或者各种各样的类比

这就引出了一个称为“持续迁移”的概念。我在这里阅读了这篇文章：

作者的建议是使用像Fastly这样的CDN。其思想是CDN允许您基于URL在传统系统和新系统之间切换。从理论上讲，这个主意听起来是个不错的主意，可以奏效。这篇文章声称，你可以用清漆来做这件事，但快速地使工作更容易。我对清漆不太感兴趣，所以我无法真正证实它的说法

我也不知道这是个好主意还是有更好的选择。我查看了Fastly的定价方案，但我无法将其含义转化为具体的价格点。我不理解这些神秘的云服务定价计划，它们对我来说毫无意义。我不知道该网站使用什么样的带宽。另一个机构管理该网站的服务器

有人能帮我了解一下使用在线CDN是否比使用Varnish之类的东西更好？有免费或更便宜的解决方案吗？有人能告诉我，每月或每年，这大约意味着什么吗？有没有其他更好的方法可以分阶段为大型网站推出新网站

---

谢谢

我想我对你的问题没有确切的答案，但我的答案可能有点帮助

我不认为CDN给你带来优势。这是因为你有不止一个系统

对代码的更改 在专业环境中，我习惯于安装三种不同的CMS。第一个是开发系统，通常在我的PC上。该系统用于开发扩展、修复单元测试支持的bug等。代码被提交到版本控制系统（如SVN、CVS或Git）。持续集成系统检查对RCS的提交。当特性被实现（或者某些bug被修复）时，将创建一个命名标签。然后将此标记版本安装在测试系统上，开发人员、客户和用户可以在其中测试实现。测试成功后，将在生产系统上安装此标记版本

乍一看，这看起来很耗时。但这并不是因为大部分步骤都可以自动化。最大的优点是客户可以在测试系统上测试更改。而且，仅在生产系统上发生错误的可能性很小。（前提是您的系统构建在相似/平等的环境上。）

对内容的更改 如果您的代码更改了内容的处理方式，那么当您的 CMS具有强大的工作流支持。这样，您就可以轻松地向工作流中添加步骤 如果内容是旧的并且必须为当前文档迁移，则此选项将终止。 这样，您就可以连续迁移内容

---

HTH

Varnish是一个缓存，而不是CDN。它拦截页面请求，并提供缓存版本（如果存在）

CDN将从非服务器位置（通常在云中）提供内容（图像、JS、其他资源等）

基于云的解决方案定价通常非常神秘，因为它是一项相当复杂的技术

我会小心不断的迁移。我在过去做过这两种方法（连续迁移和完全迁移），我不得不说，连续迁移是一种痛苦。这意味着每件事的管理时间都要加倍，并且假设您的需求在所有时间点上都是相同的

不幸的是，我想说的是，在1-2年的基础上进行适当的重建比持续迁移要好，但显然你最清楚这一点

我建议你也可以考虑混合方法。为自己构建一个导出工具，将所有内容保持在CSV/XML/JSON等可传输状态，以便在准备好后可以导入到新系统中。这意味着您可以在需要时将新的构建请求合并到新系统中（如果新系统与旧系统完全相同，那么新系统的意义何在），并且您可以保留所有内容。另外，您不需要一直构建和维护两个CMS