使用用户生成的内容进行自动数据库部署(la CMSes)

时间:2011-09-06 20:35:54

标签: database wordpress deployment content-management-system continuous-integration

过去几年,我的团队越来越多地进入CMSes。我们也越来越多地进行持续集成。事实证明,调和这两者很困难。更糟糕的是,我们使用LAMP和.NET站点,因此我们的脚本理想地适用于两者。

我们为每个站点本地,集成,登台和生产提供四种环境。内容输入和文件上载定期发生在生产站点上。发展显然是从本地开始并逐步发展起来的。

我可以在构建服务器上实现哪些方法或技术,以便在不覆盖用户生成内容的情况下自动将数据和架构更新从开发环境推送到生产环境中?相反,我如何(以及何时)自动将用户生成的数据绘制到开发环境中?

2 个答案:

答案 0 :(得分:1)

您需要担心数据库中有3种情况。

1)架构,可以在DDL中定义。 2)静态或查找数据,可以在DML中定义。 3)动态(或用户)数据,也可以用DML定义。

通常情况下,对(1)和(2)的更改应该使用它们相互依赖的代码进行生产。 (3)永远不应该上升,但如果它们与当时的生产环境同步,则可以复制到开发环境中。

当然,它要复杂得多。获取(1)up可能需要将现有模式/ DDL转换为特定的alter语句,如果数据类型或位置发生变化,也可能需要数据操作。要获得(2)需要与代码构建同步,这在复杂环境中会变得很难。

有很多工具,如果你需要自动化,那么你可能需要熟悉它们的人的建议。

我使用一个非常简单的方案,其中所有架构更改都反映在SQL构建脚本中,并且还添加到更改SQL脚本中,该脚本包括执行任何所需转换所需的所有SQL。这对我很有用,但我的场景非常简单(1个人,1个服务器),因此非典型。

然而,取得成功的关键是定义更改时所做的更改所需的工作。只是更改开发数据库然后在部署时执行修复的天真方法是一种灾难。

答案 1 :(得分:0)

对于A)最好的事情是使用优先系统。您的内容是“默认”,用户内容“覆盖”它。这个内容分为两个不同的地方。所以,你更新你的东西,没有必要处理任何类型的合并过程。无论如何,您的数据可以位于不同的目录中,也可以在数据库中以不同方式标记。这样做的缺点是你不能只使用基本的开箱即用服务器功能来提供服务数据,除非你在生成链接时进行实际的映射。

即。您可以截取/site/images/icon.png并提供/site/images/default/icon.png或/site/images/client/icon.png,或者当您编写页面时,您可以在那里进行检查并发送正确的URL,以便服务器可以直接为它们提供服务。

对于第二种,关于何时可以使用客户数据,这更像是一个合法的知识产权问题,你需要与客户谈论他们是否a)愿意和b)甚至能够分享他们的与你相关的内容。在那之后,技术很简单。

相关问题