複数のチームが変更を行う複数のコンポーネント間のMaven依存関係の管理
複数のチームが依存関係のある一部のMavenプロジェクトに変更を加えている状況（その他の場合は無関係のプロジェクト、つまりスーパーPOMがないなど）で、各チームがこれらすべてのプロジェクトの個別の作業ブランチで作業し、それらをマージします。ストーリーが完成してテストされた後にのみトランクするために、各チームが作成するスナップショットビルド間の依存関係をどのように処理する必要がありますか？
どのチームもどのプロジェクトでも変更を加える可能性があることに注意してください。チームは同じシステムのさまざまな機能を処理し、プロジェクトはさまざまなレイヤーに似ています。
複数のチームに分割される前に、アーティファクトは中央のNexusリポジトリにデプロイされました。もちろん、チームごとに個別のNexusリポジトリをセットアップし、トランク用に追加のリポジトリをセットアップすることは可能ですが、これを処理するためのより良い方法があると思います。
ソースコードリポジトリにはブランチがありますが、バイナリブランチにはありません。したがって、ブランチに依存する開発計画のどの部分も、ブランチのスコープ内にあるものについてバイナリリポジトリに依存することはできません。
（上記の1つの例外はClearCaseです。これは両方を実行するため、話されないのが最善です。）
チームを独立させる場合は、リリースされたバージョンに関して依存関係を管理する必要があります。これは苦痛です。あなたがやっていることは難しいです。おそらく、事前の変更の計画と議論に慣れ、臨時のリファクタリングを放棄する必要があります。
一方で、おそらくチームはほんのわずかなものです。全員が1つの全体的な製品のリリース/配信スケジュールになるように協力しています。次に、機能ブランチがマスターにマージされるたびにバンプされる単一の全体的なバージョン番号を保持します。次に、すべてのローカル依存関係は単に{project.version}を使用します。
番号を変更せずに更新することはないため、これはまだスナップショットではないことに注意してください。
そして、チーム内でバイナリではなくコードを共有します。追加の再コンパイルが必要ですが、15秒以上かかる場合は、より高速なPCを入手してください。そして、Eclipseのようにマルチモジュールを使用していない人はIDEのように、現在取り組んでいるモジュールのセットをカバーするために、簡単なreactor-build POMを作成する必要があります。
見る：
http://books.sonatype.com/m2Eclipse-book/reference/Eclipse.html
http://axelfontaine.com/blog/final-nail.html
http://ahoehma.wordpress.com/2010/12/22/intermodule-dependencies-now-better-working-with-maven-3/
このような状況でIDE、CIビルドサーバー、reactorビルドをセットアップする方法について。
または、git + Nexusにスクリプトを追加してClearCaseを再実装してみることもできます（これは行わないでください）。
TL; DR：スナップショットの依存関係の代わりにリリースの依存関係を使用します。
スナップショットとリリースのどちらの依存関係を選択するかを検討するケースは、一部のコンポーネント（A）の変更が依存コンポーネント（B）を壊す場合です。
これが発生した場合、修正する必要がありますが、2つのオプションがあり、プロジェクトの詳細によってはそのうちの1つが望ましい場合があります。
1つのオプションは、問題を修正する場合すぐにですが、コンポーネントのAに取り組んでいる 気が散る 開発者を犠牲にしてもかまいません。このアプローチの利点は、その概念の単純さです。コンポーネント間の依存関係を記憶、維持、更新する必要から開発者を解放します。代わりに、コンポーネントの最新バージョンすべての同期を維持することに重点が置かれるためです。
この場合、リリースの依存関係は、スナップショットのものと比較して魅力的なものを提供しません。むしろ反対です-これらは、依存コンポーネントがもう壊れないかどうかをテストできるようにするために、更新されたコンポーネントAをリリースするための追加のステップ/労力を導入します。
- ちなみに、Mavenは最も単純な形式のスナップショット依存関係設定のサポートを提供しています： multi-module projects 。モジュール間のスナップショット依存関係の処理は、これと同じくらい簡単になります（ただし、これは同時に発生します）リリースは時々望ましくない-例えばコンポーネント/モジュールが非常に異なるペースで変化する傾向がある場合）。
反対のオプションは、コンポーネントAの統合修正を延期したい場合です。たとえば、プロジェクトで変更に強く焦点を合わせることが開発者にとってより重要であると確信している場合その中で行われ、彼らの努力を後で統合に切り替えます。これは、コンポーネント間の依存関係が「緩い」、小さく、注意深く設計され、ゆっくりと変化するインターフェースである場合に当てはまります。
- たとえば、コンポーネント
AとBの間で注意深く作成され、徹底的にテストされた、クリーンで便利なインターフェイスをすでに持っている場合、Bで大まかにドラフトされた変更を磨いている間、Aでの変更を延期することをお勧めします。A側のインターフェースが再びクリーンになってから統合します。
このリリースのような場合、依存関係により、依存コンポーネントを完全に分離できます。 Bを使い、Aの依存関係を変更して目的のリリースを参照するまでは、コンポーネントBについて心配する必要はありません。スナップショットの依存関係は、このようなものを提供できません。Aで行われた変更が依存コンポーネントを壊す場合、物事を形に戻すように努力する必要があります。
さて、あなたのケースで上記がどのように適用されるか見てみましょう、
- 関連のないプロジェクト
- 別々の作業ブランチで作業する各チーム
- 複数のチームに分割
上記のささやきはすべて、チームがシステムのコンポーネントに対してより独立した、より多くの分離された作業を可能にする方向に動いていると叫びます。 JohnがプロジェクトAに取り組んでおり、PaulがBに取り組んでおり、GeorgeがCに取り組んでおり、RingoがDに取り組んでいるため、これらのコンポーネント内で変更を計画および実装する余裕があり、他のコンポーネントで何が起こっているのかを永続的に確認する必要がありません。
では、上記の視点から「各チームが作成するスナップショットビルド間の依存関係」を見てみましょう。 Mavenの動作方法では、これは、チームが離れるべきところへの大きな一歩を意味します。 JohnがAを断続的に変更してスナップショットを作成する瞬間、Mavenはすぐにそのスナップショットを選択し、 "broadcasts"ポール、ジョージ、リンゴ！
現在、他のプロジェクトで作業している3人の男がJohnによって加えられた変更に適応する必要があり、これらの変更が他のプロジェクトで深刻な問題を引き起こす場合、おそらくJohnは flow を中断し、プロジェクトを緊急に適応させる必要がありますへ...ところでところで、彼は何に適応するのですか？ポール、ジョージ、リンゴ、彼らはすべてジョンのように働いています、彼らのプロジェクトは永久に変化しています、彼らはジョンに今日彼が正確に考慮しなければならないこと、そしておそらく彼が明日何をしなければならないかを説明するはずですか？
チームが異なるコンポーネント/プロジェクトのより独立した開発に移行することになっている場合、スナップショットの依存関係を使用すると、基本的にこの動きが完全に中断され、モノリシックなアプローチの時代に戻ります。
分離されたより強力なコンポーネント/プロジェクトに移行したい場合は、これらのプロジェクトが他のプロジェクトと統合する準備/義務を「宣言」する「コミュニケーションポイント」を定義する必要があります。 Mavenでは、リリースは当然この目的を果たします。
Mavenリリースは、プロジェクト開発者が外の世界と安全に通信できるようにする、安定した固定「チェックポイント」を提供します。
- リリース2.15.23は、統合の準備ができている最新のリリースです。 2.14.999より前のリリースに対するバグレポートはサポート/承認されなくなりました。リリース2.15.24以降では、現在重大な問題が発生しており、今後の通知があるまで統合を意図したものではありません。
リリースの依存関係は、コンポーネント間ではなく、コンポーネント間の安定した「チェックポイント」を示すことを強調する価値があります。コンポーネントが別々の開発者によって保守されているかどうかは、実際には関係ありません。
たとえば、JohnがAとBの両方のコンポーネントで作業している場合や、JohnとPaulが一緒にこれら2つのコンポーネントで作業している場合でも、リリースの依存関係があることは理にかなっています。これが別の人にどのように影響するかについての心配で気を取られました。
上記を踏まえ、できるだけスムーズに統合するために、リリースをどの程度正確にスケジュールするかをチーム間で決定する必要もあります。ここであなたのオプションは本当に広いです。頭に浮かぶ自然な「スケジュール」は、各チームが他のチームが統合する作業の「チェックポイント」を提供する準備ができたときに決定することです。
ただし、自然なアドホックリリースは単一のチームの「内から」聞こえます。他のチームの観点から見ると、「統合チェックポイント」に到達するためのより定期的な方法が望まれる場合があります-これから観点からすると、他のチームの注意を引くために、コンポーネントの更新を「プロモート」する予測可能な方法を検討する必要があるかもしれません-月次、週次、あるいは日次リリース。
システムがより複雑になったので、スナップショットの依存関係の詳細と目的を詳しく見てみる価値があります。あなたはこれのかなりまともな説明を Maven：The Complete Reference でSonatypeで見つけることができます（下の引用の太字は私のものです）：
...スナップショットを展開するとき、ソフトウェアコンポーネントのリリースを作成するわけではありません。特定の時間にコンポーネントのスナップショットを解放しています。
なぜこれを使うのですか？ SNAPSHOTバージョンは、開発中のプロジェクトに使用されます。プロジェクトが開発中のソフトウェアコンポーネントに依存している場合は、SNAPSHOTリリースに依存できます。ビルドを実行すると、Mavenはリポジトリから最新のスナップショットを定期的にダウンロードしようとします。同様に、システムの次のリリースのバージョンが「1.4」になる場合、正式にリリースされるまで、プロジェクトのバージョンは「1.4-SNAPSHOT」になります...
プロジェクトがSNAPSHOTに依存している場合、依存関係は時間とともに変化する可能性があるため、安定していません... SNAPSHOTバージョンは開発専用です...
ご覧のとおり、上記は一時的、断続的、不安定スナップショット依存関係の性質を強調し、その適用範囲を「アクティブな開発」の時間に制限しています。あなたの場合、密接に相関し、同期し、緊密に一連の 結合 変更を異なるコンポーネントで行う必要がある場合、一時的にスナップショット依存関係に切り替えることを考えることができます。この「アクティブ」フェーズが終了すると、関連するコンポーネントの「チェックポイント」リリースを実行し、リリースの依存関係に切り替えることができます。
スナップショット依存関係への切り替えが頻繁に発生することがわかった場合は、設計を再考する必要があることを示している可能性があることに注意してください。コンポーネントをより適切に分離する方法、または反対の方法、つまり以前に分離されていたコンポーネントを、同期して開発およびリリースされたモノリシックモジュールに「マージ」する方法を考えるかもしれません。