유닛과 팀

단위와 팀은 조직 내부의 중첩된 멤버십을 모델로 삼습니다.

organization
└── unit
    └── team

안정적인 부서나 작업 그룹에 자체 공유 대상이나 관리 범위가 필요할 때 사용하세요. 임시 공유를 위해서는 그룹이 더 간단한 경우가 많습니다.

저장된 역할

unit_admin 및 team_lead은 기관 API에 멤버십 관리 권한을 정의했습니다. 작성자/승인자/배포자 레이블은 의도된 워크플로 책임을 표현하지만 해당 레이블이 있다고 해서 모든 빌드 또는 배포 끝점에 의한 시행이 입증되는 것은 아닙니다. 특정 워크플로를 테스트합니다.

회원 규칙

• 단위는 하나의 조직에 속합니다.
• 팀은 하나의 단위에 속합니다.
• 사용자는 단위나 팀에 가입하기 전에 반드시 조직 구성원이어야 합니다.
• 팀원은 상위 유닛에도 속해 있어야 합니다. 관리 경로는 구성원을 추가할 때 계층 구조를 적용합니다.
• 조직 소유자/관리자 및 범위가 지정된 관리자는 역할 및 권한 범위에 설명된 대로 서로 다른 관리 권한을 갖습니다.

디자인 지침

소유권, 승인 책임 또는 고유한 리소스 공유 범위와 같은 지속 가능한 경계가 있는 경우에만 단위를 만듭니다. 해당 경계 내에 소규모 작업 그룹을 위한 팀을 만듭니다.

예:

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

승인에 영향을 주지 않는 조직도를 인코딩하지 마십시오. 추가 중첩은 오래된 멤버십과 예상치 못한 상속 공유의 가능성을 높입니다.

안전한 변경

추가, 역할 변경 또는 제거의 경우:

1. 조직, 단위, 팀, 사용자 및 현재 역할을 기록합니다.
2. 한 가지 사항을 변경합니다.
3. 허용된 작업을 테스트합니다.
4. 거부된 작업을 테스트합니다.
5. 오래된 세션 동작을 감지하기 위해 새로 고치거나 재인증합니다. 그리고
6. 대상 구성원이 변경된 주식을 검토합니다.

사용자는 여러 단위와 팀에 속할 수 있습니다. 새 멤버십을 추가해도 기존 멤버십이 이전되거나 제거되지는 않습니다.

삭제 경계

단위나 팀을 삭제하는 것은 중요한 작업입니다. “리소스는 단위 수준이 됩니다.” 또는 “할당되지 않은 리소스는 보관됩니다.”와 같은 일반적인 설명에 의존하지 마십시오. 삭제하기 전에 읽기 전용 인벤토리를 사용하여 멤버십, 공유, 종속 리소스, 활성 작업 및 외부 참조를 식별하세요. 필요한 감사 기록을 내보내고 배포된 릴리스의 정확한 계단식 동작을 확인합니다.

영향이 명확하지 않은 경우 먼저 광범위한 공유 및 구성원을 제거하고 개체를 보존하며 삭제하기 전에 소유자의 승인을 구하세요.