組織

Organizationイニシアチブは、SaaSとセルフマネージドインストール間の機能パリティを達成することに重点を置いています。

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

Organizationイニシアチブの1つの側面は、グループとプロジェクトを統合し、両者の機能格差にアドレスすることです。エピックなど一部の機能はグループレベルでしか利用できません。イシューのように、プロジェクトレベルでしか利用できない機能もあります。マイルストーンなどの他の機能は、グループとプロジェクトの両方で利用できます。

私たちは、グループレベルかプロジェクトレベルのどちらかに機能を追加したいという要望を多く受けます。異なるレベルに機能を移動させることは、複数のレベルで問題があります：

  • 機能の移動にはエンジニアリングの時間が必要です。
  • 機能の可用性に関するメンタルモデルを維持するためのUXオーバーヘッドが必要。
  • 冗長なコードを作成します。

フィーチャーがあるレベル（プロジェクト、グループ、インスタンス）から別のレベルにコピーされる場合、コピーされたフィーチャーには微妙な違いがあることがよくあります。このような微妙な違いは、修正が必要なときに、修正を複数の場所にコピーしなければならないため、余分なエンジニアリング時間を発生させます。また、このようなニュアンスの違いは、その機能が異なる場所で使用されたときに、異なるユーザーエクスペリエンスを生み出します。

この問題の解決策は、グループとプロジェクトを1つのエンティティ、namespace に統合することです。この解決策の作業はいくつかのフェーズに分かれており、エピック6473で追跡されています。

グループとプロジェクト名前空間と相互作用する機能の計画方法

現在、システム内のすべてのプロジェクトは、namespaces テーブルにレコードを持っています。このため、グループやプロジェクト間で共有される機能を作成するために、共通のインターフェイスを使用することができます。共有ビヘイビアは、懸念メカニズムを使用して追加できます。Namespace モデルがUserNamespace メソッドも担当するため、Namespace モデルをプロジェクトとグループの共有ビヘイビアに使用することは推奨されません。

リソースベースの機能

リソースベースの機能をマイグレーションするには、既存の機能をサポートする必要があります。これには2つのフェーズがあります。

フェーズ1 - セットアップ

  • ネームスペース・テーブルへのリンク
    • テーブルにカラムを追加します
    • 例えば、イシューのproject id はプロジェクトテーブルを指しています。namespaces テーブルへのリンクを確立する必要があります。
    • 新しいレコードがすでに正しいデータを持つようにコードを修正します。
    • バックフィル

フェーズ2 - 前提条件となる作業

  • 権限モデルと、それに関連するパフォーマンス上の懸念事項の調査。
    • 権限をチェックし、適切に維持する必要があります。
  • フェーズ 1 でマイグレーションする機能に依存する機能のために、ネームスペースをサポートする必要がある他のモデルを調査します。
  • フェーズ1で追加した新しいカラムを指すようにCRUDサービスとAPI（RESTとGraphQL）を調整します。
  • リソースをフェッチする際のパフォーマンスを考慮してください。

新機能の導入は、すべてのチームと機能に大きく依存します。

現在、カスケード設定はNamespaceSettings で利用可能です。ProjectNamespace を作成することで、このフレームワークを使用して、いくつかの設定がプロジェクトレベルでも適用されるようにすることができます。

設定を行う際には、以下のことを確認する必要があります：

  • join クエリで使用されないこと、またはクエリを変更しないこと。
  • 設定の更新は考慮されます。
  • プロジェクト・ネームスペースからプロジェクト・ネームスペースに移動する場合は、フェーズ 1 で説明したのと同様のデータベース・プロセスに従います。