GitLab Package Registryを「最強の社内ハブ」へ変貌させる：CI/CD統合の極意
「社内ライブラリの配布に、わざわざ外部のArtifactリポジトリを立てて管理コストを増やしていませんか？」
GitLab Package Registryは単なるストレージではありません。正しく設定すれば、「コードを書く」「ビルドする」「配布する」「使う」というサイクルを、GitLabの単一UIとCI/CDパイプラインだけで完結させられる最強のインフラに化けます。
本記事では、テックリードとして現場の生産性を極限まで引き上げるための「Package Registry運用の秘術」を伝授します。
—
1. なぜ「GitLab一つ」に集約すべきなのか
外部ツール（Artifactoryなど）を併用すると、認証情報の同期、ネットワーク管理、ログの断片化が発生します。GitLabに統合する最大のメリットは、「誰が、どのコミットで、どのライブラリを作成したか」というトレーサビリティがリポジトリと完全に紐付く点です。
実践的アーキテクチャの指針
- 認証の透過: `CI_JOB_TOKEN` を活用し、`settings.xml` や `.npmrc` にハードコードされた認証情報を撲滅する。
- 可視性の分離: GroupレベルのRegistryを使い、プロジェクトを横断した依存関係を整理する。
—
2. 現場で震える！パイプライン自動発行のベストプラクティス
多くのチームが躓くのが「バージョン番号の自動更新」です。手動で `package.json` を書き換える時代は終わらせましょう。
npmの場合：semantic-release の導入
CIパイプラインで自動的にタグを打ち、バージョンを昇格させるのが鉄則です。
.gitlab-ci.yml の最適化構成:
stages:
- build
- publish
publish_package:
stage: publish
image: node:18
script:
# GitLabのURLとCI_JOB_TOKENをnpmrcに注入
- echo “//${CI_SERVER_HOST}/api/v4/projects/${CI_PROJECT_ID}/packages/npm/:_authToken=${CI_JOB_TOKEN}” > .npmrc
- echo “@${CI_PROJECT_NAMESPACE}:registry=https://${CI_SERVER_HOST}/api/v4/projects/${CI_PROJECT_ID}/packages/npm/” >> .npmrc
- npm publish
only:
- tags # タグが打たれた時のみ発行するルールを徹底
現場の知見：タグ付けの自動化
`git tag` を打つたびにCIを回すのは面倒です。`semantic-release` をGitLab CIに組み込み、コミットメッセージのプレフィックス（feat:, fix:）からバージョンを自動判定させましょう。これが最も事故が少ない運用です。
—
3. チーム開発の生産性を最大化する「設定の共有化」
.npmrc / settings.xml の配布を自動化する
ライブラリを使う側の設定が煩雑だと、誰も使わなくなります。
- 隠れた裏技: プロジェクトルートに `.npmrc` を配置し、プロジェクト専用のRegistry URLを固定しておくことで、エンジニアは `npm install` するだけで社内ライブラリを解決できるようにします。
神プラグイン・拡張機能
- GitLab Workflow (VS Code): これを入れない理由はありません。サイドバーからPackageのバージョン履歴を検索し、最新版を確認するフローを日常化してください。
- GitLab Snippets: 頻出する設定ファイル（`.gitlab-ci.yml`のテンプレート）をSnippetsで管理し、チーム全員が同じテンプレートを使い回す文化を作ります。
—
4. 事故を防ぐ！バージョン管理の「鉄の掟」
1. Snapshot/Releaseの使い分け（Mavenの場合）:
- `SNAPSHOT` はCIの `develop` ブランチでのみ発行を許可。
- `Release` バージョンは `main` へのマージかつタグ付けされた時のみ許可。これだけでライブラリの「品質の不透明さ」を排除できます。
2. Cleanup Policy（重要）:
- Registryが肥大化するとパフォーマンスが落ちます。GitLabの「Package Cleanup Policies」を設定し、古いバージョンを自動削除するルールを適用してください。
- 設定の目安: 過去10バージョンを保持、または3ヶ月以上前の非リリース版は削除。
—
5. 最後に：リードがチームに植え付けるべき文化
「ツールを導入して終わり」では生産性は上がりません。以下の3点をチームの「暗黙知」から「明文化されたルール」へ昇華させてください。
- 「ライブラリの消費者は、常に最新のマイナーバージョンを追従する」 という意識付け。
- 「CIが落ちる原因が『ライブラリの破壊的変更』か『設定ミス』か即座に判別できるログ構成」 を追求すること。
- 「パッケージ更新はGitLabのリリースノート機能と連動させる」 こと。これにより、パッケージ更新の意図をチーム全員が瞬時に把握できます。
GitLab Package Registryは、使いこなせば「開発チームのOS」になります。まずは、今動いているプロジェクトのCIに一行、認証コードを書き加えるところから始めてみてください。その小さな一歩が、数ヶ月後の圧倒的なビルド時間の短縮に繋がります。
さあ、リポジトリを整理して、本来書くべきコードに集中する時間を手に入れましょう。