チュートリアル: エンタープライズの拡大に合わせてパッケージレジストリを構造化する

組織がスケールするにつれて、パッケージ管理はますます複雑になる可能性があります。GitLabパッケージレジストリモデルは、エンタープライズパッケージ管理のための強力なソリューションを提供します。パッケージレジストリを活用する方法を理解することは、パッケージを安全、簡単、かつ大規模に扱う上で重要です。

このチュートリアルでは、GitLabパッケージレジストリモデルをエンタープライズグループ構造に組み込む方法を学びます。ここで提供する例はMavenおよびNPMパッケージに固有のものですが、このチュートリアルの概念は、GitLabパッケージレジストリでサポートされているパッケージに拡張できます。

このチュートリアルを終えると、次の方法がわかるようになります:

はじめる前

このチュートリアルを完了するには、以下が必要です:

NPMまたはMavenパッケージ。
GitLabパッケージレジストリに関する知識。
テストプロジェクト。既存のプロジェクトを使用するか、このチュートリアル用にプロジェクトを新規作成できます。

GitLabパッケージレジストリについて

JFrog ArtifactoryやSonatype Nexusなどの従来のパッケージマネージャーは、単一の集中リポジトリを使用してパッケージを保存および更新します。GitLabでは、グループまたはプロジェクトでパッケージを直接管理します。これは、次の意味をもちます:

チームはコードを保存するプロジェクトにパッケージを公開します。
チームは、それらの下にあるすべてのパッケージを集約するルートグループレジストリからパッケージを消費します。
アクセス制御は、既存のGitLab権限から継承されます。

パッケージはコードのように保存および管理されるため、既存のプロジェクトまたはグループにパッケージ管理を追加できます。このモデルには、いくつかの利点があります:

ソースコードと並行したパッケージの明確な所有権
追加の設定なしで、きめ細かいアクセス制御
簡素化されたCI/CDインテグレーション
チーム構造との自然な連携
ルートグループ消費を通じて、すべての企業パッケージにアクセスするための単一のURL

エンタープライズ構造を作成する

単一のトップレベルグループでコードを整理することを検討してください。例:

company/ (top-level group)
├── retail-division/
│   ├── shared-libraries/    # Division-specific shared code
│   └── teams/
│       ├── checkout/        # Team publishes packages here
│       └── inventory/       # Team publishes packages here
├── banking-division/
│   ├── shared-libraries/    # Division-specific shared code
│   └── teams/
│       ├── payments/        # Team publishes packages here
│       └── fraud/           # Team publishes packages here
└── shared-platform/         # Enterprise-wide shared code
    ├── java-commons/        # Shared Java libraries
    └── ui-components/       # Shared UI components

この構造では、会社内のすべてのチームがコードとパッケージを独自のプロジェクトに公開し、トップレベルグループcompany/グループの設定を継承します。

トップレベルグループを設定する

オーナーロールがあり、既存のトップレベルグループがある場合は、それを使用できます。

グループがない場合は、次の手順で作成します:

左側のサイドバーの上部で、新規作成（）を選択し、新規グループを選択します。
グループ名に、グループの名前を入力します。
グループURLに、グループのパスを入力します。これは、ネームスペースとして使用されます。
表示レベルを選択します。
オプション。情報を入力して、エクスペリエンスをパーソナライズします。
グループを作成を選択します。

このグループは、組織内の他のグループとプロジェクトを格納します。他のプロジェクトやグループがある場合は、管理のためにトップレベルグループに転送することができます。

続行する前に、少なくとも以下があることを確認してください:

トップレベルグループの場合
トップレベルグループまたはそのサブグループの1つに属するプロジェクト。

パッケージを公開

明確な所有権を維持するために、チームは独自のパッケージレジストリにパッケージを公開する必要があります。これにより、パッケージはソースコードとともに保持され、バージョン履歴がプロジェクトアクティビティーに関連付けられます。

Mavenパッケージを公開するには:

プロジェクトのパッケージレジストリに公開するようにpom.xmlファイルを設定します:

<!-- checkout/pom.xml -->
<distributionManagement>
    <repository>
        <id>gitlab-maven</id>
        <url>${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/maven</url>
    </repository>
</distributionManagement>

NPMパッケージを公開するには:

package.jsonファイルを設定する:

// ui-components/package.json
{
  "name": "@company/ui-components",
  "publishConfig": {
    "registry": "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/npm/"
  }
}

パッケージを消費する

プロジェクトは単一のトップレベルグループの下に編成されているため、パッケージは組織から引き続きアクセスできます。チームがパッケージを消費するための単一のAPIエンドポイントを設定しましょう。

トップレベルグループからパッケージにアクセスするようにpom.xmlを設定します:

<!-- Any project's pom.xml -->
<repositories>
    <repository>
        <id>gitlab-maven</id>
        <url>https://gitlab.example.com/api/v4/groups/company/-/packages/maven</url>
    </repository>
</repositories>

.npmrcファイルを設定する:

# Any project's .npmrc
@company:registry=https://gitlab.example.com/api/v4/groups/company/-/packages/npm/

この設定により、プロジェクトベースの公開の利点を維持しながら、組織全体のすべてのパッケージへのアクセスが自動的に提供されます。

デプロイトークンを追加

次に、読み取り専用デプロイトークンを追加します。このトークンは、組織のサブグループとプロジェクトに保存されているパッケージへのアクセス制御を提供するため、チームは開発にそれらを使用できます。

トップレベルグループで、左側のサイドバーで設定 > リポジトリを選択します。
デプロイトークンを展開します。
トークンの追加を選択します。
フィールドに入力し、スコープをread_repositoryに設定します。
デプロイトークンを作成を選択します。

必要に応じて、トップレベルグループにデプロイトークンをいくつでも追加できます。トークンを定期的にローテーションすることを忘れないでください。トークンが漏洩した疑いがある場合は、すぐに失効して交換してください。

CI/CDでパッケージを使用する

CI/CDジョブがパッケージレジストリにアクセスする必要がある場合、定義済みのCI/CD変数CI_JOB_TOKENで認証します。この認証は自動的に行われるため、追加の設定を行う必要はありません:

publish:
  script:
    - mvn deploy  # For Maven packages
    # or
    - npm publish # For npm packages
  # CI_JOB_TOKEN provides automatic authentication

まとめと次のステップ

GitLabプロジェクトを1つのトップレベルグループの下に編成すると、いくつかの利点があります:

簡素化された設定:
- すべてのパッケージアクセスに対する1つのURL
- チーム全体で一貫性のあるセットアップ
- 簡単なトークンローテーション
明確な所有権:
- パッケージはソースコードとともに保持されます
- チームは公開に対するアクセス制御を維持します
- バージョン履歴はプロジェクトアクティビティーに関連付けられています
自然な組織:
- グループは会社構造と一致します
- チームは自律性を維持しながら共同作業できます

GitLabパッケージレジストリモデルは、エンタープライズパッケージ管理のための強力なソリューションを提供します。プロジェクトベースの公開とトップレベルグループ消費を組み合わせることで、明確な所有権と簡素化されたアクセスの両方の利点が得られます。

このアプローチは、セキュリティと使いやすさを維持しながら、組織に合わせて自然にスケールします。このモデルを単一のチームまたは部門に実装することから始め、この統合されたアプローチの利点を確認したら展開します。このチュートリアルではMavenとNPMに焦点を当てていますが、同じ原則はGitLabでサポートされているすべてのパッケージタイプに適用されることを忘れないでください。