Controlling access to source control in Rational Team Control
유형별 장단점 위주로 간추린 내용입니다.
읽기 제한 시나리오:
- 프로젝트 영역 모든 부분에 대한 읽기 제한
프로젝트가 최고 기말사항 사항으로 선택된 사용자들만이 존재여부를 알고 있습니다.
시나리오 : Bill, Jason, Markus는 새로운 가히 혁명적인 JUnit 프로젝트를 추진하기로 결정합니다. 하지만 아직 대중의 비판을 받기에는 아직 준비되어 있지 않습니다. 그래서 자신들만이 해당 프로젝트의 프로세스, 빌드, 작업 항목 및 소스 제어를 관리할 수 있도록 합니다. 이를 위해 프로젝트 영역에서 읽기 엑세스를 빼기로 합니다.
장점 :
* 간단한 솔루션임.
* 프로젝트 영역의 멤버가 아닐 경우 해당 프로젝트 영역 내의 모든 것들을 볼 수가 없음.
단점 :
* 큰 규모의 팀인 경우에는 소스에 대한 읽기 제한을 너무 단순화 시키게 됨.
프로젝트 영역의 엑세스 제어를 멤버로 한정해서 설정 - 소스 제어는 읽기 제한, 작업 항목은 공개
프로젝트의 구현 사항은 기밀 사항이며, 스펙이나 기능은 공개되어 주석을 허용합니다.
시나리오 : JUnit 팀이 제품을 공개했습니다! 오픈 소스 프로젝트가 아닌 까닭에 소스는 공개하지 않을 작정입니다. 다만, 많은 고객들이 제품 개발에 관심이 많습니다. JUnit 팀은 최종 바이너리 제품만 고객에게 제공합니다만 고객의 피드백은 소중합니다. 보다 나은 제품 개발을 위해서, 고객에게 RTC에 대한 계정을 제공하고, 개발자에게 직접 버그나 기능 개선을 요청하도록 합니다.
장점 :
* 소스는 비공개로 관리하지만, 버그 추적 기능은 최종 사용자 등 보다 큰 커뮤니티에 공개함.
단점 :
* 큰 규모의 팀인 경우에는 소스에 대한 읽기 제한을 너무 단순화 시키게 됨.
Freddy는 작업 항목 처리용 Public JUnit만 엑세스, Markus는 소스 제어용 JUnit Project에 대한 엑세스 제공
소스 제어용 프로젝트 영역에서 작업 항목 권한 불능화 - 몇몇 콤포넌트는 읽기 제한, 나머지는 공개
프로젝트 일부분은 기밀사항이며, 나머지는 공개로 계약자, 인턴, 커뮤니티와 함께 작업합니다.
시나리오 : JUnit 팀은 Freddy의 열정에 탄복해서, 직접 수정할 수 있도록 허락합니다. Freddy는 외부 개발자인 까닭에 모든 소스를 공개하진 않고, JUnit Examples 프로젝트에 대해 작업을 할 수 있도록 하고, 나머지는 기밀에 부칩니다.
장점 :
* 사용자 마다 읽기 엑세스 범위를 달리함.
* 모든 사용자가 비록 읽기 엑세스 범위는 서로 달라도 똑같은 스트림으로 여전히 전달함.
단점 :
* 프로젝트 영역마다 읽기 엑세스 범위를 설정해야 함. 예:
* Freddy는 콤포넌트 A와 B를 볼 수 있음
* Jennifer는 콤포넌트 A와 B 그리고 C를 볼 수 있음
* Marlene는 콤포넌트 C와 D를 볼 수 있음
* Rick은 콤포넌트 C만 볼 수 있음
* 콤포넌트 A와 B, C, D를 소유하기 위한 3 프로젝트 영역이 필요함.
JUnit 콤포넌트는 JUnit 팀만 엑세스 부여, JUnit Examples 콤포넌트는 공개(Public JUnit팀 소유)
JUnit 스트림은 Freddy가 볼 수 있도록 Public JUnit 팀으로 소유권 제공
- 비공개 저장소 작업공간 상의 작업
혼자서 서프라이즈 작업을 합니다.
시나리오 : Markus는 기밀 프로젝트를 관리할 프로젝트 영역을 생성할 권한이 없습니다. 프로토타입은 며칠밖에 걸리지 않을 걸로 예상되며, 프로토타입이 제대로 작동하지 못할 경우도 대비해서 어드민에게 새로운 프로젝트 영역을 생성해 달라는 수고를 끼치고 싶지 않습니다. 괜히 프로젝트영역을 만들었다 잘못 됐다면 아카이브를 해야 할 수 있습니다. 프로토타입이 성공한다면 해당 프로젝트를 공개 스트림을 통해 공유할 수 있습니다.
장점 :
* 프로젝트 영역을 생성할 필요가 없거나 프로젝트 영역간에 스트림을 옮길 필요가 없음.
단점 :
* 다른 팀 멤버들은 해당 저장소 작업공간으로 전달할 수 없음.
프로토타입 완료 후 비공개에서 공개로 저장소 작업공간에 대한 읽기 엑세스 변경
쓰기 제한 시나리오:
- 스트림으로의 전달에 대한 권한 제한
통합 스트림에 대한 소유권을 로컬 팀에서 갖고 있고, 원격 팀의 전달 사항에는 승인이 필요합니다. 또는 스트림은 릴리즈를 위해 안정화되어 있고, 승인된 변경 사항만을 허용합니다.
시나리오 : JUnit 팀은 이제 원격 팀이 그들이 소유하고 있는 스트림으로 전달할 수 있는 데까지 확장되었습니다. 하지만 원격 팀은 JUnit 스트림으로 바로 전달할 수는 없습니다. 통합 스트림이 구성되었습니다. 통합 스트림으로 전달할 수 있는 통합자 역할을 선택된 사용자들에게만 부여합니다.
장점 :
* 개개 사용자에 대한 역할 변경의 유연성.
* 역할에 대한 권한 변경의 편리함, 해당 역할의 사용자에게 영향을 끼침.
단점 :
* 프로젝트 영역과 역할의 숫자가 늘어나면, 팀 관리 관련 복잡도가 증가함. - 읽기 전용 프로젝트 영역으로 스트림을 이동
심각한 버그 수정을 위해 갑작스레 스트림을 잠급니다. 모든 개발자들에 대한 적절한 권한 설정 및 통지 등을 하기엔 시간이 촉박합니다.
시나리오 : 해당 프로젝트 영역에 있어서 스트림으로 전달할 수 있는 권한을 제어하는 대신에 스트림이 속한 프로젝트 영역 변경을 통해 전달 권한을 다르게 가져갑니다.
JUnit 프로젝트의 품질이 최악입니다. 개발은 점점 미궁속으로 빠져들고 있습니다. Bill은 '빨간' 빌드를 수정할 필요가 있습니다만 아무도 전달하지 말라는 소리에 소리에 기울이지 않습니다. 그래서 먼저 전달 권한을 모두 거두고 빌드에 대한 모든 수정을 검토할려고 합니다. 빌드가 수정되면, 전달 권한을 다시 되돌릴 예정입니다.
장점 :
* 프로젝트 영역간 스트림 이동이 편리함 (역할에 대한 권한을 변경하고 되돌리는 것에 비해).
단점 :
* 프로젝트 영역을 특정 역할의 사용자 그룹을 위한 템플리트로 사용함. 내내 사용하지 않을 수도 있음.
* 전달시 갑자기 권한이 없다고 하면 사용자가 놀랄 수 있음. - 콤포넌트로의 전달에 대한 권한 제어
서로 다른 하위 팀들이 각각 서로 다른 콤포넌트를 소유하고 있습니다. 통합 스트림으로 전달시 각 팀에서 책임진 콤포넌트로만 전달하도록 합니다.
시나리오 : JUnit 팀 멤버들이 각각의 콤포넌트에 특화되기 시작합니다. 각각의 콤포넌트 소유자는 통합 스트림으로 푸시할 것을 결정합니다. Bill은 Product Owner이기 때문에 모든 스트림 간의 통합 관리를 지원하는 릴리즈 엔지니어로 지명됩니다. 그리고 고객 관리 서브 팀이 생기고 모든 소스에 대한 읽기 액세스를 갖게 됩니다. 고객 관리 팀은 팀내 스트림에 대해서는 자유롭지만 갱신된 example에 대해서만 통합할 수 있도록 부여받습니다.
장점 :
* 누가 콤포넌트로 전달할 수 있는 세세한 제어를 함. 다른 팀의 역할에 대한 엑세스를 부여함.
* 전달에 대한 엑세스 거부시 어드바이지 경고 메세지를 수정할 수 있음.
단점 :
* 역할을 같은 프로젝트 영역에서 작성해야 함. 하지만 다른 팀 영역에서 작성될 여지가 있음.
콤포넌트 전달 제한 설정 대화 상자 (팀 영역과 해당 역할 조합)
- 스냅샷 저장 후 스트림 삭제
더 이상 지원하지 않는 릴리즈용 스트림입니다. 더 이상의 코드가 전달되지 못하도록 합니다.
시나리오 : JUnit 팀이 수년 째 작업해 온 JUnit 코드에서 손을 떼기로 결정합니다. 누가 무엇을 원하든, 업데이트나 백포팅을 지원하지 않을 예정입니다. 사용자들은 이미 새롭고 개선된 JUnit 2.0 코드로 마이그레이션을 했습니다. 원래의 JUnit 스트림을 그냥 두면 과거 잘못내렸던 설계관련 내용이 괜히 눈만 아프게 합니다.
장점 :
* 스트림을 삭제해서 UI를 깔끔하게 함.
단점 :
* 현 개발 과정에 가히 지장을 줄수도 있음. 모두들 스트림이 제거된다는 사실을 알아야 함(자동화된 빌드 스케줄 포함해서).
새로운 스냅샷 작성 대화상자
- 스트림 상의 개별 파일 잠금
병합하기 어려운 바이너리 파일 작업 중입니다. 스트림 상에서 작업 중인 파일을 잠궈서 작업 중에 다른 사람들이 기다리도록 합니다. 또는 아키텍처 결정과 관련된 코드 (에를 들어 플러그인 종속성을 제어하는 MANIFEST.MF 파일 잠금)를 효과적으로 잠급니다.
시나리오 : Markus와 Jason은 제품에 사용된 아이콘이 맘에 들지 않습니다. 비공식적으론 모든 아이콘을 바꾸는 작업을 나누기로 합니다만 누가 어떤 파일을 수정할 지 명시하지 않습니다. 이미지를 병합할 도구가 없거니와 두가지 아이콘을 합치는 작업도 분명히 얼토당토 않습니다. 그리고 불시에 같은 파일을 수정하는 노고를 원치도 않습니다. 때문에 한번에 한명씩 수정하도록 하기위해서, 작업을 시작할 땐 해당 파일을 잠그고 작업을 마치면 파일 잠금을 풀기로 합니다.
장점 :
* 스트림에서 개개 파일을 잠글 수 있음.
단점 :
* 파일이 잠기었다는 것을 명시적으로 검색을 하거나 또는 수정을 이미 한 뒤에 알게 됨.
* 가능하더라도, 스트림 상의 모든 파일을 잠그는 것은 적절하지 않음.
Markus가 잠근 '붉은 아이콘'의 파일
댓글 없음:
댓글 쓰기