配信パイプライン

Question

にいくつかのMavenの成果物を管理する。これは、によって、プログラミングの質問ではなく、配信パイプラインの質問：

当社の製品は、日常にスナップショットを解放し、いくつかのMavenアーティファクト、（2.0.1-SNAPSHOT）で構築されています（2.0.1）を毎週発行しています。 開発中、私たちの成果物は他の成果物のスナップショットで完全にテストされ、すべての成果物がうまく機能します。多くの場合、アーティファクトは同時に開発され、後方互換性なしで互いに依存します。

パイプラインの最後のステージは、特定のアーティファクトのリリース候補を他のアーティファクトのリリースバージョンでテストします。アーティファクトBの2.3.5-SNAPSHOTでテストされ、合格したアーティファクトAのリリース2.0.1。アーティファクトBがまだ2.3.5をリリースしていないので（これは数時間後になる）、デッドエンドとなる。だから明らかにアーティファクトAは2.3.4のアーチファクトB（Bの最新リリース）に対してテストされているため、この段階で失敗します。

すべての成果物が同じパイプラインを持っているとします。ちょうどそれを総括する

： 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

私はそれがBリリース2.5.2まで失敗し続けることを理解し、どのように私はそれを配達パイプラインで考慮してください。私はアーティファクトAが毎週リリースできるようにしたい。

私が探しているのは、配送用パイプラインの穴です。パイプラインに別のステージが必要ですか？収集されたスナップショットの別のスナップショットをリリースしますか？

Answer 1

私はあなたがAは、あなたがテスト中にBのスナップショットを使用しないでください、サードパーティのライブラリとしてBに依存する場合

AとBの間で依存関係の種類を決定する必要があると思います。このようにして、Bの次回のリリースでブロックされることは決してありません。

AがマルチモジュールプロジェクトのモジュールとしてBに依存する場合は、手動でMavenの作業を行う必要があります。それはあなたが最初にBのRELEASEを構築し、その後AのRELEASEを構築する必要があることを意味します。