许多CMS的一个特点是配置部分存储在数据库中，这模糊了什么是开发、什么是配置和什么是内容编辑之间的界限。这在很大程度上是 CMS 灵活性的影响，这是可取的，因为它由站点决定。
但是，如果您没有在您的站点中创建这样的区别，则意味着您的所有内容编辑器都需要精通 CMS 的所有细节，因为他们可以更改配置，甚至在某些 CMS 中，例如 Plone，也可以通过-网。
因此，您需要确保每个人仅有权更改他们需要更改的内容。这反过来又需要一个高度灵活和详细的权限系统，比如 Plone 的。
在这方面存在问题的典型站点的一个示例是，您从一两个同时也是管理员的内容编辑者开始，他们使用具有完全权限的帐户，通常他们使用管理员帐户进行内容编辑。当更多的内容编辑者到达时，他们只是被赋予管理员密码来做一个小的改变，然后成长为拥有更多的编辑职责，但继续使用管理员帐户。结果，编辑网站的每个人都可以做任何事情，而您甚至看不到后来是谁进行了更改。
在管理良好的站点中，内容编辑器无法编辑或更改站点运行所需的任何内容。假设您有一个包含产品类别的网站，其中每个类别还需要一个概览文档，那么编辑不应该有权删除概览文档，因为这样做会破坏所有小类别链接。您将需要确定编辑/管理角色（可能有很多）并确保每个角色都具有所需的权限，然后将角色分配给帐户。
如果您最终处于难以授予权限并且编辑者往往拥有的权限太少或太多的情况，这表明您未能正确地将内容与网站开发分开，并且可能需要考虑重组一些代码和/或内容。这当然会在没有详细许可系统的简单 CMS 上更快地发生，这可能表明您已经超越了系统（这将我们带到了 Plone IMO 的主要销售点：作为 CMS，您极不可能超越它，虽然它仍然很容易上手）。
您似乎想要对完成的网站进行持续集成测试，包括它的内容。这既是一个好主意，也是一个坏主意。首先不好：
我认为对内容进行持续集成测试是不可行的，而且有点误导。如果您允许编辑者在实时站点上编辑测试过的内容，这也是完全不可能的，因为他们可以随时随意破坏它，见上文。
但是对完成的站点进行测试并不一定是一个坏主意。不过，我不会将它作为持续集成测试的一部分。这是因为这些测试通常由代码更改触发。
我的建议是将设置分为开发和编辑。开发环境是本地开发服务器和持续集成设置的正常环境，加上编辑器可以测试新功能的测试服务器。
每次部署到测试服务器时，测试服务器都会获取内容副本，这通常会在每次开发迭代中完成几次。持续集成测试不应该有依赖于普通内容编辑器可编辑内容的测试，但是这些测试应该在每次运行时从头开始创建测试内容，作为测试套件的一部分。
然后，您还需要一个登台服务器，这是在其上完成内容编辑的服务器。它在每次开发迭代或编辑批准测试服务器上的功能时接收一次软件更新。在这台服务器上，完成了内容编辑，并且您有一个单独的测试套件用于该站点，测试内容的完整性，包括运行断开链接的报告等。一旦主编对内容更改感到满意，并且内容测试通过，然后将内容部署到生产服务器并公开。测试可以按需进行，也可以定期进行，比如每天一次。
当然，这种类型的设置只适用于拥有许多内容编辑器（可能有十个或更多）的大型网站。但在这些情况下，这绝对是有道理的。在较小的情况下，您可以摆脱临时服务器并将功能直接部署到生产服务器，并每晚运行一次内容测试以合理地快速捕获错误。