Buildチームの戦略ビジョン

ビルド戦略: あらゆるプラットフォームにわたる高速・安全・スケーラブルなコンポーネントデリバリー

I. 診断: ビルドプロセスの制約と製品速度への影響

現状

GitLabのビルドシステムは、ますます複雑になる製品の状況に対応するために進化してきました：80以上のアプリケーションコンポーネントが、GitLab.com、GitLab Dedicated、Omnibus GitLab、Cloud Native GitLabを含む複数のデプロイモデルにわたってパッケージ化、テスト、デリバリーされる必要があります。ビルドプロセスはほとんどのコンポーネントで類似していますが、各デプロイモデルは速度とフィードバックにおいて大きく異なります。

GitLab.comとGitLab Dedicatedチームは自社インフラを直接管理しています。彼らは1日に複数回更新をデプロイし、障害からの迅速な回復を可能にする高速なイテレーションプロセスを持っています。これは、セルフマネージドのお客様向けのはるかに遅いペースとは直接対照的です。セルフマネージドインスタンスは正式なビルド、テスト、リリースプロセスに依存しています。このプロセスはフィードバックを遅らせ、バグ修正は同じビルド、テスト、リリースプロセスに従います。機能のリリースとバグ修正のための長いリリースサイクルは、セルフマネージドのお客様にとってのGitLab体験を損ないます。

さらに、一部のコンポーネントはOmnibus GitLabとCloud Native GitLabに必要な標準的なビルドとリリースプロセスに従っていないため、GitLab.comとGitLab Dedicatedにのみ配布できます。これらのコンポーネントは通常、お客様が期待する品質を満たさず、セルフマネージドのお客様に配布するには大幅な修正が必要です。

Buildにとっての主要なボトルネックは、セルフマネージドのお客様向けに新しいコンポーネントをオンボードするのに必要な1〜複数四半期の時間です。Deliveryステージ全体での積極的な連携と容量が必要です。新しいGitLabコンポーネントをオンボードするための標準化されたセルフサービスパスがなければ、DeliveryステージはProduct デリバリーパイプラインにおける直列的なゲートになります。

セルフマネージドとGitLabマネージドデプロイメントの二分化は技術的負債への下降スパイラルを生み出しました。コンポーネントチームは十分な厳密さなしにコンポーネントをより迅速にオンボードするためにプロセスを回避します。生成された品質負債は、コンポーネントをセルフマネージドのお客様に提供するために、再作業または完全な書き直しを強いることがよくあります。複雑さの増加はさらに多くの遅延を生み出し、より多くのチームに標準化されたプロセスと要件検証を回避させます。このサイクルは運用負担を大幅に増加させ、セキュリティと互換性に関する脅威面を倍増させます。

製品デリバリーに影響を与えるペインポイント

1. セルフマネージドへの機能デリバリーはオンボーディングの複雑さとセルフサービスの欠如によって制限されている

新しい機能（特にGitLabの競争力にとって重要なAI/MLコンポーネント）を構築するチームは、複雑で非標準化されたオンボーディングプロセスなしにセルフマネージドに配布できません。この複雑さは、セルフマネージドに必要な高い品質基準（多様なお客様環境での堅牢なパッケージング、サポート、運用上の卓越性）と、標準化された再現可能な統合パスの欠如から生じています。コンポーネントのオンボーディングにはDeliveryステージ全体の複数チームの積極的な関与が必要です。セルフサービス統合のための標準化された「舗装路」がなく、明確なプラットフォーム抽象化がなく、連携の負担を軽減するための一貫した自動化もありません。コンポーネントチームは自分自身でオンボードできません。彼らは各ステップでDeliveryステージのアシスタンスに完全に依存しています。

• 例: GitLab Secrets ManagerのためのOpenBaoオンボーディングは、パッケージング、インフラ、設定の作業全体にわたって複数の四半期かかっており、すべてのステージで複数チームからの積極的な連携が必要でした。

影響: GitLabは新しく重要な機能をセルフマネージドに十分な速さで配布できず、市場投入時間と競争優位性に直接影響します。Deliveryステージはすべてのコンポーネントがコーディネートされた容量とハンドオフを待つ直列的なゲートになります。チームがブロックされると進捗が止まり、明確なセルフサービスメカニズムなしでは並列化は不可能です。さらに、チームが標準的なオンボーディングプロセスを迂回してお客様に早く届けようとすると、品質とユーザー体験の問題を抱えるリスクがあり、運用負担とお客様満足度に影響します。

2. 分散した依存関係管理がフィードバックを遅らせ、サイクルタイムを延長する

各コンポーネントチームが独立して依存関係を管理することで、断片的な依存関係の状況が生まれます。更新が試みられると、パッケージアセンブリ中に競合する依存関係バージョンが表面化し、複数のチームにわたる連携が解決に必要です。この分散化はビルドフィードバックループの遅さとの相乗効果で問題を増幅させます。

