我们有一个 Web 应用程序,其中包含系统操作员可以更改的一堆内容(例如新闻和事件)。有时我们会发布软件的新版本。该软件被标记并存储在颠覆中。但是,对于如何最好地控制可能独立更改的内容,我有点担心。人们使用哪些机制来确保以可以重新创建站点或至少受版本控制的方式存储和版本化内容?
3 回答
当您确定两组具有自己生命周期的文件(一方面是软件文件,另一方面是“新闻和事件”)时,您就会知道:
- 您不能同时对它们进行版本控制
- 你不应该贴上相同的标签
您需要单独保存“新闻和事件”文件(在 VCS 或 Ian Jacobs 建议的数据库中,或在 CMS - 内容管理系统中),并找到将拖链链接在一起的方法(一个 id、一个时间戳,元标签,...)
不要忘记,您不仅在谈论生命周期方面的两组不同文件,而且还谈论不同性质的文件集:
考虑 S.Lott 在这个 SO 问题“资产管理是源代码控制的超集”中引入的术语
- 软件文件:基础设施信息,即“代表企业信息资产的处理”。您的代码是该资产的一部分,并由 VCS(版本控制系统)管理,作为配置管理规程的一部分。
- “新闻和事件”:企业信息,即数据(未处理);这通常分为内容管理器和关系数据库。
所以不是所有的东西都应该在 Subversion 中结束。
将所有内容保存在 DB 中,并为 DB 的每个事务提供时间戳。这样,您就可以保留标准数据库备份,并在最坏的情况发生时在您想要的任何日期加载站点内容。
我想部分答案取决于您使用的 CMS 以及您的网络应用程序的设计方式,但总的来说,我会将新闻项目或事件等数据视为“内容”。换句话说,它不是您的应用程序的一部分——它是您的应用程序处理的数据。
当然,您的 CMS 代码和应用程序代码之间会有版本控制问题。您可以通过定义两者之间的接口来管理它。就个人而言,我会将数据作为 XML 发布到 Web 应用程序,这使您可以使用 XML 模式来准确定义 CMS 需要生成什么,以及 Web 应用程序应该期望处理什么。
这应该意味着 Web 应用程序中的大多数更改都可以在不对数据呈现进行相应更改的情况下进行。当功能更改需要这样做时,您可以创建架构的新版本并继续取得进展。在这种情况下,我将使用 Web 应用程序代码检查架构,但使用 YMMV。
这并不容易,如果您需要 CMS 中的其他数据字段,它会再次变得更加复杂。期望计划一个相当复杂的发布过程(也取决于您的开发-测试-验收-生产场景的复杂程度。)
如果您没有使用 CMS,那么您应该考虑一下。(当然,如果操作非常小,它可能仍然属于可以接受手工操作的类别。)简单地将原始数据放入版本控制系统并不能解决问题 - 您需要能够控制将数据发布到 Web 应用程序的格式。几乎可以肯定,这种格式应该是供软件使用的,因此通常不适合编写新闻或事件的那种人手动编辑。