Build promotion: how do you manage dependencies?

Question

I am trying to understand all the implications of switching our java projects from a Snaphot/Release policy to build promotion.

One obvious step is that each build ends up creating an artifact that might be going all the way to the production environment, so there's not Snapshot anymore. But then, how should I manage the link from a project to other artifacts, that may or may not be allowed to go to prod?

I've had a hard time finding valuable information on this particular subject. Of course, build promotion is talked about a lot, but dependency management in the light of a migration to build promotion has less visibility.

I see two choices:

• One can only depend on artifacts that have been previously promoted to the production environment
• When one depends on another artifacts, the built artifact can only go to the last environment of its dependencies. That is, if I depend from an artifact that was allowed to go to test and not prod, then my build won't be allowed to go to prod

Are there industry standards regarding this topic? Or best practices?

Thanks a lot for your help :)

edits: We deploy to Artifactory three kind of artifacts:

• Libraries

• EARs

• The modules inside the EARs. Some of those are "public" layers that are needed by any EAR that wants to interact with the currently built EAR

We deploy EARs to JEE servers. Our libraries and public layers are deployed to Artifactory and packaged in the EARs, so they are not directly deployed on the JEE containers.

One project builds several modules, and everything is packaged in an EAR, along with its dependencies. One project can depend on a module of another project and that's where it gets complicated...

Give

JF Meier's answer below got me thinking, can you further describe what kinds of artifacts you are deploying, or at a high level, describe what kind of system you are making? He brings up a good point about deployables vs non deployables. – Dickman

I've updated the question to add some more details. – Magree

By "We deploy" you mean "We build and put in artifactory", or do you mean deployment to some kind of server? Especially: Do you deploy libraries to a server? And can you elaborate on the last point you mentioned? – Nannie

updated according to your comment. Thanks a lot for your time! – Magree

Then I would stick with my answer below and prefer to only promote the ears. Promoting a library seems to be unnecessary - the unit and integration tests are run during the build, and runtime tests make no sense because the library cannot be run without the surrounding ear. – Nannie

The difficult point is: when a project contains modules that are packaged in the EAR and used by other projects as a dependency (i.e the Public layer for remote EJB), then the same builds needs to follow two different policies? – Magree

I do not quite understand. I suggested to only promote the ears. The modules that are used as dependency need not be promoted (in my opinion). – Nannie

Yes, and I think you're right. Our project build ears and libraries in the same project, that is probably something that we need to change and just follow your advice. Anyway thanks a lot for your help! :) – Magree

Answer 1

We distinguish between "deployable artifacts" and "libraries".

Deployable artifacts (like ears, wars, standalone jars) go through a pipeline, so they are promoted and tested in different steps. They cannot be dependencies for any other artifact.

Libraries, on the other hand, are not promoted. When they are built (as a release version), are immediately available as possible dependency for all other artifacts (the release build includes unit tests and some integration tests). They are tested and promoted indirectly when they are used in deployable artifacts.

Nannie