Package

ミッションとビジョン

Package ステージは、様々な言語やプラットフォームにまたがるパッケージを1か所で公開・利用・検索できるようにすることで、ソースコードと依存関係の両方が共存できる安全な環境を作ります。私たちのビジョンは、DevOps ライフサイクル全体でパッケージとコンテナイメージを保存・配布するための、お客様にとって唯一の情報源となることです。

チーム構成

Package ステージは2つのグループで構成されています：

Package:Container Registry — OCI 準拠のコンテナイメージストレージのためのバックエンド Go サービス
Package:Package Registry — GitLab Rails アプリケーション内のパッケージ管理機能

チームメンバー

Package ステージは以下のチームで構成されています：

チームメンバー情報は原文 (英語) を参照してください。

ステーブルカウンターパート

ステーブルカウンターパート情報は原文 (英語) を参照してください。

パッケージフォーマット DRI

フォーマット	DRI
npm	@dmeshcharakou
Maven	@10io
PyPI	@radbatnag
NuGet	@mkhalifa3
Terraform	@radbatnag
Generic	@dmeshcharakou

作業の進め方

マイルストーン計画プロセス

私たちのマイルストーン計画はプロダクトロードマップとエンジニアリングのコミットメントと密接に連携しています。プロセスは、戦略的イニシアチブの実施とセキュリティ Issue・顧客バグ・インターロックコミットメントなどの運用ニーズのバランスを取ります。計画はエンジニアリングマネージャーが主導し、プロダクトマネージャーとデザイナーが協力して意見を出し合います。

計画ワークフロー

エンジニアリングマネージャーが計画 Issue を作成する
- Package ステージマイルストーン計画 epic を参照する
- マイルストーン用の新しい計画 Issue を作成する
- エンジニアリングマネージャー・プロダクトマネージャー・デザイナーにアサインする
- ロードマップとチームキャパシティに基づく初期目標を定義する
エンジニアリングマネージャーがサステイニングワークを追加する
- 期限が近いセキュリティ脆弱性をレビューし優先順位付けする
- バックログからマイルストーンで取り組む約8件のバグを選択する
- 期限が近いインターロックコミットメントを特定する
- バグの優先度がチームキャパシティと一致していることを確認する
- 現在の優先事項のためのトリアージレポートを確認する
プロダクトマネージャーとデザイナーが優先事項を提供する
- プロダクトマネージャーがプロダクト方針との整合性について目標をレビューする
- プロダクトマネージャーがプロダクト戦略と一致する機能 Issue を追加する
- デザイナーが UX 改善とデザイン Issue を追加する
- 両者が提案された目標とキャパシティについてフィードバックを提供する
エンジニアリングマネージャーがキャパシティ計画を確定する
- 現在のマイルストーンの Issue に適切な優先度ラベルが付いているかレビューする
- すべての Issue に Deliverable・Stretch・Package:P1・Package:P2 のいずれかのラベルが付いていることを確認する
- Issue フィルターを使ってギャップを特定する
- Go・Rails・フロントエンドエンジニアに十分な作業があることを確認する
- 機能別ブレークダウンボードを使ってキャパシティが超過していないことを確認する
次のマイルストーンとキャリーオーバーをレビューする
- 次のマイルストーンにすでにスケジュールされているものを確認する
- ワークフローボードを使って Issue のステータスを追跡する
- 完了したものとキャリーオーバーするものを特定する
- キャリーオーバーの Issue を新しいマイルストーンで更新する
プロジェクト DRI と調整する
- プロジェクトオーナーにメッセージを送り、マイルストーンの機能 Issue を追加してもらう
- 計画したすべての作業が適切にドキュメント化されリンクされていることを確認する

Issue の優先順位付け

Issue は以下のように優先順位付けされます：

Package:P1: マイルストーンのコミット作業
Package:P2 + Stretch: キャパシティが許せばのストレッチ目標
Deliverable: 開発準備が整った P1 Issue

ロードマップ外で計画されるアイテムには以下が含まれます：

セキュリティ脆弱性（SLA を満たすため）
優先度の高い顧客バグ
インターロックコミットメント（Geo・Protocells など）
小規模な信頼性・パフォーマンス修正

計画チェックリスト

包括的なマイルストーン計画のためにこのチェックリストを使用してください：

