• 用語解説
• 要約
• 動機
  • 目標
  • 非ゴール
• 提案
  • メリット
  • 欠点
• データ探索
• 設計と実装の詳細
  • 組織MVC
  • 組織アクセス
    • 組織ユーザー
      • ユーザーはどのように組織に参加するのですか？
      • ユーザーはいつ組織を見ることができますか？
      • ユーザーは組織で何を見ることができますか？
      • 請求可能メンバーとは何ですか？
      • ユーザーは異なる組織間でどのように切り替えられますか？
      • ユーザーが削除されるとどうなりますか？
    • 組織の非ユーザー
  • ロールと権限
    • 組織オーナーとインスタンス管理者の関係
  • ルーティング
• 組織が他のドメインに与える影響
  • 組織とフルフィルメント間の整合性
    • フルフィルメントの目標
  • 組織におけるオープンソース貢献者
• 反復計画
  • 反復1：組織プロトタイプ（FY24Q4）
  • イテレーション2：組織MVC実験（25Q1期）
  • イテレーション3：組織MVCベータ（FY25Q1）
  • イテレーション 4: 組織 MVC GA (FY25Q2)
  • MVC後の反復
• 組織ロールアウト
• 代替ソリューション
• よくある質問
  • 大規模な SaaS 顧客は、組織レベルでライセンスを取得することになりますか。たとえば、複数の最上位グループをライセンスに含めることができるようになりますか。
  • Organizations 用に GitLab の代替ドメイン名（customer.gitlab.com など）を設定できるようになる予定はありますか？
  • 組織は独自に可視性の設定（公開／非公開）をすることを期待しますか？可視性はトップレベルグループのプロパティのままですか？
• 決定ログ
• リンク集

組織

このドキュメントは進行中であり、組織設計の現状を表しています。

用語解説

• 組織：組織は、1 つまたは複数のトップレベルグループの傘です。組織はデフォルトで互いに分離されています。つまり、ネームスペースをまたがる機能は、単一の組織に存在するネームスペースに対してのみ機能します。
• トップレベルグループ：トップレベルグループは、他のすべてのグループの最上位グループに付けられる名前です。グループとプロジェクトは、トップレベルグループの下にネストされます。
• セル： セルは、複数の組織を含むインフラストラクチャ コンポーネントのセットです。セルで提供されるインフラストラクチャ コンポーネントは、Organization 間で共有されますが、他のセルとは共有されません。このようにインフラストラクチャ コンポーネントが分離されているため、セルは互いに独立しています。
• ユーザー：組織には多くのユーザーがいます。ある組織に参加すると、その組織のユーザーになります。
• メンバー：組織内のグループやプロジェクトにユーザーを追加すると、そのユーザーはメンバーになります。メンバーは常にユーザーですが、ユーザーは必ずしも組織内のグループやプロジェクトのメンバーとは限りません。例えば、ユーザーは組織への招待を受けただけで、その組織に含まれるグループやプロジェクトのメンバーではない可能性があります。
• 非ユーザー：組織の非ユーザーとは、ユーザーがその特定の組織に属していないことを意味します。

要約

組織は以下の問題を解決します：

1. トップレベルグループのグループ化を可能にします。たとえば、次のトップレベルグループは、組織GitLabに属します：
   1. https://gitlab.com/gitlab-org/
   2. https://gitlab.com/gitlab-com/
2. 異なる組織を分離できます。同じ組織のトップレベルグループは相互に作用することができますが、他の組織のグループとは作用しないため、自己管理インスタンスと同様に組織に明確な境界を提供します。ユーザーダッシュボードなどが組織にスコープされるため、分離はパフォーマンスと可用性に良い影響を与えるはずです。
3. セルとのインテグレーションが可能になります。組織を分離することで、さまざまなセルに組織を割り当ててディストリビューションできます。
4. 階層を定義する必要がなくなります。組織は、意味のある階層/エンティティセット（組織、トップレベルのグループなど）で埋めることができるコンテナです。
5. ユーザープロファイルの一元管理が可能。組織固有のユーザープロファイルを使用すると、管理者は、企業内のユーザーのロールを制御し、ユーザーの電子メールを強制したり、ユーザーが組織の一部であることを示すグラフィカルなインジケータを表示することができます。例えば、コメントに “GitLab社員 “のスタンプを追加することができます。
6. OrganizationsはSaaS（GitLab.com）にオンプレミスのような体験をもたらします。組織の管理者はインスタンスと同等の管理エリアの設定にアクセスすることができ、ほとんどの設定は組織レベルでコントロールすることができます。

