运行现代生产系统的任何人都知道关于测试，后跟渐变或分阶段的卷展栏，在长时间逐渐部署到运行系统的变化，以减少一次意外地取消一切的可能性。例如，我最后一次需要更改Google的核心DNS区域文件，更改是针对许多回归测试测试的，然后在24小时内部部署到Google的四个名称服务器中的每一个。 。回归测试检查变更似乎不会影响答案它不应该有，然后逐渐推出为自动化系统和可靠性工程师提供充足的时间，以注意意外问题并停止卷展栏。 NPM的设计选择是完全相反的。最新版本的颜色被提升为在所有这些依赖性之前在任何有机会测试它并且没有任何类型的渐进式卷展栏之前使用。用户可以通过钉住所有依赖项的确切版本来禁用这种行为。例如，这里是AWS-CDK的修复程序。这不是一个很好的答案，但至少有可能。 NPM和Package Managers的正确路径是在安装新包时停止更激先使所有依赖项的最新可能版本。相反，它们应该更喜欢使用包实际测试的依赖性版本，或者可以尽可能靠近那些版本。我称之为高保真的构建。相比之下，在周末安装了AWS-CDK和其他包的人得到了低保护版本：NPM插入了新版颜色，即这些其他包的开发人员从未测试过。用户必须在周末测试这个全新配置，并测试失败。高保真构建解决了测试问题和逐渐推出问题。 AWS-CDK作者在AWS-CDK作者中掌握了一个新版本的AWS-CDK作者并在新版本的AWS-CDK中推动新版本配置，无法通过AWS-CDK安装来获得新版本的颜色。此时，所有新的AWS-CDK安装都会获得新的颜色，但所有其他工具仍然不受影响，直到他们过于测试并正式采用新版本的颜色。有很多方法可以制作高保真构建。在Go中，包声明每个依赖关系的最低要求版本，这就是构建使用的，除非同一构建图中的其他约束请求更新的。然后，它只使用那个特定的更新，而不是周末刚刚出现的那个，并且完全没有任何人。有关此方法的更多信息，请参阅“Go的版本控制原则”。包管理人员不必完全采用Go的方法。例如，它足够了，可以记录用于其测试的AWS-CDK开发人员，然后在安装期间重用这些版本的版本。实际上，NPM可以在锁定文件中记录这些版本。但NPM安装新包不使用该软件包锁文件中的信息来决定依赖项的版本：锁定文件不传递。 NPM还具有新的NPM ShrinkWrap命令，它似乎可以解决命令问题。受到颜色破坏的大多数作者应该在今天的NPM Shrinkwrap上仔细看。 KEDOS到NPM为包装作者提供一种工具，以保护自己免受这种问题。但是，下一步是为了NPM，可以默认排列此类保护。然后在将新库包安装为依赖项时，需要相同的保护，而不仅仅是在安装命令时。所有这些都需要更多的工作。其他套餐管理人员也应该注意。 Marak通过突出大多数计划经理在自动采用新依赖性的政策的情况下突出了这些问题，使我们所有人都赢得了巨大的利益，而无需逐渐推出或任何类型的测试。修复这些问题是长期的。下次会更糟。