我正在开发一个应用程序，该应用程序仅作为另一个Web应用程序的扩展存在，并且它所做的一切都是在其他服务中显示/修改数据。
该第三方API使得许多调用都包含用户定义数据的ID，并且随着对这些用户定义实体的更改，应用必须紧随其调用的更新。当前，这来自配置。用户定义数据的更改来自我们的客户，该客户是第三方服务的管理员。在最佳情况下，与用户定义数据的更改将与我们协调以锁定步骤更新配置。在最坏的情况下，事情破裂了，我们必须找出原因。
此外，我们的应用程序实质上扩展了系统中的实体，这也是通过ID扩展到其实体中的。为了使一切正常工作，我们的实体必须在其系统中所在位置处于适当状态的状态下，与系统中的实体相对应。
我们只是刷新了一个沙箱，所以我们将所有的prod数据推送到了沙箱实例，并且我们必须修复更新的测试环境配置。幸运的是，这基本上只是复制prod配置。这很乏味，并且与我们集成的第三方相关的所有设置都混杂在一起。我想我已经识别了所有这些对象，并在我们的Wiki中添加了几页有关刷新发生时的处理方法的页面。至少在大多数情况下，我还消灭了与我们扩展的其他系统实体有关的数据。我们还需要在第三方系统中对数据进行加扰，因为这都是真实的客户信息。有很多脚本，它们需要更新，因为它们不会在刷新之外运行，并且随着开发的进行，它们已经过时了。我添加的Wiki页面也涵盖了这一点。
此时，他们将要提出功能请求，我们将不得不管理沙箱以创建与新功能的新配置设置相对应的实体，然后当我们将功能投入使用时，我们必须进行确保他们已在prod服务中创建了新实体，获取了这些ID，并确保prod配置与prod服务匹配。沙盒和产品服务将在开发过程中发生分歧，直到下一个沙盒从产品中刷新为止，测试环境将再次中断，我们需要更新配置，清洗应用程序的状态，并扰乱包含客户数据的实体。
每当出现“必须有更好的方法”时，我都提到要为与我们集成的第三方构建模拟器，至少在开发的早期阶段就打破依赖关系，这将使开发的时间增加一倍以上。未来的任何新工作，并且短期内耗费更多精力。我们太小了，我们负担不起。此外，在某个时候上线之前，您仍然必须在沙箱上运行您的应用程序。到目前为止，我们最多没有正式的质量检查，我们会进行离岸手动测试。我有一些UI冒烟测试和皮下E2E测试，而且我只是手动行使自己的新功能，似乎足以确保我不会造成灾难。
API可以通过某些方式公开一些当前用户定义的设置，可能有一项工作看起来是根据字符串匹配来保持ID同步，但是这取决于这些值的变异取决于所配置的匹配项。这是同样的问题。我们的应用程序几乎每个方面都很脆弱，如果第三方更改了错误的内容，该应用程序将会失败。
据我所知，我正在对集成运行状况进行某种形式的持续检查，这种检查每天运行并在我们停止进行某些API调用时停止运行。它需要将暂时性错误与合法更改的内容区分开来，并最终需要配置更新，然后我们仍然需要查找新的ID，重新配置，具体取决于受影响的应用重启部分，在最坏的情况下，与他们的管理员联系，了解他们对第三方所做的更改（通过修改第三方），或者通过修复程序或让他们将其更改回来。幸运的是，至少他们非常关心我们的应用程序的工作，这已成为他们业务的核心。
所有事情似乎都需要我们的管道批准才能完成。有什么建议么？我要忽略哪些工具/技术？