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

Question

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

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

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

我看到两个选择：

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

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

非常感谢你的帮助 ：）

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

• 图书馆

• 耳朵

• EAR内的模块。 其中一些是任何想要与当前构建的EAR交互的EAR所需的“公共”层

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

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

Answer 1

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

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

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