【问题标题】:Code & data tracking / deployment代码和数据跟踪/部署
【发布时间】:2011-03-28 11:14:01
【问题描述】:

很长一段时间以来,我们一直将数据保存在项目的存储库中。我们只是把所有的东西都放在 data/sql 下,每个表都有自己的 create_tablename.sql 和 data_tablename.sql 文件。

我们现在刚刚将第二个项目部署到 Scalr 上,我们意识到它有点混乱。

我们的部署方式:

我们有一个“打包”脚本集合,将项目拆分为 3 个档案(数据、代码、静态文件),然后我们将这些档案存储在 S3 上的 3 个单独的存储桶中。

每当一个角色启动时,它会下载一个文件(取决于角色:数据、nfs 或 web),然后“解包”脚本为每个角色设置所有内容,将数据加载到 mysql,设置nfs等

我们这样做是因为我们不想保存服务器图像,我们总是从 vanilla 实例开始,我们使用各种内部构建的脚本从头开始安装所有东西。启动时间不是问题(我们在 9 分钟内就可以使用农场)。

问题在于,每当我们尝试设置新的开发版本(在任何时间点,一个项目大约有 4 个开发版本)时,都很难找到正确的数据库版本。此外,一旦我们投入生产,git 就会开始窒息,因为 sql 文件最终总计大约 500mb。

问题是:

其他人如何管理数据库?我一直在寻找可以轻松将数据从生产环境转移到开发环境以及将数据从开发环境迁移到生产环境的方法,但没有发现任何问题。

【问题讨论】:

  • 为什么要将数据从 dev 迁移到 prod?
  • @sheepsimulator - 许多框架(例如 Magento、ATG 等)将配置数据存储在需要移植以复制开发/登台环境的数据库中

标签: deployment cloud database-management dev-to-production scalr


【解决方案1】:

您应该认真看看 dbdeploy (dbdeploy.com)。它被移植到多种语言,主要是 Java 和 PHP。它集成在 Ant 和 Phing 等构建工具中,并允许轻松共享所谓的 delta 文件。

一个增量文件总是包含一个部署部分,但也可以包含一个撤消部分。当您提交您的 delta 文件并且其他开发人员检查它时,他只需运行 dbdeploy,所有新更改都会自动应用于他的数据库。

我将 dbdeploy 用于我的开源博客,因此您可以查看 delta 文件的组织方式:http://site.svn.dasprids.de/trunk/sql/deltas/

【讨论】:

  • 这里有个关键点“undo”。任何像样的数据库部署过程都必须具有一步回滚功能,否则您有一天被抓住......
  • 看起来不错。此外,我可以将其分解为两个分支(dev、prod),我们可以轻松地将 dev 更改与生产更改分开跟踪,因为 dev 更改更有可能被还原并且并不总是使其成为 prod。我想知道在这种情况下它会如何管理版本。
  • 好吧,由于 delta 文件通常包含特定功能而不是版本,您可以从版本控制中删除该 delta 文件,然后您应该没问题(肯定是在应用撤消部分之后,而不是之前)。
【解决方案2】:

我如何理解您的主要问题是其他人在将 SQL 数据从开发迁移到生产中的经验。

我使用 Microsoft SQL Server 而不是 My SQL,所以我不确定我的经验是否可以直接使用。不过这种方式效果很好。

我使用 Visual Studio 2010 Ultimate 版本比较两个数据库中的数据。 Vinsual Studio Team Edition 2008(或数据库版)中也存在相同的功能。你可以阅读http://msdn.microsoft.com/en-us/library/dd193261.aspx 来了解它是如何工作的。您可以比较两个数据库(dev 和 prod)并生成用于修改数据的 SQL 脚本。您可以轻松地从比较中排除某些表或某些列。您还可以检查结果并从脚本生成中排除一些条目。因此,可以轻松灵活地生成可用于部署数据库更改的脚本。您可以从结构上单独比较两个数据库的数据(模式比较)。因此,您可以使用来自 prod 的数据刷新 dev 中的数据,或者生成将 prod 数据库修改为 dev 数据库的最新版本的脚本。我建议你看看http://www.red-gate.com/(如http://www.red-gate.com/products/SQL_Compare/index.htm)的这个功能和一些产品。

【讨论】:

    【解决方案3】:

    查看capistrano。这是 ruby​​ 社区用来部署到不同环境的工具,我发现它非常有用。

    此外,如果您的部署开始受阻,请尝试使用 Twitter 构建的名为 Murder 的工具。

    【讨论】:

    • 我并不担心部署步骤本身,而是担心部署与生产/开发环境相结合。我们经常必须在我们之间以及与现场环境共享数据库(结构+数据)。此外,git 正在阻塞我们的 sql 文件。
    【解决方案4】:

    我个人会看蟾蜍

    http://www.toadworld.com/

    少于 10k ;) ... 将分析数据库结构,生成脚本来修改它们并迁移数据。

    【讨论】:

      【解决方案5】:

      解决方案的一部分是在单个位置捕获每个代码模块的版本及其对应的数据资源,并进行比较以确保一致性。例如,增加你的版本号,比如说,customer_comments 模块将需要一个相应的 SQL 增量文件来将相关的数据库表升级到数据的相同版本号。

      例如,查看 @AlanStorm 记录的 Magento 的 core_resource approach

      干杯, 京东

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2022-09-27
        • 2014-03-10
        • 2018-04-27
        • 2017-12-20
        • 1970-01-01
        • 1970-01-01
        • 2018-05-20
        • 1970-01-01
        相关资源
        最近更新 更多