セキュリティ脆弱性がレビューされ優先順位付けされている
優先度の高いバグが特定されアサインされている
インターロックコミットメントがドキュメント化されている
すべての P1 Issue に重みが付き整理されている
前のマイルストーンからのキャリーオーバー作業が更新されている
次のマイルストーンのプレビューが完了している
プロジェクト DRI が計画作業について通知されている
新機能のインストルメンテーション要件が定義されている
Go・Rails・フロントエンドエンジニアのキャパシティが確認されている

主要な計画リソース

機能別ブレークダウンボード — マイルストーン全体で機能別に Issue を表示
マイルストーンボード — 機能別に分類された Issue を確認
ワークフローボード — マイルストーン全体で Issue のステータスを追跡
トリアージレポート — 現在のバグ優先度

スタイルガイドラインとアーキテクチャ標準

効率的なコードレビューとメンテナーの承認を確保するため、すべての貢献は確立されたスタイルガイドラインとアーキテクチャ標準に従う必要があります。

フロントエンド開発

バックエンド開発

Container Registry（Go）

セキュリティとコンプライアンス

破壊的変更を実装する前に破壊的変更と廃止予定のガイドラインをレビューする
セキュリティのベストプラクティスに従う
セキュリティに影響する変更は AppSec レビューを確保する

開発者ワークフローと貢献プロセス

Issue の整理（リファインメント）

開発を始める前に、Issue が適切に整理されていることを確認します：

重み付け: すべての Issue に重みの見積もりが必要（1〜5のスケール）
実装計画: 技術的なアプローチと依存関係を含める
完了の定義: 「完了」の意味を明確に定義する
ラベル要件: タイプ・カテゴリー・ワークフロー・Package:P1 または Package:P2 の適切なラベルを適用する
マイルストーン割り当て: Issue が正しいマイルストーンに割り当てられていることを確認する

整理が必要な Issue フィルターを使って注意が必要な作業を特定します。

インストルメンテーションは、影響と効果を測定するためのすべての機能における主要な要件です。これにより採用状況を検証し、データ駆動の意思決定ができるようになります。

非同期更新

非同期更新の目的は、進捗を伝え、今後の作業に向けて他者が準備できるようにすることです。フルリモートのカルチャーでは、更新を非同期で行い、直接 Issue に記録します。

週に1回、または注目すべきことが起きたときに、Issue にコメントを追加します（タイトルは Async Update）。マージリクエストではなく Issue を更新することをお勧めします。

非同期更新コメントには以下を含めます：

完了率（必要なすべての MR をレビューに出すのにどれだけ完了しているか）
見積もりの確信度
実施内容とレビューが開始されているかどうかのメモ
Issue に複数の人が取り組んでいる場合はフロントエンドまたはバックエンドの文脈
ブロッカーまたはリスク

ラベル要件

作業を始める前に、Issue に以下のラベルが付いていることを確認します：

タイプ: type::feature・type::bug・または type::maintenance
カテゴリー: Category:Container Registry・Category:Package Registry・または Category:Virtual Registry
優先度: Package:P1・Package:P2・または適切な優先度ラベル
ワークフロー: 開始前に workflow::ready for development
マイルストーン: 現在または計画されたマイルストーンに割り当て

デザインとプロダクトとの連携

デザインとのコラボレーション: リファインメントフェーズの早い段階でデザイナーと協力する
UX レビュー: 該当する場合は実装前に UX フィードバックを求める
プロダクトとの整合: 開始前にプロダクトマネージャーと機能スコープを確認する
デザインの引き継ぎ: 開発を始める前にデザイン仕様が完成していることを確認する

AppSec レビュープロセス

セキュリティに影響する変更については：

認証・認可・データ処理・外部統合に変更が影響するかどうかを特定する
開発プロセスの早い段階で AppSec レビューを要求する
実装計画にセキュリティの考慮事項を含める
MR でセキュリティのベストプラクティスを参照する
マージ前にすべての AppSec フィードバックに対処する

コードレビューとマージプロセス

レビューを要求する前にすべてのスタイルガイドラインに従っていることを確認する
コンテキストとテストアプローチを含む明確な MR の説明を含める
すべてのレビューフィードバックに速やかに対処する
適切なメンテナーからの承認を得る
マージ前に CI/CD パイプラインが通っていることを確認する