動機

目標

Organizationは、OrganizationがGitLabを管理するためのより良いエクスペリエンスを生み出すことに重点を置いています。組織とセルを導入することで、SaaSプラットフォームの信頼性、パフォーマンス、可用性を向上させることができます。

• より多くの人に：インスタンスレベルの機能の多くは管理者専用です。私たちはGitLab.comのユーザーを締め出したくありません。これまではセルフマネージドユーザーのみに存在していた管理機能を、SaaSユーザーにも利用できるようにしたいのです。これは、長期的にはGitLab.comの管理者からGitLab.comのユーザーをより独立させるということでもあります。現在、GitLab.comユーザーがGitLab.comアドミニストレーターにリクエストしなければならないアクションを、セルフマネージドアドミニストレーターが実行できるようにしています。
• UXの改善：プロジェクトレベルとグループレベルで利用できる機能の間に矛盾があるため、ナビゲーションや使い勝手にイシューが生じます。さらに、組織レベルの機能には専用の場所がありません。
• 集約：組織内のすべてのグループとプロジェクトのデータを集計できます。
• 組織には、同じオーナー（個人のネームスペースを含む）の下にあるすべてのグループとプロジェクトの設定、データ、および機能が含まれます。
• カスケード動作：組織は、同じ組織が所有するすべてのプロジェクトとグループに動作をカスケードします。ある設定をその下のレベルでオーバーライドできるかどうかは、組織レベルで決定できます。
• お客様への負担を最小限に：組織の追加は、URLの変更の影響を最小限に抑えるために、既存のグループとプロジェクトのパスを変更しないでください。

非ゴール

Cellの前提条件としてOrganizationsを提供することが急務であるため、現在のところNamespaceフレームワーク上にOrganizationsの機能を構築することは目標としていません。

提案

Organizationsは、必要な機能とワークフローだけを備えた、新しい軽量エンティティとして作成します。Groups と Projects にはすでに多くの機能があり、Groups 自体が基本的にトップレベルのエンティティです。少なくともSaaS上では、トップレベルのグループがこの目的を果たし続けることができるため、一部の重要な設定以外の重要な機能をOrganizationsに追加する必要はなさそうです。インフラストラクチャの観点からは、クラスター全体で共有されるデータは最小（少量）であることと、書き込み頻度が低いことの両方が必要です。

すべてのインスタンスはデフォルトのOrganizationを設定します。

メリット

• 組織の下に移動するグループのURLに変更がないため、トップレベルのグループ間の移動が非常に簡単になります。
• 既存のトップレベルグループに対する変換プロセスがないため、リスクの少ないロールアウト戦略。
• 組織は、何が組織の一部であるかを識別するための鍵となります。

欠点

• インスタンス（または組織ではない）機能、特にレポートの大部分を構築するために労力を費やし続けないようにする方法は、今のところ不明です。トップレベルのグループにはすでにこの機能があるため、SaaSではイシューにはなりませんが、セルフマネージドでは課題となります。セルフマネージドにビルトイン組織を導入する場合（または全く導入しない場合）、インスタンス/組織レベルのレポート機能を構築し続ける必要がありそうです。
• 課金はトップレベルのグループから組織レベルに移動する必要があるかもしれません。

データ探索

最初のデータ調査から、ユーザーと組織に関する以下の情報を取得しました：