• 依存関係の更新が遅く、エラーが起きやすい
• セキュリティパッチがチーム間の競合解決を待つ間遅延する
• MRのビルドパイプラインは、どのコンポーネントが変更されたかに関係なく、サポートされているすべてのOSディストリビューションにわたって最初からスタック全体を再ビルドするため、30分〜2.5時間かかることがある
• このアーキテクチャの決定はスケールしない：コンポーネント数、サポートされているディストリビューション、アーキテクチャ、提供物が増えるにつれて、パイプラインの負担も増える
• ビルドパイプラインの障害がリリース時間近くに表面化し、開発中ではないため、開発者は重大な問題に関する遅いフィードバックを受け取る

影響: フィードバックループが遅いと、高速なイテレーションが妨げられます。開発チームは正規のビルドプロセスへの信頼を失い、ローカルの乖離したビルド環境に投資し、ドリフトを深め、問題の検出をさらに遅らせる悪循環を生み出します。

3. 断片的なビルドインフラと一貫性のない環境が問題を後期まで隠す

コンポーネントチームとBuildチームは乖離したビルド環境で運用しています。この断片化は、複数のパッケージバリアントを維持する必要性と組み合わさって、統合の問題を最終リリースステージまで隠す複雑で手動の運用負担を生み出します。

• 80以上のコンポーネントチームがそれぞれ独自のビルド環境（カスタムコンテナ、乖離したツールチェーン）を維持している
• BuildチームはリリースアーティファクトのためのCanonical環境を運用しているが、この乖離により競合は最終パッケージアセンブリ時のみに表面化する
• 56の異なるLinuxパッケージを維持する必要がある（14ディストリビューション × 2アーキテクチャ × 2提供物）
• 脆弱性のトリアージは手動で非効率：1つのCVEがサポートされているすべてのOSディストリビューション全体への影響を分析・理解し、すべてのバリアントのマトリックスにわたるパッチ適用を連携させる必要がある
• ビルドと配布のプロセスが緊密に結合している：OmnibusとCloud Native GitLabは個別のビルドパイプラインとアーティファクト製造プロセスを持っており、単一のアーティファクトを配布方法にわたって再利用できない

影響: 高い運用上のToil；セキュリティ対応の遅さ；リソース集約的な脆弱性修正。遅れて発覚する問題がリリースを遅延させ、緊急のエスカレーションオーバーヘッドを増加させます。新しいOSディストリビューションの追加や新しい依存関係の管理は、サポートされているすべてのバリアント全体でこの負担を指数関数的に倍増させます。

II. 指針ポリシー

戦略的原則

コンポーネントチームがビルドプロセスを配布方法から切り離すことによってセルフマネージドへのオンボーディングをセルフサービスできるようにし、同じアーティファクトをOmnibus、Cloud Native GitLab、その他のパスを通じて安全に流通させます。BuildチームはビルドプラットフォームMR、標準化されたツール、ガードレールを提供し、会社が定めた基準（言語フレームワーク、依存関係バージョン等）が満たされていることを確認しますが、それらの基準を指定したり手動のゲートキーピングを行ったりはしません。

目標

目標1: 高速でセルフサービス可能なコンポーネントオンボーディング

標準化されたツールと舗装路を通じてコンポーネントチームが独立して統合できるようにすることで、ビルド関連のオンボーディング作業を複数四半期から既知の既存パターンについては1ヶ月に短縮します。

対処するペインポイント: 1

目標2: すべてのプラットフォームにわたる統一された再現可能なビルド

すべてのコンポーネントチームとBuildチームが共有するCanonicalビルド環境とツールチェーンを確立します。最終パッケージアセンブリの前（またはCIのアップストリーム）で**ビルドIssueの100%**を検出し、早期フィードバックを可能にして後期の問題を防ぎます。

対処するペインポイント: 2 & 3

目標3: スケーラブルなビルドインフラ

ビルドプロセスを配布方法から切り離し、アーティファクト製造を標準化し、同じアーティファクトをOmnibus、Cloud Native GitLab、その他のパスを通じて流通させます。運用負担を軽減し、新しいプラットフォームへの簡単なスケーリングを可能にします。

対処するペインポイント: 3

設計原則

組織的原則

1. すべてを構築する1つの方法

すべてのコンポーネントが使用する単一のCanonicalビルドプロセスと環境があります。例外はなく、代替パスもありません。これはスケーラビリティに不可欠であり、連携オーバーヘッドを削減しながら高速なイノベーションを可能にします。

2. Buildチームはイネーブラーであり、ゲートキーパーではない

Buildチームはプラットフォーム、ツール、基準を提供します。コンポーネントチームはオンボーディングを所有し、統合作業を実行します。Buildチームはサポートとガイダンスを提供し、ハンドオフを調整するのではなく自律性を可能にします。

3. 早期バリデーションの実現

開発者はCanonical環境でできるだけ早く（理想的には開発段階またはCI）ビルドをバリデートします。早期フィードバックにより、品質の問題がリリースまで蓄積されるのを防ぎます。

4. カスタマイズよりも標準化

標準化されたソリューションをデフォルトとします。カスタムソリューションには明確なビジネス上の正当性と承認が必要です。これによりツールの増殖を防ぎ、共有された改善がすべてのチームに恩恵をもたらします。

技術的原則

5. ビルドを配布から切り離す

