This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
StatusAuthorsCoachDRIsOwning StageCreated
ongoing @alexpooley @ifarkas @grzesiek @m_gill @mushakov devops data_stores 2021-02-07

グループとプロジェクトの統合

グループやプロジェクト内にのみ存在する機能は数多くあります。以前は、グループ機能とプロジェクト機能の境界は明確でした。しかし、グループ機能をプロジェクトに、プロジェクト機能をグループに持ちたいという要望が高まっています。例えば、イシューはグループに、エピックはプロジェクトに、というように。

Simplify Groups & Projects Working Groupは、グループやプロジェクト間で機能を共有する上で、私たちのアーキテクチャが大きな障害になっていると判断しました。

アーキテクチャのイシュー：https://gitlab.com/gitlab-org/architecture/tasks/-/issues/7

課題

機能の重複

ある機能を別のレベルで利用できるようにする必要がある場合、私たちには確立されたプロセスがありません。その結果、同じ機能が再実装されることになります。これらの実装は、それぞれが独自に生きているため、時間の経過とともに互いに乖離していきます。このアプローチにはさらにいくつかの問題があります：

  • 機能はコンテナと結合しています。実際には、コンテナから機能を切り離すのは容易ではありません。結合の度合いは機能によって異なります。
  • 素朴に機能を重複させると、コードベースがより複雑で壊れやすくなります。
  • グループやプロジェクト間でソリューションを一般化すると、システムのパフォーマンスが低下する可能性があります。
  • 機能の範囲は多くのチームにまたがり、これらの変更は開発者の干渉を管理する必要があります。
  • グループ/プロジェクト階層は自然な機能階層を作ります。フィーチャーがコンテナにまたがって存在する場合、フィーチャー階層は曖昧になります。
  • フィーチャーが重複すると開発速度が遅くなります。

アーキテクチャを大幅に変更する可能性があります。これらの変更は、顧客体験が一貫したものになるよう、製品設計から独立したものでなければなりません。

パフォーマンス

リソースは複雑な方法でしかクエリできません。そのため、作成者やエピック、その他多くの場所でパフォーマンスのイシューが発生しました。例として、ユーザーがアクセスできるプロジェクトをクエリするには、以下のソースを考慮する必要があります：

  • 個人プロジェクト
  • グループへの直接参加
  • プロジェクトへの直接参加
  • 継承グループメンバー
  • 継承されたプロジェクトメンバーシップ
  • グループ共有
  • グループ共有による会員権の継承
  • プロジェクト共有

グループ/プロジェクトメンバーシップ、グループ/プロジェクト共有も重複する機能の例です。

目標

今のところ、この青写真はエンジニアリングの課題にのみ関係しています。

  • グループとプロジェクトのコンテナアーキテクチャを統合します。
  • コンテナから機能を切り離す一連のソリューションの開発者。
  • エンジニアリングの変更を製品の変更から切り離します。
  • 他のチームに悪影響を与えることなくアーキテクチャの変更を行うための戦略の開発者。
  • 他のレベルで利用可能な機能を求める要求に対する解決策の提供。

提案

既存のNamespace モデルを機能のコンテナとして Namespace使用します。Namespace すでに Namespace、User （個人の名前空間）、Group （のサブクラス）に関連付けられていますNamespace。 Namespace ProjectNamespacesを導入してProjects とNamespace関連付けることで、これをさらに拡張 Namespaceすることができます。各Project は、そのProjectNamespaceによって所有されるべきであり、この関係は、既存のProject <-> Group / 個人の名前空間の関係に取って代わるべきです。

また、個人名前空間に特化したモデルがなく、代わりに一般的なNamespace モデルを使用しています。これは混乱を招きますが、専用のサブクラスUserNamespace を作成することで解決できます。

その結果、Namespace の階層は次のようになります：

classDiagram Namespace <|-- UserNamespace Namespace <|-- Group Namespace <|-- ProjectNamespace

新しい機能はNamespaceに実装されるべきです。同様に、ある機能を別の階層で再実装する必要がある場合、Namespace に移動することで、実質的にすべての階層で利用できるようになります：

  • 個人用名前空間
  • グループ
  • プロジェクト