• 組織に接続されているユーザーの大部分（98％）は、1つの組織に関連付けられているだけです。つまり、ユーザーの約 2% が複数の組織にナビゲートしていると予想されます。
• 大多数のユーザー（78%）は、単一のトップレベルグループのメンバーです。
• 現在のトップレベルグループの25%は、組織に一致させることができます。
  • これらのトップレベルグループのほとんど（83%）は、複数のトップレベルグループを持つ組織に関連付けられています。
  • 複数のトップレベル・グループを持つ組織のうち、トップレベル・グループの平均数（中央値）は3。
  • トップレベルグループが2つ以上ある組織にマッチしたトップレベルグループのほとんどは、1つの組織に統合されることを想定しています（82％）。
  • 複数の最上位グループを持つ組織にマッチする最上位グループのほとんどは、単一の価格階層のみを使用しています（59%）。
• 現在のトップレベルグループのほとんどは、公開に設定されています（85%）。
• 他のトップレベルグループとグループを共有しているトップレベルグループは0.5%未満です。しかし、これは組織を導入することで、既存のトップレベルグループ間の76,000のリンクを破壊できる可能性があることを意味します。

この分析に基づき、Organizationを展開する際にも同様の挙動が見られると予想されます。

設計と実装の詳細

組織MVC

組織MVCには以下の機能がコンテナされます：

• 複数の組織を作成できるインスタンス設定。GitLab.comではデフォルトで有効になり、セルフマネジメントのGitLabでは無効になります。
• すべてのインスタンスには、Default Organizationという名前のデフォルトの組織が設定されます。初期状態では、すべてのユーザーはこのデフォルトの組織で管理されます。
• 組織のオーナー。組織を作成すると、そのユーザーが組織のオーナーに任命されます。組織のオーナーは、他の組織のオーナーを任命することができます。
• 組織ユーザー。ユーザーは1つの組織によって管理されますが、複数の組織に所属することができます。ユーザーは、所属する組織間を移動することができます。
• セットアップ設定。組織名、ID、説明、アバターのコンテナ。設定は、組織のオーナーが編集可能です。
• セットアップフロー。ユーザーは、新しい組織を構築し、既存のトップレベルグループをその組織に転送することができます。また、組織内に新しいトップレベルグループを作成することもできます。
• 可視性。最初は、組織はpublic。公開組織は、誰でも見ることができます。組織には、公開および非公開のグループとプロジェクトを含めることができます。
• 組織を削除する機能が追加された組織設定ページ。デフォルトの組織は削除できません。
• グループ。これには、グループの作成、編集、削除、および組織のオーナーとユーザーがアクセスできるグループの概要が含まれます。
• プロジェクト。プロジェクトの作成、編集、削除、および組織オーナーとユーザーがアクセスできるプロジェクトの概要が含まれます。

組織アクセス

組織ユーザー

組織ユーザーは、グループとプロジェクトにアクセスできます：

• グループメンバー：グループとそのすべてのプロジェクトにアクセスできます。
• プロジェクトメンバー: プロジェクトの可視性に関係なく、プロジェクトへのアクセスと、親グループへの限定的なアクセスを許可します。
• 非会員：組織の公開グループや内部グループ、プロジェクトにアクセスできます。組織の非公開グループやプロジェクトにアクセスするには、ユーザーはメンバーになる必要があります。

組織ユーザーは以下の方法で管理できます：

• エンタープライズユーザーとして、組織によって管理されます。これには、ユーザーアカウントの管理とユーザーをブロックする機能が含まれます。
• 非エンタープライズユーザーとして、デフォルトの組織によって管理されます。非エンタープライズユーザーは組織から削除することができますが、ユーザーはユーザーアカウントの所有権を保持します。

エンタープライズユーザーは、PremiumまたはUltimateサブスクリプションを持つ組織のみが利用できます。無料層の組織は、非エンタープライズユーザーをホストすることしかできません。

ユーザーはどのように組織に参加するのですか？

ユーザーはすべての組織に表示されます。これにより、ユーザーは組織間を移動することができます。ユーザーは以下の方法で組織に参加できます：

1. 組織に含まれるネームスペース（グループ、サブグループ、プロジェクト）のメンバーになること。ユーザーは、以下の方法でネームスペースのメンバーになることができます：

   • ユーザー名で招待されること
   • メールアドレスによる招待
   • アクセスの要求。これには組織とネームスペースの可視性が必要で、ネームスペースのオーナーが承認する必要があります。非公開グループやプロジェクトにアクセスを要求することはできません。

