Drupal部署：如何处理数据库？
我花了两天时间阅读有关 SO、博客文章、论坛等的问题。
其中大部分信息都是旧的。
我正在我的 Ubuntu 机器上使用 Drupal 7（带有 Drush）和 GitHub 进行存储库托管来构建一个网站。我可以通过 SSH 访问生产服务器。
在交付网站的第一个版本后，我必须添加功能并修复错误。
一位朋友告诉我将 SQL 文件存储在存储库中，然后从那里开始。
我的问题是：最好的方法是什么？对此有好的实践建议吗？
谢谢！
I've spend two days reading questions on SO, blog posts, forums, etc.
Most of that information, it's old.
I'm building a site on my Ubuntu box using Drupal 7 (with Drush) and GitHub for repo hosting. I have SSH access to the production server.
After I deliver the first version of the site, I'm gonna have to add features and fix bugs.
A friend told me to store my SQL file on the repo, and go from there.
My question is: what's the best approach? Is there a good practice advise about this?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不是 Drupal 专家，但一般来说，数据库部署很棘手 - 特别是如果您最终使用测试和生产环境，因为最终需要订购更改。我建议使用某种形式的“主脚本”来执行您需要的数据库更新。我们用查询来包装我们的查询，询问数据库您使用的是哪个版本，并且仅应用新的 SQL 更新。
I'm not a Drupal expert, but in general database deployments are tricky - especially if you end up with test and prod environments because changes end up needing to be ordered. I recommend using some form of "master script" that executes the database updates you need. We wrap ours with queries that ask the database what version are you on, and applies only new sql updates.
Drupal 中的部署是一个复杂的主题，因为 Drupal 本身对于配置管理的一般主题没有一个好的答案。 重大举措已经为 Drupal 8 的实现取得了重大进展，但现在，我们要解决存储在数据库中的内容和配置的尴尬问题。
至少，您将需要内容的数据库转储。从那里开始，它就变成了一系列潜在的论文。仅涉及一些：
您可以将 SQL 转储到存储库中，但我们认为没有必要，因为我们关心版本的所有配置都导出到代码中。所以 SQL 转储实际上相当于备份。
Deployment in Drupal is a complex subject, because Drupal itself doesn't have a good answer for the general topic of configuration management. A major initiative has made significant progress for Drupal 8 to get it there, but for now, we deal with the awkwardness of content and configuration both stored in the database.
At bare minimum, you will need the database dump for content. From there, it becomes an entire series of potential essays. Just to touch on a few:
You can dump your SQL into the repository, but we don't find it necessary since all configuration we care to version is exported to code. So the SQL dump really amounts to a backup.