소스 제어 : 역할 및 책임-모범 사례

역할과 책임, 특히 개발 지점에서 트렁크 (또는 주요) 로의 병합을 담당하는 사람과 관련된 "모범 사례"를 찾고 있습니다. 기본적으로 나는 내 대의를 돕기 위해 탄약을 찾고 있습니다.

내가 직면하고있는 것을 설명하겠습니다. 특정 응용 프로그램의 수석 개발자 (소유자)입니다. 우리 회사는 최근 VSS (내 응용 프로그램이 저장된 VSS 데이터베이스의 관리자 인)에서 TFS ( "운영"팀이 만든 개발 지점에 대한 권한 만 있음)로 옮겼습니다. 이전 작업에서 저는 TFS 관리자 였으므로 TFS와 MSBuild에 대한 길을 알고 있습니다.

사용되는 분기 및 병합 전략에 문제가 없습니다 (필요에 따라 생성 된 버그 / 프로젝트 개발 분기가있는 메인 분기, 메인으로 병합 된 다음 릴리스 분기로 승격 됨). 내가 가진 문제는 다음과 같습니다.

1. 나만의 브랜치를 만들 수 없습니다. "작업"팀 구성원이 나를 위해 지점을 만들도록하려면 TFS 작업을 만들어야합니다.

2. Main에서 개발 지점으로 병합 할 수 없습니다. "작업"팀 구성원이 병합을 수행하도록 TFS 태스크를 작성해야합니다. 그런 다음 "ops guy"가 개발자 일 수도 있고 아닐 수도 있기 때문에 팀 변경 사항을 "스텝"하지 않기를 바랍니다. 그가 병합하고있는 코드에 대해 거의 또는 전혀 모른다.

3. 개발에서 메인으로 병합 할 수 없습니다. 다시 한 번 "ops guy"가 병합을 수행하도록 TFS 태스크를 작성해야합니다. 그런 다음 개발자가 아닌 사람을 Main에 병합하여 발생한 문제를 해결할 수 있도록 지점으로 다시 병합 할 다른 TFS 작업을 만들어야합니다.

4. MSBuild 스크립트를 만들거나 편집 할 수 없습니다. 다시 한 번 MSBuild에 새로운 "ops"팀과 함께 작업해야하므로 가장 기본적인 빌드 작업 만 수행 할 수 있습니다. (복잡한 일을 잊어 버리거나 천국에서 맞춤 작업을 금지)

5. MSBuild 스크립트를 실행할 수 없습니다. 다시 한 번 "ops"팀만이이 작업을 수행 할 수 있습니다.

6. 이 모든 것을 끝내려면 일반적으로 요청 된 작업을 수행하는 "해상"리소스이므로 이른 아침에 작업을 (분기 / 병합 / 빌드) 생성하더라도 완료되지 않을 수 있습니다. 그날 저녁까지

이제 릴리스 브랜치를 유지 관리하는 "운영"팀에 문제가 없습니다. 그들이하고있는 모든 것은 (기본적으로) Main에서 최신 버전을 가져 와서 릴리스 지점으로 승격시키는 것입니다. "Main"이 안정적이고 준비가되어 있으면 릴리스 브랜치가 양호합니다.

제 의견은 기술 리드 (예 : I)가 트렁크 ( "메인")를 유지하고 개발 지점과의 병합을 책임 져야한다는 것입니다. 팀장은 또한 MS 빌드 스크립트를 생성하여 통합 테스트 환경에 구축하고 배포 할 수 있어야합니다.

누구든지 내 사례를 증명하는 데 도움이되는 모범 사례 문서로 안내 할 수 있습니까? 내 모든 검색은 분기 및 병합 기술과 관련된 모범 사례 만 나타 났으며 WHO에 대한 언급은 분기 / 병합을 수행하지 않아야합니다.

모범 사례에 대한 나의 일반적인 취지는 개발 팀 구성원이 프로덕션 배포를 시작하는 것과 같은 일을하지 않는다고 가정하면 트리에서 모든 작업을 수행 할 수 있어야한다는 것입니다. 특정 지점 / 태그 / 리포지토리가 자동 배포의 소스 역할을하는 경우 합리적인 변경 제어 또는 진입 장벽이 합리적 일 수 있습니다. 개발자가 브랜치를 만들고 빌드 스크립트를 개선하도록 권장합니다. 필요한 경우 개발자가 프로덕션에 액세스 할 수있는 방법을 찾을 것입니다. 소스 제어의 요점 중 하나는 실수를 효과적으로 마술로 지우는 것입니다. 최악의 상황은 rev 또는 2를 롤백하고 분기하는 것입니다.