2. 組織のエンタープライズユーザーになること。エンタープライズユーザーを組織レベルにすることは、MVC以降に計画されています。組織 MVC では、エンタープライズユーザーはトップレベルのグループのままです。

組織の作成者は、自動的に組織のオーナーになります。例えば、公開イシューにコメントしたり作成したりするために、特定の組織のユーザーになる必要はありません。すべての既存ユーザーは、すべての公開イシューを作成し、コメントすることができます。

ユーザーはいつ組織を見ることができますか？

MVCでは、組織は公開のみ可能です。公開組織は誰でも見ることができます。公開グループと非公開グループ、プロジェクトを含むことができます。

将来的には、組織にはグループとプロジェクトの内部可視性設定が追加される予定です。これにより、内部組織には、その組織に所属するユーザーのみが表示できるようになります。これは、組織の一部であるユーザーだけが表示されることを意味します：

• 組織のURLをナビゲートすると404ではなく、組織のフロントページが表示されます。
• 組織名
• 組織概要
• アクティビティページ、グループ、プロジェクト、ユーザー概要などの組織ページ

これらのページの内容は、各ユーザーの特定のグループやプロジェクトへのアクセス権によって決まります。例えば、非公開プロジェクトはプロジェクト概要でそのプロジェクトのメンバーだけが見ることができます。

最終目標として、以下のシナリオを提供する予定です：

ユーザーは組織で何を見ることができますか？

ユーザーは、組織内でアクセス権を持つものを見ることができます。例えば、組織ユーザーは自分がメンバーである非公開グループとプロジェクトにのみアクセスできますが、公開グループとプロジェクトはすべて見ることができます。イシュー、マージリクエスト、To-Doリストなどのアクション可能なアイテムは、組織のコンテキストで表示されます。つまり、あるユーザーは、Organization A で作成したマージ リクエストが 10 件、Organization Bで作成したマージ リクエストが 7 件表示され、両方の組織で合計 17 件のマージ リクエストを作成したことになります。

請求可能メンバーとは何ですか？

請求可能メンバーの定義方法は、GitLab が提供する 2 つの主なサービスによって異なります：

• Self-managed(SM): 請求可能メンバーは、SMライセンスに対してシートを消費するユーザーです。ゲスト・ロールより上位のカスタム・ロールがシートを消費します。
• GitLab.com（SaaS）：課金対象メンバーは、ネームスペース（グループまたはプロジェクト）のメンバーで、最上位グループの SaaS サブスクリプションに対してシートを消費するユーザーです。現在、Minimal Access のユーザーとグループを持たないユーザーはライセンスされたシートにカウントされますが、これは変更されます。

これらの違いや計算方法、表示方法は、しばしば混乱を引き起こします。SM と SaaS の両方で、同じ Core ルールセットに対してユーザーがシートを消費するかどうかを評価します：

1. アクティブユーザーであること
2. ボットユーザーではありません。
3. アルティメット・ティアでは、ゲストではありません。

(1)については、アクティビティとして分類されるものと、私たちが参照する基本的なモデル（ユーザー対メンバー）の両方の観点から、提供ごとに異なる方法で決定されます。GitLab で使われている課金対象メンバーに関する様々な関連付けを示すために、以下に関係図を示します：

GroupGroupLink は、2つの Group レコード間の結合テーブルで、一方の Group が他方の Group を招待したことを示します。ProjectGroupLink は、グループとプロジェクト間の結合テーブルで、グループがプロジェクトに招待されていることを示します。

SaaSでは、ユーザーを請求可能メンバーとみなすかどうかを決定するリレーションシップ、特に混乱を招きがちなグループ/プロジェクト・メンバーシップに関連して、さらに複雑なものがあります。その例として、グループのメンバーが別のグループやプロジェクトに招待され、それによって課金対象となる場合があります。それぞれ流れが異なるため、2つのChartがあります：SaaSと SMです。

ユーザーは異なる組織間でどのように切り替えられますか？

ユーザーはコンテキスト・スイッチャーを利用できます。この機能により、異なる組織のコンテンツや設定への簡単なナビゲーションとアクセスが可能になります。コンテキスト・スイッチャーをクリックし、表示されるリストから特定の組織を選択することで、ユーザーは自分のビューと権限をシームレスに移行し、選択した組織のリソースや機能を利用することができます。

