7

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...

Sébastien
  • 548
  • 1
  • 6
  • 19
  • 1
    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. – Nick DeFazio May 02 '18 at 13:29
  • I've updated the question to add some more details. – Sébastien May 02 '18 at 14:32
  • 2
    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? – J Fabian Meier May 02 '18 at 15:20
  • updated according to your comment. Thanks a lot for your time! – Sébastien May 03 '18 at 07:56
  • 1
    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. – J Fabian Meier May 03 '18 at 09:42
  • 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? – Sébastien May 03 '18 at 11:26
  • 1
    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). – J Fabian Meier May 04 '18 at 07:49
  • 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! :) – Sébastien May 04 '18 at 12:14

1 Answers1

3

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.

J Fabian Meier
  • 33,516
  • 10
  • 64
  • 142