ヘルプリクエスト（RFH）プロセス

Package チームは、サポートチームがエスカレーションした顧客の Issue をサポートするために GitLab のヘルプリクエスト（RFH）プロセスに参加しています。RFH の Issue は gitlab-com/request-for-help リポジトリで追跡されます。

RFH の仕組み

サポートが顧客の Issue を Package チームにエスカレーションする際、次のいずれかのテンプレートを使って RFH Issue を作成します：

チーム全体がグループメンション（@gitlab-org/ci-cd/package-stage/container-registry-group または @gitlab-org/ci-cd/package-stage/package-registry-group）で通知を受け、Issue には適切なヘルプグループラベルが付きます。

レスポンスタイム SLO

Package チームは、request-for-help ハンドブックページのタイムラインに基づく初回レスポンスタイム（FRT）SLO に従うことを約束しています。

これらの SLO は初回レスポンスを提供するまでの時間を表しており、必ずしも完全な解決までの時間ではありません。

チームワークフローへの RFH の組み込み

監視とトリアージ

Package チームに割り当てられた新しい Issue のために RFH リポジトリを定期的に確認する
新しい RFH Issue が作成されたときの Slack のグループメンションに応答する
Issue をトリアージして、即座の対応が必要か予定に組み込めるかを判断する

優先順位付け

RFH の Issue は SLA 要件を満たす場合、通常は計画作業より優先される
Severity 1・2 の Issue は即座のコンテキスト切り替えが必要な場合がある
Severity 3・4 の Issue は SLO ウィンドウ内に対処すべきだが、現在または次のマイルストーンに組み込むことができる
SLO 内に対応できない RFH はエンジニアリングマネージャーにエスカレーションする

RFH Issue の処理

初回レスポンス: Issue を確認し、可能であれば初期調査または回避策を提供する
調査: Issue がバグ・ドキュメント不足・期待通りの動作のいずれかを判断する
解決パス: 以下のいずれかを選択する：
- 回避策を提供する
- 必要に応じてメインの GitLab プロジェクトにバグレポートを作成する
- ドキュメントまたは設定ガイダンスを提供する
- 重大なエンジニアリング作業が必要な場合はエスカレーションする
コミュニケーション: 進捗と次のステップをサポートチームに継続的に伝える
クローズ: 解決したら、適切なクローズラベルを適用し、レトロスペクティブフィードバックを完了する

クローズラベル

RFH Issue をクローズする際は、解決状況をドキュメント化するためにこれらのラベルのいずれかを適用します：

Closed::Workaround — 回避策で Issue が解決された
Closed::Bug Fixed — バグが特定され修正された
Closed::Other Request — 関連する機能リクエストまたはバグレポートが公開トラッカーに作成された
Closed::Moved to Public Issue — 回避策が見つからず、公開 Issue に移動した
Closed::No Solution — 詳細不足のため対応できなかった
Closed::Insufficient Information — 運用上またはプロダクト外の Issue
Closed::Documentation — 既存のドキュメントに従うことで解決された

レトロスペクティブ

RFH Issue に retrospective::started のマークが付いた場合、以下についてフィードバックを提供します：

この RFH を防ぐために何ができたか？（ドキュメント不足・プロセスが不明確・ツールのギャップ）
顧客が独自に解決するために役立った資料やリソースは何か？
セルフサービスの提供改善のための提案

完了したら、ラベルを retrospective::completed または retrospective::not needed に更新します。

主要リソース

Issue 管理

バックログラベリングプロセス

Issue をトリアージする際は、コミットメントレベルに基づいて適切なバックログラベルを適用します：

backlog::prospective: 今後24か月以内に取り組む予定の Issue
backlog::no-commitment: ユーザーの関心はあるが今後24か月間での優先は見込みにくい Issue

タイプ別の Issue 整理

機能 Issue（`type::feature`）

適切な epic にアサインする
すべての epic に優先度ラベルを適用する（priority::1 から priority::4）
サポートされていないフォーマット（Go リポジトリ・RPM）の Issue はクローズする
需要が低いフォーマットリクエストを backlog::no-commitment に移動する（Rust・Dart・Swift など）

メンテナンス Issue（`type::maintenance`）