불행히도 이것은 그들이 여기에서 취한 접근법처럼 들리지 않습니다. 이것을 물 리치려면 몇 가지 각도를 다루어야한다고 생각합니다.

a) 이러한 정책이 개발에 해롭다는 것을 증명하십시오. 당신이 무언가를 위해 일하기 위해 작전을 기다리는 데 소비하는 모든 시간을 기록하십시오. 이것이 혼자서 이것이 왜 나쁜 정책인지에 대한 합리적인 관리를 판매해야합니다.

b) Ops에서 친구를 사귀십시오. 아마도이 정책에 대한 이유가있을 수 있습니다. 아마도 그 추론은보다 효과적인 방식으로 해결 될 수있을 것입니다.

도움이 되었기를 바랍니다.

내가 본 관행은 다음과 같습니다.

1. 누구나 마음의 내용에 따라 작업 분기를 만들 수 있습니다. 개발자는 현재 진행중인 작업을 저장하는 데 문제가 있다고 판단되는 순간에 기능 분기를 작성할 수 있어야합니다. 그들은 하루가 끝날 때 백업하고 싶기 때문에 다른 팀원과 공유하고 싶거나 주 또는 기타의 변화로부터 보호되어야합니다.

2. 누구나 개발 지사에 절대적으로 아무것도 할 수 없습니다. 개발자는 메인에 통합 된 다른 무언가를 알려주는 순간부터 메인에서 병합 할 수 있어야합니다.

3. 메인으로 통합 (통합)에는 세 가지 옵션이 있습니다.

   • 개발자는 스스로이 일을합니다. 그들은 단지 수석 개발자와 위험을 논의하고 기능을 적절히 테스트합니다. 이는 누구나 권한이 있음을 의미합니다. 누군가 규칙을 어기면 꾸짖고 틀린 변화를 되돌립니다.
   • 다른 개발자는 변경 사항을 검토 한 후 수행합니다. 여전히 모든 사람에게 권한이 필요합니다. 규칙은 여전히 ​​수석 개발자가 시행합니다.
   • 메인을 검토하고 병합하는 지정된 통합자가 있습니다. 그러나 통합자는 팀의 일부이므로 코드를 이해해야합니다. 소규모 팀에서는 건축가와 같은 사람이되고, 큰 팀에서는 별개이지만 밀접하게 협력해야합니다.

4. 기능을 준비하는 사람은 빌드 스크립트를 수정해야합니다. 그러나 TFS와 어떻게 작동하는지 잘 모르겠습니다. 필자가 사용한 시스템에서 빌드 스크립트는 항상 버전이 지정된 파일이므로 개발자는 다른 것과 마찬가지로 파일을 편집하고 다른 모든 것과 함께 통합했습니다.

5. 지정된 적분기가있는 경우 대개 정의 (실행할 스크립트)를 정의하고 빌드를 시작합니다. 그렇지 않으면 팀 리더가 지정하거나 지정된 팀 구성원이 권한을 부여하거나 누구나 권한을 가지며 팀 리더가 사례별로 특정 빌드를 설정하고 시작합니다.

6. 어떠한 경우에도 위의 작업에는 팀 외부의 운영자가 필요하지 않습니다. 운영자는 권한 설정, 복제본 작성 등에 만 필요합니다.

"모범 사례"(나와 함께)를 염두에 두지 마십시오. 이것은 관리 문제입니다. 기본적으로 제약 조건으로 인해 제대로 작업을 수행 할 수 없습니다.

실제로 "모범 사례"가 무엇인지는 중요하지 않습니다. 이것은 간단하고 입증 가능한 문제로, 귀하와 팀의 생산성에 영향을 미치므로 해당 라인 관리에 따라야합니다.

그게 가장 좋은 방법은 문서의 힘을 휘두르는 참조 (만 수 수도 ) 수 원조를 설득하려고이 아니라 훨씬 더 다른 시간대에 누군가를 기다리는 동안 dev에 팀 구성원이 자신의 손에 앉아 있어야 할 것이라는 개념이다 프로세스가 개선 / 합리화되지 않는 한 함께 행동을 취합니다.

그리고 너무 대립하지 마십시오. 제한이있는 이유, 정당성이 무엇인지 알고 싶은 것만 큼 ...