Namespaces Projects は階層のリーフノードを表しますが、ProjectNamespace の導入により、これらのトラバーサルクエリを使ってプロジェクトも取得できるようになりました。

これにより、コア機能の一部をさらに簡素化することができます：

  • ルートは、プロジェクトとグループ階層を混在させるのではなく、Namespace の階層に基づいて生成されるべきです。
  • GroupMembers とProjectMembers を区別する必要はありません。すべてのMembers は、Namespace に関連している必要があります。これにより、クエリが簡素化され、ポリシーが重複排除される可能性があります。

より多くの機能がNamespace にマイグレーションされるにつれて、Project モデルのロールは時間とともに減少し、実質的にリポジトリ関連機能のコンテナとなるでしょう。

イテレーション

Namespace を我々の機能のコンテナとして確立するために必要な作業は、Consolidate Groups and Projectsepic で追跡されています。

フェーズ 1 (完了)

  • フェーズ1のエピック。
  • ゴール
    1. すべてのプロジェクトがtype='Project' のnamespaces テーブルに対応するレコードを受け取るようにします。
    2. ユーザー・ネームスペースの場合、タイプはNULL からUser に変更されます。

プロジェクトとプロジェクト名前空間が等価であることを確認する必要があります：

  • プロジェクトを作成します：Railsコールバックを使用して、プロジェクトごとに新しいプロジェクト名前空間が作成されるようにします。プロジェクト名前空間のレコードには、プロジェクトのcreated_at/updated_at 属性と同じcreated_at /updated_at 属性を含める必要があります。
  • プロジェクトを更新します：Railsのafter_save コールバックを使用して、プロジェクトとプロジェクト名前空間の間で一部の属性が同期されるようにします。詳しくはproject#after_save をお読みください。
  • プロジェクトの削除：FKのカスケード削除またはRailsのコールバックを使用して、aProject またはitsが削除 ProjectされたProject ProjectNamespace ときに、対応する ProjectNamespaceorも Project削除されるようにします。
  • プロジェクトを別のグループに転送：プロジェクトが転送されたときに、対応するプロジェクトの名前空間が同じグループに転送されるようにします。
  • グループを転送します：グループを転送するときに、直接または子孫グループを通じて、そのグループのすべてのサブプロジェクトに対応するプロジェクト・ネームスペースが正しく転送されることを確認します。
  • プロジェクトのエクスポートまたはインポート
    • プロジェクトのエクスポートでは、このフェーズでは引き続きプロジェクトのみをエクスポートし、プロジェクト・ネームスペースはエクスポートしません。プロジェクト・ネームスペースには、この時点ではエクスポートする特定の情報は含まれていません。最終的には、プロジェクト・ネームスペースもエクスポートするようにします。
    • インポートプロジェクトは新しいプロジェクトを作成するので、プロジェクト名前空間はRailsafter_save コールバックを通じてプロジェクトモデル上に作成されます。
  • グループのエクスポートまたはインポート： Group をインポートまたはエクスポートするとき、プロジェクトはオペレーションに含まれません。グループがインポートまたはエクスポートされるときにProject が含まれるようにその機能が変更された場合、ロジックは対応するプロジェクト名前空間をインポートまたはエクスポートに含める必要があります。

これらの点を確認した後、データベースマイグレーションを実行して、Project ごとにProjectNamespace レコードを作成します。マイグレーション中に作成されるプロジェクト・ネームスペース・レコードには、created_at 属性とupdated_at 属性をマイグレーション実行時に設定する必要があります。プロジェクト・ネームスペースのcreated_at およびupdated_at 属性は、対応するプロジェクトのcreated_at およびupdated_at 属性と一致しません。作成されたプロジェクト・ネームスペースの監査が必要になった場合に備えて、異なる日付が必要です。この作業が完了したら、BackfillProjectNamespace で説明したように、すべてのプロジェクトについてデータをマイグレーションする必要があります。

フェーズ2（完了）

このフェーズでは

  • エンジニアレベルで全社的な変更を伝えます。フェーズ3までは、各チームが積極的にコラボレーションを行うことは想定されていませんが、エンジニアには今後の変更について認識してもらいたいと考えています。
  • フェーズ 3 の前に対処可能なリグレッションや、競合する作業、重複する作業を避けるために、意識を高めてください。

