2

就更新 html/js 代码和资产（通过使用 Subversion）而言，我们有一个很好的升级客户网站的过程，我们对此非常满意。

但是，在升级数据库时，我们没有任何正式的流程。

如果我们将新表/字段添加到我们的开发数据库中，那么在将其推出到生产服务器时，我们必须记住我们的更改并复制它们。我们不能简单地将开发数据库复制到生产数据库之上，因为客户端数据会丢失（例如博客文章、帐户信息等）。

我们现在也在构建一个会遇到同样问题的网络应用程序。

有没有人有一个解决方案可以使这个过程更容易，更不容易出错？大型网络应用程序如何解决这个问题？

谢谢。

4

6 回答 6

1

我认为在开发过程中添加控制是最重要的。在我过去的一项工作中，我们必须编写所有数据库更改的脚本。然后将这些脚本传递给 DBA，并说明将它们部署在什么环境中。在一天结束时，您可以实施技术解决方案，但如果项目已正确记录（如果！！！），那么当需要部署时，开发人员应该记住迁移脚本以及代码文件。我的 $.02

于 2009-07-28T18:13:49.830 回答
0

我们几乎在每个项目中都有文件夹 migrations/，并且这里有所谓的“向上”和“向下”脚本 (sql)。每个开发人员都有义务编写自己的 up/down 脚本并根据测试环境对其进行验证。

还有其他用于迁移的工具和框架，但我们没有时间测试它......

有些是：DoctrineDB、rails 迁移、推进（我认为......）、capistrano 也可以做到......

于 2010-01-20T12:40:27.697 回答
0

我们基本上有与 Senad 类似的方法，我们在我们的 repo 中维护一个 changes.sql 文件，开发人员将他们的更改放入其中。当我们部署到生产环境时，我们：

对 QA 服务器运行测试部署：

  • 首先在QA服务器中复现生产环境（app & db）
  • 对 qa 数据库运行 changes.sql
  • 将应用程序部署到 QA
  • 运行集成测试。

当我们确定应用程序在 qa 中运行良好且对数据库进行脚本更改时（即，没有人忘记在 changes.sql 或引用等中包含他们的数据库更改），我们：

  • 备份生产数据库
  • 针对生产数据库运行 changes.sql 文件中的脚本
  • 部署应用程序
  • 清除 changes.sql 文件

所有的部署都是通过自动化脚本运行的，所以我们现在可以重现它。

希望这有帮助

于 2009-07-28T18:25:52.720 回答
0

在我看来，您的代码应该始终能够从头开始创建数据库，因此它也应该处理升级。它应该检查数据库中的字段以查看架构的版本并处理升级到最新版本。

于 2009-07-28T09:35:19.643 回答
0

我运气不错： http: //anantgarg.com/2009/04/22/bulletproof-subversion-web-workflow/

作者有一个数据库版本控制工作流程（带有 PHP 脚本），很不错。

于 2009-07-28T09:37:02.387 回答
0

一些框架具有处理数据库升级的工具。例如，rails 迁移非常好。如果您的平台没有方便的工具，您可以尝试对开发数据库进行脚本修改。

在我的公司，我们在一些最大的项目中使用这种模型：如果 X 是我们应用程序的刚刚部署的版本，并且它与最新的开发版本没有什么不同。我们为命名它的脚本创建一个新目录，例如 - version x + 1 并将其添加到 subversion 存储库。当开发人员想要对开发数据库进行修改时，他会创建一个名为“1 - do something.sql”的 .sql 脚本来进行修改（它们必须是不可破坏的），保存它然后在开发数据库上运行它。他提交 Web 应用程序代码和 sql 脚本。每个开发人员都做同样的事情并维护脚本的执行顺序。当我们需要部署 X+1 版本时 - 我们将 x+1 Web 应用程序代码和脚本复制到生产服务器，我们备份数据库，

之后，我们打开一个新的 (x + 2) sql 脚本目录并重复该过程...

于 2009-07-28T09:53:35.567 回答