【问题标题】:Promotion of sql scripts to dev, cert,staging and prod将 sql 脚本推广到 dev、cert、staging 和 prod
【发布时间】:2019-12-09 11:06:05
【问题描述】:

我的工作中有三个部署环境,即 DEV、CERT 和 PROD。

到目前为止,还没有设置用于将 sql 脚本从一个环境升级到另一个环境的流程。但是,有讨论创建一个流程,开发团队将脚本提交到 git,Jenkins 作业将在构建期间在各自的环境中获取并执行脚本。我没有更多信息可以分享。无论如何!

现在,我们只是将针对不同错误的脚本、功能集提交到各自的 git 分支中以进行安全保管,并与数据库团队共享一组脚本以用于特定版本。但也有团队成员错过与数据库团队共享脚本、忘记在项目中提交/保存 SQL 等导致部署失败的情况

我想知道以我当前的设置将脚本从一个 ENV 提升到另一个 ENV 的更好方法。

期待与在工作中面临类似挑战的任何人进行良好的讨论,从而获得正确的方向

当前技术栈:SPRING、GIT、JENKINS、APACHE、JIRA

【问题讨论】:

    标签: java spring git jenkins web-applications


    【解决方案1】:

    对于这种情况有一些工具,我建议使用以下工具之一:

    1. flyway
    2. liquibase

    两者都是用于 sql 管理的开源工具。

    【讨论】:

    • 太棒了!但这很容易找到。我期待从企业应用程序开发的角度了解处理场景的不同方法。
    • @stack123 我在一个很大的解决方案中工作,我们在这种情况下使用 flyway,该工具非常棒且有用,您只需要知道如何使用它。
    • 我知道当数据库变更管理需要在独立于供应商的数据库中时,这些工具是更好的选择。我对 liquibase 不太熟悉,但对它进行了少量阅读。所以基本上,我们将有一个主变更日志文件和 .sql / xml 文件用于各自的功能/错误,当应用程序启动时,配置的数据库将更新为与变更日志文件中创建的查询同步。对吗?
    • @stack123 因为您使用的是 Jenkins,所以您可以创建一个作业来在不同的环境中执行脚本,这样您可以确保所有的 env 都在同一个版本中,如果作业也是如此在开发环境中失败然后修复脚本,然后再次部署
    • 当然。这就是我们计划要做的。我想如果我分享我的技术堆栈,我会从小组中获得更多不同的可能性。无论如何!
    猜你喜欢
    • 2020-01-04
    • 1970-01-01
    • 1970-01-01
    • 2022-01-16
    • 2019-04-15
    • 1970-01-01
    • 2018-06-09
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多