【问题标题】:Database data upgrade with versioning by environment数据库数据升级,按环境进行版本控制
【发布时间】:2021-07-16 05:41:04
【问题描述】:

我有一个 java 应用程序,我部署在各种平台上(使用 ansible)。

这个应用程序使用一个数据库,它有时需要获取架构更新,我使用 flyway 执行和记录/版本(作为软件依赖项)。

我现在面临更新所有平台上的数据的需要,但根据平台的不同使用不同的值。这不是架构更新,但仍然是构成我的应用程序主要结构的数据(它连接到的其他应用程序的列表),因此我希望它以类似于 flyway 的方式进行版本控制。

起初我想我应该在我的 ansible 配置中输入不同的数据,这似乎是有道理的,因为 ansible 知道各种平台。然后我认为这些信息会以某种方式传递给flyway,以便它执行所需的更新。 但是,如果使用“版本化迁移”来处理,我最终可能会遇到版本冲突,因为一个环境需要更新,而另一个不需要更新(通用版本控制与环境版本控制)。

flyway FAQ 稍微提到了这个问题,可以设置flyway.locations 属性,或者我可以使用ansible 设置的flyway 占位符?

我在正确的轨道上吗?还是我不应该完全使用flyway(它是要与DML一起使用,还是应该为DDL保留)?

【问题讨论】:

    标签: java deployment ansible database-migration flyway


    【解决方案1】:

    Flyway 可用于架构和数据更新。虽然它的主要目的是围绕版本控制架构更新。

    听起来您需要一种仅在特定环境中部署某些脚本的方法。 Flyway 提供了支持此工作流程的功能。但是,您需要决定最适合您的方法。

    这里有一些想法。

    使用不同的位置

    我能想到的最简单的方法是在它们自己的位置放置特定于环境的脚本。您还可以为“常用”脚本指定一个位置。

    部署时,您可以指定“通用”位置以及特定于环境的位置。比如:

    flyway migration -locations=common/sql, test/sql flyway migration -locations=common/sql, production/sql

    等等。

    shouldExecute 脚​​本配置和占位符

    另一种方法是使用 Flyway Teams 功能 shouldExecute。这让您可以定义一个布尔表达式来确定是否应该运行脚本。您可以从placeholder 注入一个值。有一个blog post 对此进行了更多解释。

    使用cherryPick 配置选项

    另一个 Teams 版本功能是 cherryPick,它允许您准确指定要部署的脚本。因此,您可能在每个环境中都有一个配置文件,其中包含一个 cherryPick 配置,用于指定要运行的确切脚本。这可能有点笨拙,因为您需要明确列出每个脚本,但它确实可以让您完全控制。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2011-09-16
      • 2010-10-29
      • 1970-01-01
      • 1970-01-01
      • 2010-10-01
      • 2011-02-18
      • 2011-09-25
      相关资源
      最近更新 更多