正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

異なる開発ステージにある機能のサポート

GitLabは、実験的ステージやベータ版など、さまざまな開発ステージで機能をリリースする場合があります。ユーザーはオプトインして新しいユーザーエクスペリエンスをテストできます。これらの機能リリースの理由としては、次のようなものがあります:

  • 設計されたあらゆるユースケースにおいて、現在の形式の機能のスケール、サポート、およびメンテナンスの負担のエッジケースを検証します。
  • MVCと見なされるには不完全な機能でも、開発プロセスの一部としてコードベースに追加されます。

一部の機能は、推奨事項が策定される前に開発された場合や、チームが代替の実装アプローチが必要であると判断した場合には、これらの推奨事項に沿わない場合があります。

その他のすべての機能は、一般公開されていると見なされます。

実験

実験的機能:

  • 本番環境での使用には適していません。
  • 提供されているサポートはありません。このような機能に関するイシューは、GitLabイシュートラッカーで提起する必要があります。
  • 不安定である可能性があります。
  • いつでも削除される可能性があります。
  • 一般公開に至らない可能性があります。
  • データ損失のリスクがある可能性があります。
  • ドキュメントがない場合や、GitLabイシューまたはブログに限定された情報しかない場合があります。
  • 最終的なユーザーエクスペリエンスが確立されていない場合があり、クイックアクションまたはAPIリクエストからのみアクセスできる場合があります。

ベータ

ベータ機能:

  • 本番環境での使用には適していない可能性があります。
  • 商業的に合理的な努力に基づきサポートされますが、イシューのトラブルシューティングには開発からの追加の時間と支援が必要となる場合があります。
  • 不安定である可能性があります。
  • 変更される可能性が低い設定と依存関係があります。
  • 変更される可能性が低い機能があります。ただし、主要なリリース以外で、または一般公開されている機能よりも少ない通知で破壊的な変更が発生する可能性があります。
  • データ損失のリスクが低い。
  • 完了済みまたはほぼ完了のユーザーエクスペリエンスがあります。
  • パートナーの「Publicプレビュー」ステージと同等である場合があります。

公開の可用性

2種類の公開リリースが利用可能です:

  • 利用制限
  • 一般提供

両方のタイプが本番環境対応ですが、異なるスコープを持っています。

限定提供

限定提供機能は一般公開機能と同じセキュリティ要件に従いますが、最初のロールアウト時にプラットフォームのサブセットまたはスケール制限付きでデプロイされる場合があります。

限定提供機能:

  • 縮小されたスケールでの本番環境使用に対応しています。
  • 最初に1つ以上のGitLabプラットフォーム (GitLab.com、GitLab Self-Managed、GitLab Dedicated) で利用できます。
  • 最初はFree版として提供され、一般公開時に有料になる場合があります。
  • 一般公開される前に割引が提供される場合があります。
  • 一般公開時に新規契約の商用条件が変更される場合があります。
  • 完全にサポートされており、文書化されています。
  • GitLabデザイン標準に準拠した完全なユーザーエクスペリエンスを備えています。

一般公開

一般公開機能:

  • あらゆるスケールでの本番環境使用に対応しています。
  • 完全にサポートされており、文書化されています。
  • GitLabデザイン標準に準拠した完全なユーザーエクスペリエンスを備えています。
  • すべてのGitLab提供製品 (GitLab.com、GitLab.com Cells、GitLab Self-Managed、GitLab Dedicated、GitLab Dedicated for Government) で利用可能である必要があります。
  • GitLab Duo Agent Platformでの一般公開機能の使用は、GitLabクレジットを消費します。機能が最新のGitLabバージョンで一般公開されると、すべてのバージョンと提供製品でその機能の使用によってクレジットが消費され始めます。ベータ機能は、いつでも使用量課金によって一般公開に変更される可能性があります。

機能リリース要件

GitLabのチームは、ユーザーが機能を利用できるようになる前に、上記のステータスガイダンスと各開発ステージの要件を考慮する必要があります。

用語

明確にするために、これらのガイドラインでは次の定義を使用します:

  • Explicit opt-in: 機能はデフォルトで無効になっており、認証されたユーザー（機能のスコープに応じて、インスタンス管理者、グループオーナー、または個々のユーザーなど）による意図的な有効化アクションが必要です。有効化できるが、アクティベートされない限り無効のままの機能は、明示的なオプトインを必要とすると見なされます。
  • Enabled by default: 機能はオプトインアクションを必要とせずに、ユーザーまたはインスタンスでアクティブになります。機能は実験的ステージまたはベータステージの間は、デフォルトで有効化されていてはいけません。
  • Production use: 両方を指します:
    • 顧客の本番環境ワークロード (ユーザーがビジネス運用に依存する機能)
    • GitLabが管理する本番環境インフラストラクチャ (GitLab.com、GitLab Dedicated、およびDedicated for Federalをサポートする、プラットフォームの信頼性またはセキュリティに影響する共有サービス)
  • Internal testing: GitLabチームメンバーによる検証目的でのGA前の機能の使用。カスタマーゼロとも呼ばれます。

