LabKit ノーススター戦略

用語集

• プラットフォームオファリング - インフラストラクチャプラットフォームチームからエンジニアに公開される機能。 例としては、ロギングやメトリクスがあります。

概要

このドキュメントは、すべての GitLab プラットフォーム全体で一貫した、標準化され、シームレスな運用を実現するために 必要な LabKit エコシステムを概説します。

モチベーション

インフラストラクチャチームが、エンジニアに最高のエクスペリエンスを提供するために、一貫した方法で プラットフォームオファリングを公開できるようにしたいと思います。

FY2026 Q3 に公開された DX サーベイの結果に基づくと、エンジニアは一般的な可観測性や本番の問題を デバッグする能力などの面で苦労していました。

これはさまざまな理由によるものですが、主な理由の 1 つは、エンジニアが基盤となる GitLab の観測性インフラに シームレスに統合される採用しやすい観測性セットアップを持っていないことです。

ここで Developer Experience がステップインし、内部的にバーを引き上げ、大多数のユースケースに対応できる 一貫して表現力豊かなセットアップを提供します。

LabKit に一貫した機能を確立することで、エンジニアが断片化した、または存在しない観測性セットアップを持つ システムを提供することを避け、チームが高品質なビジネス価値を提供するのにかかる時間を直接短縮します。

DX サーベイの結果

2025 年 8 月 31 日の DX サーベイ では、このプロポーザルが 対処しようとするエンジニアからのコメントが多数提供されました。以下は、このプロポーザルの残りの部分を 読む際に考慮していただきたいサーベイから引用したコメントです:

• 「私たちのロギングには規約の標準がありません。」
• 「一貫性: ロギングの一貫性が低い。」
• 「ログに残していないことが多い。真の観測性レイヤーがあると非常に役立つ。」
• 「本番の問題のデバッグが少し難しい。」
• 「本番の AI 機能のロギングとトレーシングが改善されることを望む。」

目標

この作業の包括的な目標は、サポートされるすべてのランタイムにわたって、クリティカルなプラットフォーム機能を ラップし、採用コストを削減する一貫したライブラリセットを提供することです。

さらに、以下を解決します:

• プラットフォームレベルの機能を公開したいチームが、会社内のすべてのエンジニアにプラットフォームレベルの 機能を公開するために準拠できるパターンの確立。
• コアプラットフォーム機能とのインタラクションの散在した断片化したロジックを削減する。
• プラットフォームチームがより速くイテレーションし、システム全体に広範な変更をロールアウトできるようにする。
• インシデントの数と影響を減らし、エンジニアが本番の問題を調査する方法を改善する。
• これらのコアプラットフォーム機能を利用しようとするエンジニアの開発者エクスペリエンスを、 これらのライブラリの採用を通じて改善する。

LabKit とは?

LabKit はサービスのために有効なすべてのプラットフォーム機能を公開する抽象化レイヤーとして機能します。 これには以下のものが含まれますが、これらに限定されません:

• サービスディスカバリー
• スケーリング
• ロギング
• トレーシング
• ヘルスチェック
• フィーチャーゲート
• レートリミット

LabKit は、インフラストラクチャチームが新しいプラットフォームレベルの機能を公開するための導管となります。

すべてのサービス全体での一貫性

このアプローチを選択することで、内部エンジニアがこれらのプラットフォームオファリングとインタラクションするための サービスをセットアップする方法に関する一貫性を確保しようとしています。

このアプローチは、これらの機能それぞれの採用にかかる時間を短縮し、GitLab 固有の複雑さを、 これらのオファリングを管理する各インフラストラクチャチームが所有できる単一の場所に集中させることを可能にします。

アーキテクチャの疎結合

これらの抽象化の薄さや厚さは公開される基盤のプラットフォーム機能に依存しますが、 これらの抽象化は重要です。

現在、さまざまなエンジニアリングチームとコアプラットフォーム機能の現在のオファリングとの間に 緊密な結合が存在します。これは LabKit が直接焦点を当てて取り除くものです。

LabKit を介して一貫した方法でこれらの基盤のプラットフォームオファリングとインタラクションするようにチームが 確保することで、これらの基盤機能を管理するコアプラットフォームチームがそうでなければ可能なよりも はるかに速く安全に動くことができるようになります。

仮定的な例として、「Observability チームがすべてのサービス全体のすべてのログを OTEL フォーマットに 標準化したい」という状況が考えられます。現在のモデルでは、Observability チームがすべてのサービスにわたる 一連の複雑で潜在的に高リスクな変更を行う必要があります。

