推奨するリポジトリ構造⚓︎
1 つのシステムの中に複数のプロジェクトやパッケージが存在する場合、リポジトリ管理の方針を定めます。 単一のリポジトリで管理する mono-repo とそれぞれ個別のリポジトリで管理する poly-repo ( multi-repo ) という管理方法があります。
- mono-repo のメリット
- プロジェクト間のリソースの共有、すなわち横断した変更が容易
- プロジェクトを横断したテストが容易
- システムの全体把握が容易
- poly-repo のメリット
- 開発者自身が作業するリポジトリに集中できるため開発効率が向上
- リポジトリの肥大化の防止
AlesInfiny Maia OSS Edition では mono-repo 構造を推奨します。 マイクロサービス開発など、各プロジェクトの独立性が高く、プロジェクトごとに採用する技術要素が全く異なる場合は、 poly-repo を検討してください。
依存ライブラリのバージョン管理方針⚓︎
Java アプリケーションでは、ビルドの再現性を高めるため、 Gradle の依存関係ロック を使用します。 直接依存するライブラリと推移的に依存するライブラリの解決済みバージョンを gradle.lockfile に記録・管理します。 依存関係を変更する際は、依存関係の定義とロックファイルを併せて更新し、差分をレビューします。 また、通常のビルドや CI では、保存されたロック状態を用いて依存関係を解決します。
ロックモードは Gradle の LockMode で定義されており、それぞれの動作は以下の通りです。
| ロックモード | 動作 |
|---|---|
DEFAULT | ロック状態がある場合、依存関係の解決結果との一致を検証します。ロック状態がない場合は解決を許可します。 |
STRICT | DEFAULT の検証に加え、解決するロック対象の構成にロック状態がない場合もエラーにします。 |
LENIENT | 動的バージョンをロック状態に固定しつつ、依存関係の追加・削除やその他のバージョン変更を許可します。 |
解決結果とロック状態の不整合や、ロック対象の依存関係にロック状態が存在しないことを検知できるよう、 STRICT を使用します。
設定方法は 依存ライブラリのバージョン固定 を参照してください。