ユーザーが削除されるとどうなりますか？

ユーザーが組織から削除されるシナリオは3つあります：

1. 削除：ユーザーが organization_users テーブルから削除されます。これはユーザーが退社する場合と似ていますが、ユーザーはアクセス承認後に組織に再び参加することができます。
2. 禁止：ユーザーを追放します。これは不正行為があった場合に起こり得ますが、禁止が解除されるまでユーザーを組織に再び追加することはできません。この場合、organization_usersのエントリを残し、権限をnoneに変更します。
3. 削除：ユーザーを削除します。そのユーザーが作成したものすべてをゴーストユーザーに割り当て、organization_usersテーブルからエントリーを削除します。

組織 MVC の一部として、組織オーナーは組織ユーザーを削除することができます。これは、組織内に含まれるすべてのグループとプロジェクトから、ユーザーのメンバーシップエントリが削除されることを意味します。さらに、organization_users テーブルからユーザーエントリが削除されます。

ユーザーの禁止や削除などのアクションは、後日組織に追加されます。

組織の非ユーザー

非ユーザーは組織の外部であり、公開プロジェクトなど、組織の公開リソースにのみアクセスできます。

ロールと権限

組織はオーナーロールを持ちます。ユーザーと比較して、以下のアクションを実行できます：

(1) ユーザーは、自分がアクセス権を持つユーザーしか見ることができません。(2) ユーザーは、自分がアクセス権を持つグループとプロジェクトのユーザーしか表示できません。

グループとプロジェクトレベルのロールは現在のままです。

組織オーナーとインスタンス管理者の関係

インスタンス）管理者ロールを持つユーザーは現在、自分で管理する GitLab インスタンスを管理することができます。機能が組織レベルに移行されると、組織オーナーは現在管理者しかアクセスできないより多くの機能にアクセスできるようになります。私たちのSaaSプラットフォームでは、これは現在GitLabのチームメンバーであるインスタンス管理者に依存することなく、企業が自分たちの組織をより効率的に管理できるようにするのに役立ちます。SaaS では、インスタンス管理者と組織オーナーは異なるユーザーであることを想定しています。セルフマネージドインスタンスは一般的に単一の組織にスコープされるため、この場合、両方のロールが同じ人によって果たされる可能性があります。インスタンス管理者による介入が必要な状況もあります。たとえば、ユーザーがシステムを悪用している場合などです。このような場合、インスタンス管理者が行うアクションは、組織オーナーのアクションに優先します。例えば、インスタンス管理者は組織オーナーに代わってユーザーを禁止または削除できます。

ルーティング

現在、ユーザー、プロジェクト、ネームスペース、コンテナイメージのみが、https://gitlab.com/<path>/-/でグローバルな一意性を必要とするルーティング可能なエンティティとみなされています。当初、組織のルートはスコープされません。組織の追加は、既存のグループとプロジェクトのパスを変更しないことが設計目標の1つであるため、組織はパスhttps://gitlab.com/-/organizations/org-name/ に従います。

組織が他のドメインに与える影響

共有データベースでは、書き込み頻度の低いテーブルを最小限にしたいものです。もし共有データベースへの書き込み量が多かったりデータ量が多かったりすると、それがスケーリングにおける一つのボトルネックとなり、Cells の水平スケーラビリティの目的を失うことになります。分離はCellsを機能させるための主な要件の1つであるため、既存の機能はOrganization間で機能するのではなく、ほとんどがOrganizationにスコープされることを意味します。例外はユーザーで、これはクラスター全体の共有データベースに保存されます。一部の機能への影響については、Cells によって影響を受ける機能のリストを参照してください。

組織とフルフィルメント間の整合性

フルフィルメント社は、トップレベルのグループより上位の組織を支持しています。彼らの見解はイシュー#1138に概説されています。

フルフィルメントの目標

