java – 构建升级:如何管理依赖项?

前端之家收集整理的这篇文章主要介绍了java – 构建升级:如何管理依赖项?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我试图了解将我们的 Java项目从Snaphot / Release策略切换到构建促销的所有含义.

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

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

我看到两个选择:

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

是否有关于此主题的行业标准?还是最佳做法?

非常感谢你的帮助 :)

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

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

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

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

解决方法

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

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

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

猜你在找的Java相关文章