依赖性提升策略：孤立还是精心策划？
我们有很多相互依赖的应用程序和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。 这已经得到了成为一个问题，很多开发者（比我更聪明，经验丰富）已经解决了，如果这个问题，其解决方案已经有名字给他们我不会感到惊讶（除了什么我打电话策划/孤立）。所以我问：孤立的促销策略的优点是否胜过任何缺点，在这里我可能忽略哪些缺点？