機能の成熟度移行原則

機能が成熟度ステージに進む準備ができているかを評価する際には、incident response testを適用してください:

「この機能がすでに目標とする成熟度レベルに達しており、このリスクが顕在化した場合、インシデントを宣言し、緊急の修正をプッシュするでしょうか?」

機能は、GA後に発生した場合にインシデント対応をトリガーするようなリスクを伴ってGAに移行すべきではありません。これには以下が含まれます:

  • 重大な (S1/S2) セキュリティ脆弱性
  • SLAのコミットメントに違反するパフォーマンス低下
  • 顧客への通知が必要なデータ整合性イシュー
  • プラットフォームの安定性に影響する可用性の影響

この原則は、機能が予測可能な将来のインシデントを作成するのではなく、適切なリスク姿勢で本番環境の成熟度に達することを保証します。

実験的機能

  • デフォルトで無効になっており、明示的なオプトインが必要です。顧客のアクションなしに、ユーザーまたはインスタンスに対して自動的に有効にすることはできません。
  • マルチテナントプラットフォームでは、オプトインしたユーザーが他のテナントにリスクをもたらさないように、テナントの分離を維持する必要があります。
  • リリースの成熟度の現状に応じて、標準的な (修正プログラム公開時) でセキュリティ修正がリリースされる場合があります。標準的な脆弱性修正サービスレベル目標は、実験的機能には適用されません。
  • 明記されたベータ版要件を満たさずにベータ版に移行するための例外については、VPの承認が必要です。

Internal testing (カスタマーゼロ) は、実験的機能をエンジニアリング検証に使用する場合があります。全社的なビジネスプロセス (オンボーディング、アクセス管理、コンプライアンスワークフローなど) に影響する機能は、エンジニアリングおよびセキュリティリーダーシップからの文書化されたリスク受容が必要です。

ベータ機能

  • デフォルトで無効になっており、明示的なオプトインが必要です。顧客のアクションなしに、ユーザーまたはインスタンスに対して自動的に有効にすることはできません。
  • マルチテナントプラットフォームでは、オプトインしたユーザーが他のテナントにリスクをもたらさないように、テナントの分離を維持する必要があります。
  • 一般公開前に、セキュリティリリースプロセスを確立するための文書化され、利害関係者と合意した計画が必要です。このプロセスは、脆弱性がどのように特定、追跡、優先順位付け、修正され、調整された開示を通じて伝達されるかを含め、時期尚早な公開なしにセキュアな脆弱性修正を可能にする必要があります。
  • リリースの成熟度の現状に応じて、標準的な (修正プログラム公開時) でセキュリティ修正がリリースされる場合があります。標準的な脆弱性修正サービスレベル目標は、ベータ機能には適用されません。
  • 一般公開前に、監査ログを実装するための文書化され、利害関係者と合意した計画が必要です。この計画では、どのようなイベントが記録されるか、ログのフォーマットと保持、セキュリティチームがログにアクセスする方法、および既存の監査ログシステムとのインテグレーションポイントを具体的に定める必要があります。
  • 明記されたGA要件を満たさずにGAに移行するための例外については、eグループの承認が必要です。

制限付き利用可能機能

  • 時期尚早な公開なしにセキュアな脆弱性修正を可能にする運用可能なセキュリティリリースプロセスが必要です。
  • セキュリティチーム (内部および顧客) が異常な動作を検出し、セキュリティインシデントを調査し、誰が、何を、どこで、いつ行ったかについての基本的な質問に回答できるようにする運用可能な監査ログが必要です。監査ログは洗練されたUIユーザーエクスペリエンスを必要としませんが、セキュリティ関連イベントへのプログラムによるアクセスを提供する必要があります。
  • 運用手順書ドキュメントが必要です。

一般提供機能

  • GAに移行する前に、セキュリティレビューが完了している必要があります。セキュリティレビューのスコープは、機能特性 (顧客向け機能、インフラストラクチャへの影響、データアクセスパターン) によって決定されます。部分的に完了したセキュリティレビューでGAに移行する機能には、Eグループの承認が必要です。
  • 脆弱性修正サービスレベル目標を遵守し、Eグループからの文書化されたリスク受容なしにS1/S2の脆弱性を伴って出荷してはなりません。インシデント対応テストを適用してください: GA後に発見された場合、緊急のパッチをトリガーするようなリスクを伴って機能を出荷してはなりません。
  • 時期尚早な公開なしにセキュアな脆弱性修正を可能にする運用可能なセキュリティリリースプロセスが必要です。
  • セキュリティチーム (内部および顧客) が異常な動作を検出し、セキュリティインシデントを調査し、誰が、何を、どこで、いつ行ったかについての基本的な質問に回答できるようにする運用可能な監査ログが必要です。監査ログは洗練されたUIユーザーエクスペリエンスを必要としませんが、セキュリティ関連イベントへのプログラムによるアクセスを提供する必要があります。

例外ガバナンス

ビジネス上の必要性によりこれらの要件から逸脱する必要がある例外的な状況では、GitLabは役員承認とリスク受容を伴う文書化された例外プロセスに従います。