依赖性提升策略：孤立还是精心策划？

我们有很多相互依赖的应用程序和Web服务（一些面向公众的产品，一些内部和私有“后端”的一部分）。这些组件中的每一个都有4个环境（用于特定目的的服务器/节点集群）：

• 非生产
  • DEV-CI建立推动变更的集成开发环境；有助于工程师解决在本地无法复制的难以发现的错误
  • QA -隔离的质量检查/测试环境
  • DEMO -为业务利益相关者提供稳定的UAT环境
• 生产
  • LIVE -我们的现场/制作环境

代码升级是：（LOCAL开发人员的机器）=> DEV=> QA=> DEMO=> LIVE。

假设我们有一个名为的应用程序myapp，该应用程序由RESTful Web服务支持，该服务myws本身由一个名为的数据库支持mydb。

目前，我们拥有我所说的“ 策划 ”推广这些依赖关系之中：在myapp-dev指向myws-dev它使用mydb-dev。同样，myapp-qa指向myws-qa使用mydb-qa。与DEMO和相同LIVE。

问题是，无论何时我进行更改，例如myapp，这都需要我也对myws和进行更改mydb。但是因为每个DEV环境都指向其依赖项的DEV环境，所以这意味着我必须同时计划和部署这些更改。此外，如果一个构建变得不稳定/损坏，它通常会使其他上游组件崩溃；例如，如果开发人员在更改时破坏了某些内容mydb-dev，则myws-dev和myapp-dev群集通常也会变得不稳定。

为了解决这个问题，我针对我所谓的“ 孤立的 ”促销策略提出了一个建议：所有组件间的依赖关系都遵循以下准则：

• 上游的依赖关系取决于DEMO对它们的下游依赖环境，对于所有其非生产环境的（DEV，QA和DEMO）; 和
• 上游依赖项依赖于LIVE环境，生产环境依赖于下游依赖项

使用此约定，实际myapp-dev将指向myws-demo，而将使用mydb-demo。同样，myapp-qa也将指向myws-demo和mydb-demo。

我在这里可以找到的优势是构建稳定：DEMO特定组件的环境变得不稳定的可能性要小得多，因为DEMO没有在DEV和上进行严格的测试，代码就无法实现QA。

我可以发现这种方法的唯一缺点是，如果DEMO某个特定组件发生故障，则所有上游依赖项的所有非生产环境都将突然中断。但是我要反驳说，由于在DEV和上进行的测试，这种情况极少发生QA。

这已经得到了成为一个问题，很多开发者（比我更聪明，经验丰富）已经解决了，如果这个问题，其解决方案已经有名字给他们我不会感到惊讶（除了什么我打电话策划/孤立）。所以我问：孤立的促销策略的优点是否胜过任何缺点，在这里我可能忽略哪些缺点？

如果我没看错你的帖子，那么这个提议似乎并不能解决任何一个所谓的问题。

每当我对myapp进行更改时，这都要求我也对myws和mydb进行更改。但是因为每个DEV环境都指向其依赖项的DEV环境，所以这意味着我必须同时计划和推出这些更改

“孤立的促销策略”似乎只会使情况变得更糟。如果myapp v2，myws v2和mydb v2仅在DEV上，而myapp v2依靠mydb v2不会崩溃，那么当我尝试在DEV上运行myapp v2时，我将打出mydb v1 DEMO并崩溃。从本质上讲，您甚至不得不在开始使用myapp v2之前，要么不得不不断地覆盖孤岛，要么将mydb v2一直部署到生产。更重要的是，您永远不会在DEV上测试mydb v2，因此，如果它损坏了，您甚至要在DEMO上发现它才发现它，然后回到第一位。

在某种程度上，无论如何设置工作流程，您所描述的问题都是不可避免的，但可以将其最小化。技巧是确保严格定义mydb和myws之间的接口（以及myws和myapp之间的接口），并要求对该接口的所有更新都完全向后兼容。在我的工作中，我们有一个XML模式定义了我们的应用程序和服务之间的接口，我们的许多内部工具根本不允许我们对这些模式进行不兼容的更新。

此外，如果一个构建变得不稳定/损坏，它通常会使其他上游组件崩溃；例如，如果开发人员在更改mydb-dev时出现问题，则myws-dev和myapp-dev集群通常也会变得不稳定。

在我看来，这听起来像是一个严重的问题，但不是部署问题。损坏的数据库肯定会阻止服务和应用程序正常运行，但不应使它们变得“不稳定”。他们应该返回某种错误消息，以便在开发人员上运行myapp的任何人都看到“很抱歉，我们的数据库今天有问题”，而不仅仅是崩溃。

如果问题是数据库损坏根本导致了这些问题，那么您可以设置一些“临时孤岛”系统，让您说“ mydb DEV现在已损坏，请将所有myws DEV查询路由到mydb DEMO以获取暂且”。但这仅是在mydb DEV再次正常工作之前执行临时修复的一种方法。如果默认情况下所有内容都被“隔离”，那么您又回到了我上面描述的问题，因为根本没有人针对mydb DEV运行。

我觉得我可能以某种方式误解了您的建议，但希望这个答案至少可以使您清楚地理解了什么是误解以及如何最好地重新表述。