それはすべて、転職してすぐに大きなプロジェクトに着手したときに始まりました。 私にとって大きなのは、数社のベンダー、1ダースのシステム、5段階のリリースサイクル、さまざまな場所にいる1000人以上のエンジニアです。 ソースは、それぞれが1つまたは複数のシステムで使用できる多数のMavenモジュールを備えた複数のsvnリポジトリに「住んで」います。 各モジュールは、バイナリ依存関係を介してメインシステムに接続されました。 リリースサイクルの終わりに、それらに基づいて組み立てられたモジュールとシステムの新しいバージョンをリリースする必要がありました。 カットの下で、私が戦おうとしたこのプロセスの有効性の問題と、それがもたらしたものについて説明します。
ちなみに、モジュールのバージョン管理とリリースのリリースのメインキッチンに関する非常に適切な
記事を見つけました。著者には非常に感謝しています。 これを説明する問題を理解するのに役立つので、事前にこれを理解することを強くお勧めしますが、「コピーペースト」はお勧めしません。
プロジェクトですべてがどのように機能したかの例：
- モジュールA、B、Cと2つのシステムX、Yがあります。
- XはA（バージョン1.0.0）、B（1.1.0）から組み立てられます。
- Y B（1.8.0）、C（1.0.0）から収集。
- モジュールBは、たとえばAに依存する場合があります。
- 依存関係は
pom.xml各システムのルートpom.xmlバイナリとして登録されます（以下を参照）。 - 開発サイクルの最後に必要なことは、変更されたモジュールのリリースとXおよびYの新しいバージョンをリリースする（バージョンを増やす）ことです。
<dependencies> <dependency> <groupId>B</groupId> <artifactId>B</artifactId> <version>1.1.0</version> </dependency>
問題
- 各システムのリリースを担当する人々がいます。 したがって、各リリースサイクルの終わり（1か月）にすべてのモジュールのすべての変更を検索することを強制されました。その新しいバージョンはリリースに含まれ、その後は変更されたモジュールの新しいリリースと正しい順序で更新されます（例の段落4を参照）、更新
pom.xml ;
本当にたくさんのモジュールがあり、一部は変更され、一部は変更されていません。
多くのエンジニアもいます。通常、XおよびYシステムの単一モジュールの変更が可能かどうかは、これらの変更を行った人と上司の助けを借りてのみ可能です。