やあ、エンジニア諸君。現場の最前線でコードを書き続けていると、「社内ライブラリの配布」という壁に必ずぶつかるはずだ。
「Gitのサブモジュールで管理する?」「適当なサーバーにscpで上げる?」……ノン、ノン。そんな運用は今すぐ捨てよう。それらは技術的負債の温床でしかない。
GitLabには「Package Registry」という、極めて強力な武器が標準で備わっている。これを使えば、npm、Maven、PyPIといったあらゆるパッケージを、GitLabの中に「自分だけのプライベートな中央リポジトリ」として構築できるんだ。
今回は、GitLab一つで社内ライブラリを完結させる、プロの運用術を伝授しよう。これをマスターすれば、開発体験(DX)は劇的に向上するぞ。
—
1. なぜ「Package Registry」を使うべきなのか?
最大の理由は「CI/CDとの究極的な統合」だ。
外部のレジストリ(npm registryやNexusなど)を使わず、GitLab内で完結させるメリットは以下の3点に集約される。
- 認証の一元管理: GitLabの個人アクセストークン(PAT)やジョブトークンを使うため、セキュリティ管理が極めて楽。
- 権限の自動化: プロジェクトの権限設定がそのままパッケージの公開・閲覧権限に直結する。
- パイプラインとの同期: 「テストが通ったら自動で新バージョンをタグ付けして発行する」というフローが、GitLab CIの1ジョブで完結する。
—
2. 【HelloWorld】npmパッケージをGitLabへ公開する
一番導入しやすいnpm(JavaScript/TypeScript)を例に、実際にパッケージを登録するまでの最短ルートを見ていこう。
ステップ1: `package.json` の設定
プロジェクトの `package.json` に、GitLabのレジストリへ向けるための設定を追加する。
{
“name”: “@your-group/your-package”,
“version”: “1.0.0”,
“publishConfig”: {
// ここでGitLabのレジストリを指定する
“@your-group:registry”: “https://gitlab.example.com/api/v4/projects/
}
}
ステップ2: CI/CDで自動発行する(.gitlab-ci.yml)
手動で `npm publish` などしてはいけない。常に自動化だ。
publish_package:
stage: deploy
script:
# GitLabの認証情報を設定
- echo “//gitlab.example.com/api/v4/projects/
/packages/npm/:_authToken=${CI_JOB_TOKEN}” > .npmrc - npm publish
only:
- tags # タグが打たれた時だけ公開する「セマンティックバージョニング」の鉄則
—
3. バージョニング管理の「黄金律」
ここで初心者が陥りやすい罠がある。それは「バージョン管理を感覚で行うこと」だ。以下のルールをチームの憲法にしてほしい。
1. セマンティックバージョニング(SemVer)を厳守せよ: `MAJOR.MINOR.PATCH`(1.2.3)のルールを守るだけで、破壊的変更による事故が激減する。
2. Gitタグとパッケージのバージョンは一致させる: GitLabのレジストリは「どのタグでビルドされたか」を常に追跡できるようにしておくべきだ。
3. スナップショット(開発版)は `alpha` や `beta` を使う: 本番向けのメインブランチ以外は、必ずプレリリース版として発行する。これにより、実験的なコードが本番環境へ混入するリスクを物理的に遮断できる。
—
4. 現場で震えるほど役立つ「ハック」
最後に、現場で重宝するプロの小技を紹介しよう。
- Dependency Proxyを活用せよ:
もし社内の通信環境が不安定なら、GitLabの「Dependency Proxy」を併用するんだ。外部のnpm registryへのアクセスをキャッシュしてくれるため、ビルド速度が爆速になる。
- トークンの使い分け:
CI/CD内では `CI_JOB_TOKEN` を使うのが基本だが、ローカル環境からデバッグ用にプッシュしたい場合は、「Scoped Access Token」を作成して、特定のプロジェクトのみ操作可能な権限を付与するのが鉄則だ。絶対に個人のマスターパスワードを直書きしてはいけない。
—
最後に:自動化こそが自由への鍵
GitLabのPackage Registryを使いこなすということは、単にファイルを保存する場所が変わるということではない。「コードの変更から利用可能になるまでのリードタイムをゼロに近づける」という思想を導入するということなんだ。
最初は設定ファイルと睨めっこする時間が必要かもしれない。だが、一度このフローを構築してしまえば、あなたは「ライブラリの配布作業」という退屈なルーチンから解放され、より創造的なコードを書く時間に専念できるようになる。
さあ、今すぐあなたのプロジェクトに最初のタグを打ってみよう。その瞬間、あなたの開発環境は一段上のステージへ昇華するはずだ。
応援しているよ、エンジニア。何か詰まったら、いつでもまた聞きに来てくれ。