関連するメンテナンス epic にアサインする：
- Package Registry メンテナンス Epic（&19029）
- Container Registry メンテナンス Epic（&19037）
サブ epic のカテゴリー：
- セキュリティとコンプライアンス
- パフォーマンス最適化
- インフラ & 運用
- データ管理 & クリーンアップ
- コード改善
- テスト & QA
- ドキュメント

バグ Issue（`type::bug`）

適切なトリアージのために優先度ラベルを適用する
解決予定のバグには backlog::prospective ラベルを付ける
現在のロードマップに適用されなくなった古いバグはクローズする

Epic 管理

断片化を減らすために関連する epic を統合する
重複する epic を削除する
すべての見込み epic にスコープ付きの優先度ラベルがあることを確認する
定期的に epic のスコープをレビューし、重複するイニシアチブを統合する

非同期 Issue 更新

非同期更新の目的は、進捗を伝え、必要に応じて今後の作業に向けて他者が準備できるようにすることです。フルリモートのカルチャーでは、更新を非同期で行い、直接 Issue に記録します。

非同期更新は Issue コメントとマイルストーンのヘルスステータスを使って進捗と確信度を伝えます。週に1回、または Issue に関して注目すべきことが起きたときに、タイトルが Async Update の Issue コメントを追加します。関連するマージリクエストではなく Issue を更新することをお勧めします。

非同期更新コメントには以下を含めます：

作業が何パーセント完了しているか（必要なすべての MR をレビューに出すのにどれだけ完了しているか）
見積もりが正しいという確信度
実施内容やレビューが開始されているかどうかのメモ
Issue に複数の人が取り組んでいる場合はフロントエンドまたはバックエンドの更新かどうかを含めると良い

Issue 重み付けガイドライン

重み	説明	確信度
1: 微小	十分理解されており調査不要、解決方法が明確	≥90%
2: 小	十分理解されており最小限の調査が必要、サプライズが少ない	≥75%
3: 中	十分理解されているが調査が必要、サプライズが想定される	≥60%
より大きい	より小さい Issue に分解すべき	≥50%

重み1の Issue は2日以内に完了するはずです。

現在のプロジェクト

Container Registry

メタデータデータベース GA（DRI: @hswimelar）
データベース負荷分散（DRI: @jdrpereira）
バックグラウンドマイグレーションサポート（DRI: @suleimiahmed）
ベータ: Docker バーチャルレジストリ（DRI: @adie.po）

Package Registry

バーチャルレジストリサポート（Maven・npm・PyPI・NuGet）（DRI: @10io）
Dependency Firewall（DRI: @dmeshcharakou）
パッケージフォーマット改善（DRI: @radbatnag）
テスト安定性の強化（DRI: @radbatnag）

技術ガイドライン

破壊的変更プロセス

破壊的変更を発表または進める前にリーダーシップの承認が必要なため、破壊的変更・廃止予定・削除のガイダンスをレビューして従ってください。

新しいパッケージフォーマットのリリース

新しいパッケージフォーマットのリリースには以下の構造化されたプロセスに従います：

実験フェーズ
- ステージング環境でフィーチャーフラグを有効化
- 包括的なテスト：
  - 小規模・大規模パッケージ操作
  - 数百のパッケージでのパフォーマンス
  - サポートされているすべての認証方法
  - GitLab 固有のカスタム機能
- フィーチャーフラグロールアウト Issue に問題を記録する
ベータフェーズ
- GitLab.com への限定ロールアウト
- 内部チームによるドッグフーディング
- 選択した顧客によるテスト
- バグのトリアージと解決
一般公開（GA）
- 完全なドキュメント更新
- フィーチャーフラグの削除
- セルフマネージドリリース
- リリースコミュニケーション

バックエンドとフロントエンドに関連する変更の適切な処理を確保するためにマルチバージョン互換性ガイドラインをレビューしてください。

アラートと CI フレーク管理

チームはサービスアラートと CI 通知のために Slack チャンネル #g_container-registry_alerts を監視しています。アラート処理のプロセス：

全員が作業時間中にアラートを監視する責任がある
新しいアラートが表示されたとき：
- 👀 絵文字を追加して調査中であることを知らせる
- アラートの詳細を確認する（ランブック・ダッシュボード・パイプライン・Sentry Issue）
- 利用可能なリソースを使って問題を評価する
- 以下に基づいて無視しても安全かどうかを判断する：
  - 既存の Issue カバレッジ
  - 自動解決
  - 解決を示すログ
