构建促销：您如何管理依赖项？

Question

我试图理解将我们的Java项目从Snaphot / Release策略切换到构建促销的所有含义。

一个显而易见的步骤是每个构建最终会创建一个可能一直到生产环境的工件，因此不再存在快照。但是，我应该如何管理从项目到其他工件的链接，这些工件可能会也可能不会被允许进行生产？

我很难找到关于这个特定主题的有价值的信息。当然，构建促销很多，但是根据迁移到构建促销的依赖管理的可见性较低。

我看到两个选择：

• 只能依赖先前已提升到生产环境的工件
• 当一个依赖于另一个工件时，构建的工件只能转到其依赖项的最后一个环境。也就是说，如果我依赖于允许进行测试而不是刺激的工件，那么我的构建将不被允许进入产品

是否有关于此主题的行业标准？还是最佳实践？

非常感谢您的帮助：）

编辑： 我们向Artifactory部署了三种工件：

• 库

• 的EAR

• EAR内的模块。其中一些是＆＃34; public＆＃34;想要与当前构建的EAR进行交互的任何EAR所需的图层

我们将EAR部署到JEE服务器。我们的库和公共层部署到Artifactory并打包在EAR中，因此它们不直接部署在JEE容器上。

一个项目构建了几个模块，所有内容都包含在EAR及其依赖项中。一个项目可能依赖于另一个项目的模块以及它变得复杂的地方......

Answer 1

我们区分“可部署工件”和“库”。

可部署的工件（如耳朵，战争，独立的罐子）通过管道，因此它们在不同的步骤中得到提升和测试。它们不能是任何其他工件的依赖项。

另一方面，库不被提升。当它们构建时（作为发布版本），立即可用作所有其他工件的可能依赖项（发布版本包括单元测试和一些集成测试）。当它们用于可部署的工件时，它们会被间接测试和提升。