代码之家  ›  专栏  ›  技术社区  ›  Catchwa

在应用程序实例之间进行用户友好的数据迁移

  •  1
  • Catchwa  · 技术社区  · 6 年前

    我们有一个基于网络的系统,本质上是一个调查应用程序。 到目前为止,我们一直在将新调查直接加载到数据库中(作为flyway迁移)。这显然是站不住脚的长期,我们需要把创建新调查的权力交给管理员用户。其中一个方面是添加UI,以便管理员用户可以创建新的调查。

    然而,我们希望管理员用户在测试环境中创建并测试任何新的调查,然后再将其发布到生产环境中。由于这些调查非常复杂,在测试环境中设置的调查与在生产环境中设置的调查存在细微差异的风险。我的目标是消除这种风险。

    我的问题与我们可以实现的技术机制有关,这样管理员用户就可以在自助服务的基础上,“迁移”调查从他们的测试环境(他们在那里完成了所有的测试和验证)到生产环境,这样我们就有很高的信心,迁移的调查将以相同的方式设置。像Moodle这样的应用程序已经内置了这种功能。

    我考虑过:

    • 允许用户创建调查的校验和(可能基于所有元素的哈希代码),以便他们知道跨两个环境的调查是相同的。因此,问题是,试图找出这两个实例的调查之间的确切差异会令人恼火。
    • 编写一个将原始SQL转储为导出的UI,并允许这些用户将其散播到生产数据库中,但从很多角度来看,这是非常糟糕的
    • 构建我们自己的领域特定语言来描述这些调查——但编写输入/输出解析器似乎太复杂了
    • 将数据转储到JSON(考虑到它是一个RESTful web应用程序,大部分工作已经完成)并将其吸回

    在这个阶段,我倾向于使用JSON方法,但我很想听听我们可以轻松集成到Spring Boot应用程序中的任何其他想法或库,以帮助这一过程。

    1 回复  |  直到 6 年前
        1
  •  1
  •   Doe Johnson    6 年前

    老实说,通过引入独立实例来解决这类问题听起来是个糟糕的想法:不仅迁移部分很棘手。您必须始终确保兼容性。假设管理员使用了过时的版本或未配置 他的例子 正确(每个管理员的梦想)。即使迁移本身不会产生错误,最终结果也可能会有所不同(这正是您真正想要避免的)。

    据我所知,您目前将调查视为大量原始信息,以某种方式出现在数据库中,然后由应用程序显示。从这个角度来看,你显然无法区分测试调查和生产调查之间的区别。

    这就是为什么你真的应该扩展你的模型!

    这不仅仅是一项调查。有一个 调查草案 和/或 调查预览区 A. 调查创建过程 用户所经历的,从草稿中旋转生产调查的过程,等等。

    如果您将这些概念添加到应用程序中,那么您描述的用例应该很容易实现(您已经提到了一个计划好的UI,对吧?)。

    希望我能帮助你。抱歉,我知道它不能完全回答你的问题。