フェーズ3（継続中）

このフェーズでは、基本的で優先度の高いプロジェクト機能を、Project からProjectNamespace へ、または直接Namespace へマイグレーションします。このフェーズで解決すべき問題

  • メンバー/メンバーのアクションの統一- UIおよびAPIレベルで。
  • スター付け：現在、スターを付けられるのはプロジェクトだけです。これをグループレベルにも導入したいです。
  • 一般的なアクション：破壊、転送、復元。これをコントローラレベルで統一し、さらに下位に伝搬させることができます。
  • アーカイブは現在、プロジェクトレベルでしか機能しません。これは、”pending deletion “の仕組みと同様に、グループレベルで実現できます。
  • アバターのサービングとアクション。

第4段階

このフェーズでは、追加機能をProject からProjectNamespace/Namespace にマイグレーションします：

  • コード内のProject をProjectNamespace に置き換えてください。
  • ネームスペースとネームスペース機能を公開するための API の変更。
    • groups 用の API を拡張するか、namespaces エンドポイントを導入し、groups とprojects エンドポイントを徐々に非推奨とするかについて検討。
  • Project からProjectNamespace またはNamespace にマイグレーションする必要がある各機能を分解。
    • Project -> Namespace から直接、Project -> ProjectNamespace -> Namespace に機能を移行できるかどうかを調査します。 これは機能ごとにケースで決めることができます。
  • Project#namespaceをProjectNamespaceを参照するようにマイグレーション。
  • ProjectとProjectNamespaceを統合します。
  • ポリシーの統合。

フェーズ5

フェーズを進めながら、コードのクリーンアップを行うように努力すべきです。しかし、開発中にすべてをクリーンアップできるわけではありません。たとえば、データベースのカラムを削除するのは、すべてが機能していることを確認した最後のタスクとして行うことができます。このフェーズでは

  • コードのクリーンアップ
  • データベースのクリーンアップ

機能のネームスペースへのマイグレーション

最初のイテレーションでは、Namespaces. NamespacesNameSpaceの下に機能を格納するフレームワークを提供します。Namespacesステージグループは、最終的に自分たちのフィーチャーや機能を.NameSpaceにマイグレーションする必要が Namespacesあります。 これは、これらのフィーチャーに予期せぬ影響を与える可能性があります。したがって、UXの負債を最小限に抑え、製品の一貫性を維持するために、ステージグループは機能をNamespaces にマイグレーションする際にいくつかの要素を考慮する必要があります：

  1. 概念モデル：概念モデル: これらの機能の現在と将来の状態の概念モデルは何ですか(デザイナーのためのオブジェクトモデリングを参照)？これらはパジャマで文書化する必要があります（例：マージリクエスト）。
  2. マージにおける矛盾：プロジェクト、グループ、管理者レベルでどのような矛盾がありますか？どのようなアドレスが考えられますか？ラベルについてどのように合理化したかの例については、このイシューをご覧ください。
  3. 継承と情報の流れ：現在、コンテナ階層間でどのように情報が継承されていますか？新しい継承ビヘイビア・フレームワークに準拠した場合、どのような影響がありますか？
  4. 設定：この機能の設定は現在どこにありますか？これらはNamespacesによってどのような影響を受けるでしょうか？
  5. アクセス：誰がこの機能にアクセスでき、それは新しいコンテナ構造によって影響を受けますか？ロールやプライバシーへの配慮はありますか？
  6. 階層：プロジェクトやグループによって区別される階層機能はありますか？
  7. ドキュメンテーション：ドキュメンテーションの構造や内容は、これらの変更によって影響を受けますか?
  8. 解決策の提案
    • 大きく考えるこの分析は、その機能のUXを全体的に拡大して考える絶好の機会を提供します。Namespaces が提供する新しい構造、継承、機能に基づいて、この機能をどのように愛すべきものにできるでしょうか？ パジャマに準拠していないUIはないでしょうか？
    • 小さく始める：マイグレーションを支援するために必要な製品の変更は何ですか？
    • 迅速に：これらのソリューションのアイデアに優先順位をつけ、イシューを文書化し、実装のためのロードマップを作成します。