使用用户生成的内容进行自动化数据库部署（la CMS）
在过去的几年里，我的团队越来越多地关注 CMS。我们也越来越多地进行持续集成。事实证明，协调两者是很困难的。更糟糕的是，我们同时使用 LAMP 和 .NET 站点，因此我们的脚本非常适合这两种站点。
我们为每个站点本地、集成、暂存和生产提供四种环境。内容输入和文件上传定期发生在生产站点上。开发显然是从本地开始并逐步向上的。
我可以在构建服务器上实现哪些方法或技术，以自动将数据和架构更新从开发环境推送到生产环境，而不会覆盖用户生成的内容？相反，我如何（以及何时）自动将用户生成的数据绘制到开发环境中？
My team has been getting more and more into CMSes over the past couple years. We have also been getting more and more into continuous integration. Reconciling the two has proven to be difficult. To make it even worse, we do LAMP and .NET sites so our scripts ideally work for both.
We have four environments for each site local, integration, staging and production. Content entry and file upload regularly occur on the production site. Development obviously starts locally and works its way up.
What are some of the methods or techniques that I can implement on my build server to automatically push data and schema updates from development environments into production without overwriting user-generated content? Conversely, how (and when) can I automatically draw user-generated data down into the development environments?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的数据库中将有 3 种需要担心的事情。
1）模式，可以在DDL中定义。
2）静态或查找数据，可以在DML中定义。
3) 动态（或用户）数据也可以在 DML 中定义。
通常，对 (1) 和 (2) 的更改应该使用它们相互依赖的代码投入生产。 (3)永远不应该上去，但如果当时与生产环境同步，则可以复制到开发环境。
当然，事情比这复杂得多。要实现 (1) 可能需要将现有架构/DDL 转换为特定的更改语句，并且如果数据类型或位置发生变化，还可能需要数据操作。要实现 (2) 需要与代码构建同步，这在复杂的环境中可能会变得很困难。
有很多工具，如果您需要自动化，那么您可能需要熟悉它们的人的建议。
我使用一个非常简单的方案，其中所有架构更改都反映在 SQL 构建脚本中，并且还添加到更改 SQL 脚本中，其中包括执行任何所需转换所需的所有 SQL。这对我来说效果很好，但我的场景非常简单（1 个人，1 个服务器），因此不典型。
然而，任何成功的关键是在进行变更时定义变更所需的工作。仅更改开发数据库然后在部署时执行修复的简单方法是一场灾难。
You will have 3 sorts of things in your database you need to worry about.
1) The schema, which can be defined in DDL.
2) Static or lookup data, which can be defined in DML.
3) Dynamic (or user) data which also can be defined in DML.
Normally changes to (1) and (2) should just go up to production with the code they are mutually reliant on. (3) should never go up, but can be copied to development environments if they are in sync with production environments at that time.
Of course it is much more complicated than that. To get (1) up may require converting exsiting schema / DDL into specific alter statements, and may also require data manipulation if data types or locations are changing. To get (2) up requires synchronisation with the code build which can become hard in complex environments.
There are many tools out there and if you require automation then you probably need advice from someone familiar with them.
I use a very simple scheme where all schema changes are reflected in a SQL build script, and are also added to a changes SQL script which includes all SQL required to perform any required transformations. This works well for me but my scenario is very simple (1 person, 1 server) and is therefore atypical.
However the key to any success is defining the work required for the changes at the time the change is made. The naive method of just changing the development DB and then performing remediation at deployment time is a disaster.
对于 A），最好的办法是使用优先级系统。您的内容是“默认”的，而用户内容“覆盖”它。而且这个内容在两个不同的地方。因此，您无需处理任何类型的合并过程即可更新您的内容。您的数据可以位于不同的目录中，或者在数据库中以不同的方式标记，无论如何。这样做的缺点是，您不能仅使用基本的开箱即用服务器功能来服务器数据，除非您在生成链接时进行实际映射。
即您可以拦截 /site/images/icon.png 并提供 /site/images/default/icon.png 或 /site/images/client/icon.png 或者当您写出页面时您可以进行检查并发送正确的 URL，以便服务器可以直接为它们提供服务。
第二，至于您何时可以使用客户数据，这更多的是一个法律知识产权问题，您需要与客户讨论他们是否a）愿意并且b）甚至有能力与您分享他们的内容。之后，技术就很简单了。
For A) the best thing is to use a priority system. Where your content is "default" and user content "overrides" it. And this content is in two different places. So, you update your stuff with no chance of having to deal with any kind of merging process. Your data can be in a different directory, or flagged differently in the DB, whatever. The downside of this is that you can't just use basic out of the box server functionality to server the data up, unless you do the actual mapping when the links are generated.
i.e. you can either intercept /site/images/icon.png and serve up either /site/images/default/icon.png or /site/images/client/icon.png or when you write the pages out you can do the check there and send out the proper URLs so the server can service them directly.
For the second, as to when you can use the clients data, that's more of a legal IP issue that you'd need to talk to the client about whether they're a) willing and b) even capable of sharing their content with you. After that, the tech is straightforward.