我有一个基于 python 的应用程序，其中包含大量模块 并与两个数据库交互:
- 元数据(在某些情况下需要更新)
- 客户数据 此应用程序可以在没有互联网访问权限的环境中手动部署。
在为此类系统实现更新机制时，最佳做法和注意事项是什么？ 几乎所有的信息都是关于打包和分发阶段 - 签名等，但我更关心更新过程本身。
我考虑过根据版本通过脚本处理 pip 包版本和元数据库的代码更新。 这引发了新的问题，例如:
该机制应如何处理具有某些副作用或先决条件的代码更新？例如用户配置的模式 文件已被更改 - 所以以前的配置应该转换为新的(我想它应该对用户透明)。 显然，这仅在从版本 X 更新到 Y 而不是在全新安装(可以分配默认值的位置)时完成。
应该如何处理，尤其是当我们有版本差距时？ - 比如客户端版本是1，最新是4 而需要转换的是从2到3。它应该是一个累积更新，将保存所有更新(1->2->3->4)并处理所有这些 用脚本？或者每个更新都应该独立存在，客户端应该运行一系列更新？
- 如果元数据数据库很大~GBytes。管理其更新的最佳方式是什么？显然不是每次都将整个数据库发送给客户端 - 计算两个版本之间的差异并仅发送带有 DML 指令的脚本的最佳方法是什么？
- 如何管理数据库和代码库版本之间的依赖关系？例如，如果数据库模式中的字段已更改 所以代码库版本也应该更新(代码版本 X 支持数据库版本 Y)？
- 在这些情况下应该如何处理故障恢复？例如，当安装大量 pip 包更新时 其中一个在中间失败了？如何恢复到以前的状态？除了复制文件，还有什么好的方法可以备份当前版本吗？
最佳答案
那么，您需要的是图表。是的，一个数据结构。我敢打赌你的图表将是有向的和非循环的 - DAG。如果没有，您很可能会遇到麻烦。
- 不确定你在问什么。但是没有版本差距。绝不。有一个完全确定的序列:v1 -> v2 -> v3(哇!看起来又是一个 DAG，不是吗？然而，这是您将要处理的最简单的一个:只是一个常规链表!)。一旦客户端的应用程序发现某处有更新，它就会向服务器请求一系列命令或步骤，以从当前版本升级到最新版本。它再次要求提供图表。然后它按照服务器的指示执行。
- 是的，计算增量。存储增量。顺便说一句，deltas 自然地表示为一个.. 图表。
GIT是一个著名的例子，对吧？更重要的是，通常改变整个架构以适应这种需要确实是有意义的——目前它通常被称为“事件源”:想法是你存储一个初始的——从未修改过的——状态以及长-长-到目前为止，这个状态发生的一系列变化。每次您需要一个实际状态时，您最好使用Google的map/reduce方法来……将整个变更集缩减为单个变更，这很简单地应用于初始状态状态从而产生实际状态。它速度非常快，易于测试，相信我，对于大型系统来说非常可靠(当然，只要存在数据持久性机制，并且在通过不稳定的网络传输时不会丢失任何更改)。 - 我不认为这是一个单独的问题。这是三角洲问题的一部分。似乎您正在尝试构建非常复杂的系统。有一条规则:没有简单的增量可以很好地适用于复杂的系统。结论？首先，想想你的三角洲。这都是关于他们的。
- 好吧，假设存在状态转换
version 1 -> version 2，则可能存在双重状态转换:version 2 -> version 1。附带说明:您可以通过“翻转”现有图的顶点来获得另一个(有向)图。这就是这里发生的事情:有“前向”图和由它生成的“后向”图。如果你想要更多的数学方法，你需要一个 group .有一个由这个想法驱动的 VCS - darcs .
关于python - 代码库应用更新机制设计，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/53701292/