Managing several maven artifacts in a delivery pipeline

65 Views Asked by At

This is not a programming question by but a delivery pipeline question:

Our product is built of several maven artifacts, which release SNAPSHOTS (2.0.1-SNAPSHOT) on a daily basis and release versions (2.0.1) on a weekly basis. During development, our artifacts get tested fully with snapshots of the other artifacts and all works well. In many cases artifacts get developed at the same time and so depend on eachother without backwards compatibility

The last stage of the pipeline tests the release candidate of a specific artifact with the release versions of other artifacts, so I'm trying to release 2.0.1 of artifact A, that was tested with 2.3.5-SNAPSHOT of artifact B and passed. If it passes artifact A gets released (2.0.1-SNAPSHOT becomes 2.0.1)

Here comes the dead-end, because artifact B hasn't released 2.3.5 yet (it will in a few hours). So obviously artifact A will fail in this stage because it's being tested against 2.3.4 of artifact B (which is B's latest release).

Let's assume that all artifacts have the same pipeline.

Just to sum it up: Artifact A is at 2.0.1-SNAPSHOT attempting to release 2.0.1, its latest release is 2.0.0 Artifact B is at 2.5.2-SNAPSHOT attempting to release 2.5.2, its latest release is 2.5.1

stage 0 test -> A 2.0.0 with B 2.5.1 - PASSED

stage 1 test -> A 2.0.1-SNAPSHOT with B 2.5.2-SNAPSHOT - PASSED

stage 2 test -> A 2.0.1-SNAPSHOT with B 2.5.1- FAILED

I understand that it will continue to fail until B release 2.5.2, but how do I take that into consideration in my delivery pipeline. I want artifact A to be able to release weekly.

What I'm looking for is a fix to this hole in my delivery pipeline. Do I need another stage in the pipeline? release another SNAPSHOT of the collected snapshots?

1

There are 1 best solutions below

6
On

I think you need to decide what kind of dependency is between A and B.

If A depends on B as 3rd party library you should never use B's SNAPSHOT during the testing. In such way you will never be blocked by the upcoming release of B.

If A depends on B as a module in multi module project, you should do the maven's work manually. It means you need to build first the B's RELEASE and afterwards the A's RELEASE.