1

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?

orepor
  • 905
  • 2
  • 13
  • 23
  • Are you using version ranges? `[2.5.2-SNAPSHOT,2.5.2]` might work, if you're careful with backwards compatibility. You might have to create your own version resolver though. I'm not sure if maven considers 2.5.2-SNAPSHOT to be before 2.5.2... – Paul Hicks Jul 06 '16 at 22:36
  • I could use ranges, and this *would* keep my build green, but I'd still like to know when my build is using the SNAPSHOT and when it has started using the release version, so basically when B has released. – orepor Jul 07 '16 at 07:08

1 Answers1

0

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.

Yuri G.
  • 4,323
  • 1
  • 17
  • 32
  • Thanks, the latter is what I'm talking about. I'd like to keep my pipeline automatic with no manual steps. – orepor Jul 07 '16 at 07:07
  • @orepor manually doesn't mean to trigger the build releases manually. You need to update your pipeline in such way, that release of A won't occur before release of B. it can be validation in the A release. It can be a release of B automatically when A is released etc... – Yuri G. Jul 07 '16 at 08:05
  • I see what you mean, only issue is that today A is building a feature that depends on B, and tomorrow B will release a feature that is dependant on A – orepor Jul 07 '16 at 08:27
  • @orepor it looks like a circular dependency, that's in general a problem when you are working with maven. – Yuri G. Jul 07 '16 at 08:33
  • I don't mean dependent in that sense. Think about 2 squads working on the same "feature", each developing their artifact according to this new feature. – orepor Jul 07 '16 at 08:50
  • 1
    @orepor I understand your point, but here is your mistake. Can you tell me how would you define the dependency between A and B if they were sitting in the same multi module project? If you can't answer this, in my understanding it means that you have a circular dependency here. if yo can answer this, just adopt your pipeline accordingly – Yuri G. Jul 07 '16 at 08:56