CMS 暂存环境架构
我的公司开发了一个cms，但现在我们使用它一段时间后，我们偶然发现一个问题：所有的更改都与现场环境直接相关。如果您想对网站进行大修，有时您需要先完成所有工作，然后立即将所有更改发布到实时网站。
我现在谈论的是内容，而不是开发软件的开发/测试/登台/生产环境
我已经看到了解决问题的几种选择，但没有一个可以完全解决这个问题：
- 使用版本控制：版本 x 正在生产中运行，y 处于暂存阶段；
- 使用草稿/发布标志：所有草稿内容都远离实时站点；
- 使用两个数据库：一个用于临时环境，一个用于实时环境。
它们都存在问题：
- 新创建的页面的版本控制存在问题（生产时版本为空？）以及页面站点地图的更改（我们为此使用嵌套集）；
- 对于草稿，无法创建已发布页面的第二版本；
- 使用第二个数据库，您必须复制/同步您不希望在两个地方之间有所不同的所有数据：用户、用户组、权限等。
还有其他选择吗？最好是在用户层面上执行此操作，以便用户 A 可以开始大修，而用户 B 仍然能够发布新内容。但也许现在这太难了，我们现在只需要解决第一个问题。
附言。它是一个带有 MySQL 后端的 php、ZF 应用程序，但这对于我认为的架构来说应该不重要。
My company has developed a cms but now we use it for a while we stumble upon a problem: all changes are directly linked to the live environment. If you want to do a big overhaul of a site, you sometimes want to do all the work first and then publish all the changes to the live site at once.
I'm talking about content now, not a development/testing/staging/production environment for developing software
I've seen several options to solve the problem, but none can completely solve this problem:
- Use versioning: version x is running at production, y is at staging;
- Use a draft/publish flag: all draft content is kept away from the live site;
- Use two databases: one for the staging environment, one for live.
All of them have problems:
- Versioning is problematic for newly created pages (version null at production?) and changes in page sitemap (we use a nested set for that);
- For drafts it is not possible to create a second version of an already published page;
- With a second database you have to copy/synchronise all data you don't want to be different between the two places: users, user groups, permissions etc.
Are there other options? Preferably you want to do this on a user-lever, so user A can start a big overhaul and user B is still able to publish new content. But perhaps this is too difficult for now and we just have to solve the first problem for now.
PS. It is a php, ZF app with MySQL backend, but that shouldn't matter for the architecture I think.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
还有另一种策略，即拥有一个单独的内容管理存储库，内容可以从该存储库发布到不同的内容交付环境。 （因此是 3 个数据库，而不是两个。）
这是 SDL Tridion 使用的架构，根据我自己的经验，我知道它非常有效。我确信还有其他 WCMS 系统可以像这样工作，尽管我立即想到的唯一一个是 Bricolage。
There is yet another strategy, which is to have a separate repository for content management, from which the content is published to different content delivery environments. (So 3 databases rather than two.)
This is the architecture used by SDL Tridion and I know from my own experience that it is very effective. I am sure there are other WCMS systems that work like this, although the only one that immediately springs to mind is Bricolage.
执行此操作的方法是使用相对链接或根据站点配置文件中的值向链接添加前缀。
The way to do this is to use relative links or add a prefix to the links based on a value in the site's configuration file.
已经过去很长时间了，但我们现在有了一个多阶段 CMS，其工作原理如下。制作和分期树有两个方面。在嵌套集设置中，我们可以在一个数据库中存储多棵树。生产中的页面通过 UUID 链接到暂存区。
内容本身通过版本控制进行管理，其中版本控制表保存所有版本，实体表保存生产版本。因此，版本控制（用于暂存）比生产版本提前了一些步骤。这样我们还可以实现文本 blob 的自动保存（这只是另一个版本）。
It's been a long time, but we have now a multi stage CMS which works as follows. The tree of production and staging is two-fold. In a nested-set setup we can store multiple trees in one database. The page in production is linked to the staging with a UUID.
Content itself is managed with versioning where a versioning table holds all versions and an entity table holds the production version. The versioning is (for staging) thus some steps ahead of the production version. This way we can also implement autosave for text blobs (it's just another version).