• フルフィルメントには、課金をトップレベルのグループからその上のレベルに移すという長年の計画があります。これは、1 つのライセンスが組織とそのすべてのトップレベル グループに適用されることを意味します。
• フルフィルメントは課金に Zuora を使用しており、組織と BillingAccount と呼ばれる Zuora エンティティの間に 1 対 1 の関係を持ちたいと考えています。彼らは、ライセンスを単一のトップレベルグループに結びつけることから脱却したいと考えています。
• 顧客が複数の組織を必要とする場合、それぞれ別の BillingAccount を持つ必要があります。
• 理想的には、セルフマネージドインスタンスにはデフォルトで1つのOrganizationがあり、ほとんどの顧客にはこれで十分です。
• フルフィルメントでは、追加エンティティは1つだけです。

組織におけるオープンソース貢献者

現在のオープンソースのワークフローのいくつかの側面は、Organizationsの導入によって影響を受けるでしょう。私たちは、イシュー420804で、この具体的な問題に関してより深い調査を行っています。

反復計画

以下の反復計画は、私たちがどのように組織MVCに到達するつもりかを概説しています。私たちは、実験、ベータ、および一般に利用可能な機能のガイドラインに従っています。

反復1：組織プロトタイプ（FY24Q4）

イテレーション1では、トップレベルのグループをグループ化する方法として、組織の概念を導入しました。OrganizationのサポートにCellsの作業は必要ありませんが、Organizationがあることでその後のCellsのイテレーションがよりシンプルになります。イテレーション1のゴールは、GitLabチームがOrganizationの基本的な機能をテストするためのプロトタイプを作成することです。プロトタイプには以下の機能が含まれます：

• 新しいOrganizationを作成することができます。
• 組織には名前、ID、説明、アバターが含まれます。
• 組織の作成者は組織のオーナーとして割り当てられます。
• グループは組織内に作成できます。グループはグループの概要に表示されます。すべての組織ユーザーは、グループの概要にアクセスし、自分がアクセスできるグループを確認できます。
• プロジェクトはグループで作成できます。プロジェクトはプロジェクトの一覧に表示されます。すべての組織ユーザーは、プロジェクトの概要にアクセスし、自分がアクセスできるプロジェクトを確認できます。
• エンタープライズユーザーも非エンタープライズユーザーも組織に属することができます。
• エンタープライズユーザーはトップレベルのグループによって管理されます。
• ユーザーは複数の組織に属することができます。
• ユーザーは、所属する組織間を移動することができます。
• 組織の内外を問わず、ユーザーは組織に含まれるグループやプロジェクトに招待することができます。

イテレーション2：組織MVC実験（25Q1期）

イテレーション2では、組織MVC実験をリリースします。一部のお客様を対象に機能テストを実施し、その結果に基づいてMVCを改善します。MVC実験には以下の機能が含まれます：

• ユーザーはユーザー一覧に表示されます。すべての組織ユーザーは、ユーザー概要にアクセスし、自分がアクセス権を持つグループやプロジェクトに所属するユーザーを確認することができます。
• 組織は削除できます。
• 組織のオーナーは、組織のアクティビティページにアクセスできます。
• 組織間の分岐が定義されます。

イテレーション3：組織MVCベータ（FY25Q1）

反復3では、組織MVCベータがリリースされます。ユーザーは既存のトップレベルグループを組織に移行できるようになります。

• 複数の組織オーナーを割り当てることができます。
• 組織アバターは組織設定で変更できます。
• 組織のオーナーは、グループの概要からグループの作成、編集、削除ができます。
• 組織のオーナーは、プロジェクトの概要からプロジェクトを作成、編集、削除できます。
• トップレベルのグループを組織に移動することができます。
• 組織のURLパスを変更できます。

イテレーション 4: 組織 MVC GA (FY25Q2)

反復4では、組織MVCが展開されます。

MVC後の反復

Organizationsの初期展開の後、GitLabの実装に関するお客様のニーズにアドレスするために、以下の機能が追加されます：