新しく提案されたモデルでは、LabKit ランタイムにまたがる一連の MR でこの変更を提供する自由があり、 基盤となるサービスは新しいフォーマットに準拠するために LabKit バージョンをバンプするだけで済みます。

エンジニアリング品質の向上

上記のすべての要素が、GitLab 製品を構成する既存のサービスだけでなく、すべての新しいサービスに 入るエンジニアリング品質の向上に直接影響します。

エンジニアリングチームが業界標準のプラクティスを適時に採用し、車輪を再発明することなく採用できるよう 支援しています。

このアプローチは、LabKit に保持された抽象化のレビューと改良により多くの時間を費やすことを奨励します。 これらの抽象化の開発は製品のデリバリータイムラインに直接結びついていません。

エンジニアが製品デリバリータイムラインとともにこれらのコアプラットフォーム関数に対して 十分に適切なローカル抽象化を定義することはありません。

ノーススター

上記を要約すると、LabKit はすべてのエンジニアがコアプラットフォームとインフラストラクチャ機能とインタラクションする 必要がある際に採用しなければならないライブラリセット（最初はメイン言語である Ruby と Go に焦点を当てて）です。

LabKit はインフラストラクチャプラットフォームチームが公開する主要なプラットフォーム機能を抽象化します。

これらの抽象化はインフラストラクチャプラットフォームチームが所有します。

すべての新しいプラットフォームオファリングは対応する LabKit パッケージとともに提供される必要があります。

LabKit は GitLab 全体の任意のシステムで簡単にプラグインして採用できる必要があります。

LabKit は意味がある場所でさまざまなランタイムにわたって機能の同等性を提供すべきです。

ガバナンスモデル

オーナーシップモデル

Developer Experience チームはすべての言語実装を含む LabKit を製品として所有します。このオーナーシップには以下が含まれます:

• すべての変更に対する最終承認権限
• ロードマップの優先順位付けとバックログ管理
• 実装間の一貫性と品質の確保
• ドキュメントと採用サポート

ただし、LabKit はオープンコントリビューションモデルで運用されます。インフラストラクチャプラットフォームチーム、 アプリケーションチーム、個々のエンジニアはコントリビュートするよう奨励されています。Developer Experience チームは 唯一の実装者ではなく、スチュワードとして機能します。

規約の一貫性

言語にわたる LabKit の実装は概念的な一貫性を維持する必要があります。言語間のイディオム的な違いは 予想されており奨励されていますが、以下は一貫している必要があります:

• パッケージ/モジュール構造と命名
• 設定パターンとオプションの命名
• フィールド名とログフォーマット（フィールドパッケージのコントラクトに従って）
• 同等の機能の動作セマンティクス
• エラー処理の哲学

確立された規約からの逸脱には、文書化された正当化と Developer Experience チームからの承認が必要です。 相互運用性や運用上の一貫性に影響する重大な逸脱は、アーキテクチャレビュープロセスに従った広範な合意が必要です。

アーキテクチャレビュー

LabKit は GitLab のアーキテクチャで特権的な位置を占めています。LabKit への変更はすべての採用サービスに 伝播し、特定の変更を組織のファクトアーキテクチャの決定にします。

アーキテクチャレビューが必要な変更には以下が含まれます:

• 新しいプラットフォーム機能の追加（新しいパッケージまたは主要な機能）
• 特定の技術の採用を義務付けたり強く推奨する変更（トレーシングバックエンド、サービスメッシュの実装、ディスカバリーメカニズム）
• 移行パスを提供する場合でも、パブリック API への破壊的変更
• サービス全体の運用動作に影響する変更（ログフォーマット、メトリクスのカーディナリティ、デフォルトのタイムアウト）
• ライセンスやセキュリティへの影響を持つ新しい外部依存関係の導入

レビュー権限:

アーキテクチャカウンシルが確立されるまで、このカテゴリの変更には関連するドメインの専門知識を持つ Distinguished Engineer または Engineering Fellow からの承認が必要です。承認者はマージリクエストに文書化されます。

アーキテクチャカウンシルが稼働すると、その組織が LabKit へのアーキテクチャ変更のレビュー権限を引き継ぎます。 Developer Experience チームは、カウンシルのインプットが必要な LabKit の変更のために常設アジェンダアイテムを維持します。

プロセス:

1. 提案者が変更とそのアーキテクチャへの影響を説明するブループリント MR を開きます
2. Developer Experience チームがトリアージして必要なレビュアーを識別します
3. アーキテクチャレビューが適宜非同期または予定された議論で行われます
4. 実装が進む前にブループリントのマージャーによって承認が記録されます

