回滚的技术注意事项

当我们讨论后备保险策略时，我们经常听到客户同意回退策略，但从技术上讲，认为回退是不可行的。对于这个问题，我们的答案是，从技术上讲，几乎可以肯定能够回滚，但您当前的团队，流程和架构无法回滚。

当我们讨论后备保险策略时，我们经常听到客户同意回退策略，但从技术上讲，认为回退是不可行的。对于这个问题，我们的答案是，从技术上讲，几乎可以肯定能够回滚，但您当前的团队，流程和架构无法回滚。在基于Web的平台或邮局T系统中，无法回滚的最常见的借口是数据库架构不兼容。这个视图认为，对于主要的软件开发工作，因为它们可能会对数据库模式进行重大更改，因此存储的旧数据和新数据不兼容。这些修改可能导致数据库表关系的更改，候选关键字的更改，表列的更改，表添加，表合并，表分解和表删除。解决此数据库问题的关键是在扩展数据库模式时保留旧数据库关系和实体，至少在遇到需要回退到旧数据库的主要性能问题时。当您出于功能或性能原因需要传输数据以创建不同范例的各种数据库模式时，应考虑使用数据库触发的数据传输程序，或使用数据传输守护程序或第三方复制技术。当您达到或超过要求中指定的后备版本数时，此数据传输将停止。理想情况下，您可以在确认不需要在实施更改后的一到两周内回滚后关闭数据传输系统。理想情况下，您将限制此数据传输，而是将新数据写入新数据库表或列，将旧数据保留在原始数据库表和列中。在许多情况下，这种方法将满足您的需求。当您需要重新组织数据时，只需将微信小程序数据从新位置传输回执行回滚的时间段内的旧位置。如果需要更改数据库中列的名称或其在应用程序中的含义，则应首先打开数据库，修改应用程序，然后在将来发布新版本时修改数据库。 这是回退的一般原则的一个示例，即在一个版本中修改应用程序，然后在另一个版本中修改数据库。