ユニットとチーム

ユニットとチームは、組織内のネストされたメンバーシップをモデル化します。


organization
└── unit
    └── team

安定した部門または作業グループが独自の共有ターゲットまたは管理スコープを必要とする場合にこれらを使用します。多くの場合、グループはアドホック共有にとってより簡単です。

保存されたロール

範囲	役割
単位	`unit_admin`、`base_creator`、`base_approver`、`member`
チーム	`team_lead`、`variant_creator`、`variant_deployer`、`variant_user`

unit_admin および team_lead は、組織 API でメンバーシップ管理権限を定義しました。作成者/承認者/デプロイ者のラベルは、ワークフローの意図された責任を表しますが、それらのラベルの存在は、すべてのビルドまたはデプロイメントのエンドポイントによる適用を証明するものではありません。特定のワークフローをテストします。

会員規約

ユニットは 1 つの組織に所属します。
チームは 1 つのユニットに所属します。
ユーザーは、ユニットまたはチームに参加する前に、組織のメンバーである必要があります。
チームメンバーは親ユニットにもいる必要があります。管理ルートは、メンバーを追加するときに階層を適用します。
組織の所有者/管理者と対象範囲の管理者は、役割と権限の範囲で説明されているように、異なる管理権限を持ちます。

設計ガイダンス

所有権、承認責任、または明確なリソース共有範囲などの永続的な境界がある場合にのみ、ユニットを作成します。その境界内に小さな作業グループのチームを作成します。

例:


Acme
├── Platform unit
│   ├── Image engineering team
│   └── Security review team
└── Product unit
    └── Device application team

権限に影響を与えない組織図をエンコードしないでください。余分なネストにより、メンバーシップが古くなり、予期しない共有が継承される可能性が高くなります。

安全な変更

追加、役割の変更、または削除の場合:

組織、ユニット、チーム、ユーザー、および現在の役割を記録します。
1 つ変更を加えます。
許可された操作をテストします。
拒否された操作をテストします。
更新または再認証して、古いセッションの動作を検出します。そして
ターゲットメンバーシップが変更された株式を確認します。

ユーザーは複数のユニットやチームに所属できます。新しいメンバーシップを追加しても、古いメンバーシップは移行または削除されません。

削除境界

ユニットまたはチームの削除は重要な操作です。「リソースがユニットレベルになる」または「未割り当てのリソースがアーカイブされる」などの一般的な記述に依存しないでください。削除する前に、読み取り専用インベントリを使用して、メンバーシップ、共有、依存リソース、アクティブな作業、および外部参照を特定します。必要な監査レコードをエクスポートし、デプロイされたリリースの正確なカスケード動作を確認します。

影響が明らかでない場合は、まず広範囲の共有とメンバーを削除し、オブジェクトを保存し、削除する前に所有者の承認を求めます。