バージョニングと互換性

LabKit の既存のアーキテクチャガイドラインは後方互換性があり前方拡張可能な API を義務付けています。 設定インジェクションインターフェースは、既存のサービス設定を壊すことなく LabKit がデフォルトを提供できるように 関数オプションを使用する必要があります。LabKit に追加された新しいプラットフォーム機能は、すでに LabKit を 使用しているサービスへの変更を必要としてはなりません。

LabKit はセマンティックバージョニングに従います。基盤インフラとしての位置を考えると:

• メジャーバージョンのバンプ（破壊的変更）は少なく、十分にコミュニケーションされるべきです
• サービスはコードを変更せずに新しいマイナーバージョンを採用できるべきです
• LabKit 経由で新しい機能を導入するプラットフォームチームは、消費するサービスに即時の変更を強制しない採用パスを提供する必要があります

LabKit ロードマップ

LabKit の開発ロードマップは、Development tooling チームによって定期的に評価され、このページで伝えられます: LabKit

機能またはロードマップへの追加のリクエスト

エンジニアは Development Tooling チームの RFH プロセスを通じて新しい機能をリクエストできます。 これらの Issue は現在のロードマップに対して評価され、該当するリクエストを実現するために基盤となる インフラストラクチャプラットフォームチームと連携します。

すべてのエンジニアは、開発ツールチームが進行中の作業を把握できるようにするために、 この相談プロセスを経る必要があります。これは、取り組みの重複を避けるために非常に重要です。

新しい言語サポートへのコントリビューション

執筆時点では、GitLab 内の主要な公式言語として Ruby と Go を公式にサポートしています。

ただし、チームが現在メンテナンスされていない言語の LabKit サポートを必要とする場合、以下が適用されます:

開始チームの責任:

• ユースケースに適した機能同等性を持つ初期実装の構築
• 既存の LabKit ライブラリと一致するテストカバレッジとドキュメントの提供
• 新しいライブラリの主要ユーザーとしての継続的なメンテナンスへのコントリビューション
• 実装が確立された LabKit の規約に従っていることの確保

Developer Experience チームの責任:

• LabKit 標準との一貫性のためのすべてのコントリビューションのレビュー
• 変更の承認とマージ
• 承認後のライブラリの長期的なオーナーシップの引き受け
• より広い LabKit エコシステムとドキュメントへの新しいライブラリの統合

新しい言語の実装は軽く行うべきではありません。このパスを検討しているチームは、ユースケースが継続的な メンテナンスの負担を正当化するかどうか、および代替アプローチが存在するかどうかを議論するために 早期に Developer Experience と連携すべきです。

決定

• ADR 001: Go サービスの HTTP ルーティングアプローチ

代替ソリューション

何もしない: 会社全体の対応するスタッフプラスエンジニアとのインタビューを通じて、 および DX サーベイを通じて、現在のセットアップが断片化しすぎており、デバッグや本番調査のニーズを 十分に対処していないことが既に判明しています。

より意見の少ないアプローチ: シニアリーダーシップとの会話を通じて、これは残念ながらオプションではないと 判断しました。成熟したエンジニアリング会社として、迅速にスケールし、タイムリーに機能を提供し続けるために ある程度の標準化を定義する必要があります。

断片化したセットアップと観測性周りの標準化の欠如により、状況によっては本番でのシステムの動作に 真の理解がほとんどない状況に至っています。

何もしないことは、システム全体でのフィーチャーフラグの状態の伝播などの悪いアンチパターンをさらに 蔓延させます。LabKit 経由で公開される標準化されたセットアップは、スムーズな採用エクスペリエンスを提供することで これらのアンチパターンに頼ることへの誘惑を減らすのに役立ちます。より簡単でアーキテクチャ的に優れたソリューションを 提供できれば、エンジニアは正しいことをする可能性が高くなります。

機会コスト

DX サーベイの結果セクションで参照されたコメントの多くが、提供されている AI 機能に焦点を当てていたことを 強調したいと思います。

このプロポーザルを採用することで、重要なビジネス価値を提供しようとしている内部エンジニアにとって 効果的に力の倍増器として機能するシステムをセットアップすることになります。

迅速に提供するプレッシャーの下にあるこれらのエンジニアが、私たちのベースラインの機能準備標準のいくつかを 自動的に満たす高品質なソフトウェアを提供することを保証するためのガードレールを提供します。

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