Java – build upgrade: how to manage dependencies?

I'm trying to understand all the implications of switching our java project from snapshot / release strategy to build promotion

An obvious step is that each build will eventually create an artifact that may go all the way to the production environment, so there is no snapshot However, how should I manage links from the project to other artifacts that may or may not be allowed to be produced?

It is difficult for me to find valuable information on this particular subject Of course, there are many build promotions, but the dependency management based on the migration to build promotions has low visibility

I see two options:

>People can only rely on artifacts that have previously been promoted to the production environment > when relying on another artifact, the built artifact can only go to the last environment of its dependency That is, if I rely on artifacts that allow testing rather than stimulation, my build will not be allowed into the product

Is there an industry standard on this topic? Or best practices?

Thank you very much for your help:)

Editor: we have deployed three artifacts to the artifact:

>Library > ear > modules in ear Some of these are the "common" layers required by any ear that wants to interact with the currently built ear

We deploy ear to Jee server Our libraries and common layers are deployed to the artifact and packaged in ear, so they are not deployed directly on the Jee container

A project builds several modules, all of which are contained in ear and its dependencies A project can depend on the modules of another project, which is where it becomes complex

Solution

We distinguish between deployable artifacts and libraries

Deployable artifacts (e.g. ears, war, independent cans) pass through the pipeline, so they are promoted and tested in different steps They cannot be dependencies of any other artifact

On the other hand, the library has not been promoted When they are built (as release versions), they are immediately available as possible dependencies for all other artifacts (release versions include unit tests and some integration tests) When they are used for deployable artifacts, they are tested and upgraded indirectly