- 無視しても安全でない場合：
  - #production と #incidents-dotcom チャンネルをレビューする
  - インシデントの報告を検討する
  - 詳細を #g_container-registry で共有する
- レビューをドキュメント化するためにコメントスレッドを追加する
- 解決したら ✅ 絵文字を追加する

アラート発生テンプレート

## Alert Occurrence Update
- **Occurrence Count**: X (previously Y)
- **Date/Time**: [Insert timestamp]
- **Last occurrences**: [Insert slack link]

主要リソース

プロダクトコンテキスト

Container Registry の歴史

もともとマイルストーン 8.8 でリリースされた Container Registry は、Docker Distribution レジストリを GitLab に統合しました。主な課題はストレージ管理でした。削除されたイメージは、ダウンタイムが必要なガベージコレクションなしでは実際にはストレージから削除されませんでした。

この問題に対処し将来の機能を可能にするために、私たちは：

Docker Distribution をフォークした
オンラインガベージコレクションを実装した
メタデータデータベースを追加した
クリーンアップポリシーを作成した

この作業により、以下の将来の機能が可能になります：

より堅牢な API と UI
エンタープライズ機能（イメージ署名・保護）
安定性と信頼性の向上

レジストリは、Docker 仕様との後方互換性を維持しながら、Image および Distribution 仕様の OCI 標準に準拠しています。

結果の測定

主要パフォーマンス指標

Lighthouse メトリック: （公開パッケージ数 + 公開コンテナ数）/ 課金対象ユーザー数
月次アクティブユーザー（GMAU）
エラーバジェット準拠
配信コミットメントに対する言行一致率
運用コスト：
- ストレージコスト
- データ転送コスト

ダッシュボード

追加リソース

Package 品質ガイドライン
Package ジョブトゥービードン
Container Registry ドキュメント
Package Registry ドキュメント
チーム YouTube チャンネル（デモ・チームミーティング・顧客サマリー・ユーザーインタビューを含む）

Package グループ - GitLab 品質保証エンドツーエンドテスト

テスト戦略ローカル開発テストユニットテスト Container Registry（Go）: make test Package Registry（Rails）: bundle exec rspec …

Package ステージ — お客様にとって最も重要なユースケース

概要このページの目的は、Package ステージのジョブトゥービードン（JTBD）とそれに対応するジョブステートメントを作成・共有・イテレーションすることです。私たちの目標は、JTBD フレームワー …

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)

ページのソースコードを見る - ページの編集 - please contribute.

Package

ミッションとビジョン

チーム構成

チームメンバー

ステーブルカウンターパート

パッケージフォーマット DRI

作業の進め方

マイルストーン計画プロセス

計画ワークフロー

Issue の優先順位付け

計画チェックリスト

主要な計画リソース

スタイルガイドラインとアーキテクチャ標準

フロントエンド開発

バックエンド開発

Container Registry（Go）

セキュリティとコンプライアンス

開発者ワークフローと貢献プロセス

Issue の整理（リファインメント）

非同期更新

ラベル要件

デザインとプロダクトとの連携

AppSec レビュープロセス

コードレビューとマージプロセス

ヘルプリクエスト（RFH）プロセス

RFH の仕組み

レスポンスタイム SLO

チームワークフローへの RFH の組み込み

クローズラベル

レトロスペクティブ

主要リソース

Issue 管理

バックログラベリングプロセス

タイプ別の Issue 整理

機能 Issue（type::feature）

メンテナンス Issue（type::maintenance）

バグ Issue（type::bug）

Epic 管理

非同期 Issue 更新

Issue 重み付けガイドライン

現在のプロジェクト

Container Registry

Package Registry

技術ガイドライン

破壊的変更プロセス

新しいパッケージフォーマットのリリース

アラートと CI フレーク管理

アラート発生テンプレート

主要リソース

プロダクトコンテキスト

Container Registry の歴史

結果の測定

主要パフォーマンス指標

ダッシュボード

追加リソース

Package グループ - GitLab 品質保証エンドツーエンドテスト

Package ステージ — お客様にとって最も重要なユースケース

機能 Issue（`type::feature`）

メンテナンス Issue（`type::maintenance`）

バグ Issue（`type::bug`）