1. 組織はユーザーを招待することができます。
2. 内部可視性は、GitLab.comの一部である組織で利用可能になります。
3. 組織外のユーザーを招待することを制限します。
4. エンタープライズユーザーは組織レベルで利用可能になります。
5. 組織はユーザーを禁止したり削除したりすることができます。
6. プロジェクトは組織レベルのプロジェクト概要から作成できます。
7. グループは、組織レベルのグループの概要から作成できます。
8. トップレベルのグループから組織に請求書を移動します。
9. 組織レベルでのイベント監査。
10. 組織レベルでマージリクエストの承認者ルールを設定し、すべてのグループとプロジェクトにカスケードします。
11. 組織レベルでのセキュリティポリシー。
12. 組織レベルでの脆弱性レポーターと依存関係リスト。
13. セキュリティスキャンを実施するためのカスケード組織設定。
14. 組織レベルでのスキャン結果ポリシー
15. コンプライアンスのフレームワーク
16. 組織レベルでのKubernetes共有のためのエージェントのサポート。

組織ロールアウト

組織のロールアウトを成功させるために、以下のステップを提案します：

• フェーズ1：ロールアウト
  • 組織は、default OrganizationGitLab.com の既存のトップレベルグループはすべてこの .Organizationsの一部 default Organizationです。組織 UI には機能フラグがあり、最初は特定のユーザーに対して、そしてこのフェーズの終わりにはグローバルなユーザープールに対して有効にすることができます。こうすることで、ユーザーは既に組織と組織UIの概念に慣れることができます。default Organization を有効にしても、どの機能も影響を受けません。 詳細はイシュー#418225を参照してください。
• フェーズ 2: マイグレーション
  • 組織であるGitLabは、最初に別のOrganizationに移行します。GitLabに所属するすべてのトップレベルグループ（gitLab-org とgitLab-com トップレベルグループも含む）を新しいGitLab Organizationに移行します。詳しくはイシュー#418228をご覧ください。
  • 既存のお客様は、独自の組織を作成することができます。組織の作成は引き続き任意です。
• フェーズ 3: オンボーディングの変更
  • 新規のお客様は、組織を作成することによってのみ旅を開始することができます。
• フェーズ4：ターゲットを絞った取り組み
  • バナーメッセージやCSMを通じた大口顧客との会話などを通じて、組織を昇格させます。別組織の設立は、引き続き自主的なアクションとなります。
  • 例えば、課金を組織レベルに移行することで、組織の価値提案を高め、より多くの顧客が独立組織に移行するインセンティブを提供します。採用はモニターされます。

Cellsで目指している負荷ディストリビューションが達成できなかった場合のみ、強制的な選択が検討されます。

代替ソリューション

組織の構築に代わるアプローチとして、トップレベルのグループを組織に変換する方法があります。このアプローチの主な利点は、Namespaceフレームワークの上に機能を構築し、グループレベルですでに利用可能な機能を活用できることです。同じ機能を何度も構築する必要がなくなります。しかし、Organizations は Cells の重要なドライバーとして認識されています。Cellsを提供することが緊急であるため、私たちはOrganizationを提供するための最も迅速で簡単な解決策を選ぶことにしました。つのOrganization案の比較の詳細はこちらをご覧ください。

よくある質問

大規模な SaaS 顧客は、組織レベルでライセンスを取得することになりますか。たとえば、複数の最上位グループをライセンスに含めることができるようになりますか。

はい、これはフルフィルメントと協議しており、組織向けのポストMVCロードマップの一部です。組織とフルフィルメント間の調整も参照してください。

Organizations 用に GitLab の代替ドメイン名（customer.gitlab.com など）を設定できるようになる予定はありますか？

現時点では、GitLabドメイン名の設定を可能にする予定はありません。以前、サブドメインは管理上の課題をもたらすと聞いたことがあります。現時点ではGitLab Dedicatedの方がはるかに適しているでしょう。

組織は独自に可視性の設定（公開／非公開）をすることを期待しますか？可視性はトップレベルグループのプロパティのままですか？

組織は今のところ公開されていますが、将来的には独立した可視性設定を持つことになるでしょう。ユーザーはいつ組織を見ることができますか？

決定ログ

• 2023-05-10:請求書は組織MVCの一部ではありません
• 2023-05-15:組織ルートのセットアップ

リンク集

• 組織エピック
• 組織MVCデザイン
• ユーザー
• セルの設計図
• セルのエピック
• 名前空間