ビルドプロセスは単一のCanonicalアーティファクトを生成します。配布方法はそれぞれの環境向けにコンシュームしてパッケージ化します。この分離により再利用が可能になり、乖離を防ぎます。

6. 再現可能なビルド

同一の入力を使ったすべてのビルドは、以下を通じて同一の出力を生成します：

• Canonical・不変のビルド環境
• 統一されたツールチェーン（UBT）
• 確定的な依存関係の解決
• すべての依存関係とソースの完全な可視性

7. 完全な来歴とサプライチェーンの完全性

すべてのアーティファクトには、ソースコード、ビルド環境、依存関係に遡るメタデータが含まれています。これにより、トレーサビリティ、セキュリティコンプライアンス、迅速な脆弱性対応が可能になります。

8. 包括的なプラットフォームカバレッジテスト

サポートされているすべてのOSディストリビューションとアーキテクチャにわたる自動テストにより、コンポーネントが一貫した製品として連携して機能することをバリデートします。UBTを使用すると、単一のバイナリがどこでも機能する必要があり、包括的なテストはこれを確保します。

III. 一貫したアクション

主要イニシアチブ

1. プラットフォームファウンデーション（UBT + TUBE + メタパッケージ）

すべてのコンポーネントにわたって統一されたビルド環境、依存関係管理、標準化されたビルドプロセスを確立します。これには以下が含まれます：

• 一貫したコンパイラ、ビルドツール、システムライブラリを提供するUniversal Build Toolchain（UBT）
• 標準的なビルド環境と集中的な依存関係管理（TUBE）
• お客様が必要なコンポーネントのみを選択してインストールできるモジュラーメタパッケージング、リソースの無駄と運用の複雑さの削減
• ビルドプロセスを配布方法から切り離し、単一のアーティファクトが複数のパスを流通できるようにする
• 変更されたコンポーネントのみを再ビルドするインクリメンタルなコンポーネントレベルのビルド（すべてのパイプライン実行でフルスタックの再ビルドを回避）

2. セルフサービスオンボーディング（CIテンプレートと舗装路）

コンポーネントチームがBuildチームの調整なしにセルフマネージドに独立して統合できるようにします。これには以下が含まれます：

• チームが直接使用できる標準化されたCIテンプレートと設定基準
• 包括的なドキュメントとオンボーディングガイド（舗装路）
• 手動のハンドオフと連携オーバーヘッドを削減するツールと自動化
• ゲートキーパーではなくイネーブラーとしてのBuildチームのサポートとガイダンス

3. 品質とバリデーションインフラ

サポートされているすべてのプラットフォームにわたって包括的な自動テストとバリデーションを実装します。これには以下が含まれます：

• サポートされているすべてのOSディストリビューションとアーキテクチャにわたる自動テストパイプライン（QA、エンドツーエンド、スモークテスト）
• ビルドプロセスへの来歴追跡とサプライチェーン可視性の統合
• 開発者向けの早期Issue検出とフィードバックメカニズム

4. 運用上の卓越性

ビルドプラットフォームの監視と可観測性を確立します。これには以下が含まれます：

• ビルドパフォーマンスと健全性のリアルタイム可視性
• ビルド成功率、サイクルタイム、リソース使用率を追跡するメトリクスとダッシュボード
• インシデント対応とアラートメカニズム

実装ロードマップ

タイムライン概要（FY27）

ロードマップは依存関係を持つ並行ワークストリームを示しています。すべてのタイムラインは推定値であり、各フェーズのスコープと計画が完了するにつれて洗練されます。

Q1 FY27

Q2 FY27

Q3-Q4 FY27

FY27末の目標状態

• ✓ UBT完了: 4月末までにすべてのコンポーネントが統一されたツールチェーンに移行
• ✓ TUBE完了: すべての既存および新しいコンポーネントが集中的な依存関係管理に接続
• ✓ インクリメンタルなコンポーネントレベルのビルドがフルスタック再ビルドサイクルを削減、パフォーマンス向上が計測可能
• ✓ 品質とバリデーションインフラがサポートされているすべてのプラットフォームで稼働
• ✓ ビルドプラットフォームの監視、可観測性、メトリクスが整備、UBT/TUBEの価値が実証
• 目標（スコープ/計画待ち）: セルフサービスオンボーディングフレームワークが整備、初期コンポーネントが独立してオンボード完了

主要な依存関係と前提条件

• セルフサービスオンボーディングはUBTとTUBEがほぼ完了していることに依存する
• TUBEの採用はコンポーネントチームの優先度と移行意欲に依存する。Buildチームはプラットフォームを提供できるが、採用ペースはコンポーネントチームがコントロールする
• TUBEのスコープと実装タイムラインはFY26 Q4 / FY27 Q1に確定予定
• 運用上の卓越性のPOCはメトリクスを通じてUBT/TUBEの価値をキャプチャして実証するためのファウンデーションを提供する
• タイムラインは推定値であり、各フェーズで計画が進むにつれて洗練される

成功メトリクスと成果

[未記入]

リスクと緩和策

[未記入]

付録

関連ドキュメントとコンテキスト

[未記入]

用語集

[未記入]

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