웹사이트 개발을 위한 버전 관리 방법에 대해 논의해보고 싶습니다.
글쓴이: sangheon / 작성시간: 화, 2007/02/27 - 11:43오전
상황 :
울랄라 웹사이트를 유지보수하는 개발팀이 있습니다.
현재 이 개발팀에는 찌질이 차단 기능을 개발하는 3명의 개발자와 악플러 응징 기능을 개발하는 2명의 개발자가 있습니다.
찌질이 차단 기능은 이달 초에 개발을 시작하여 3개월 뒤에 완료 후 서비스에 반영 할 것이고, 악플러 응징 기능은 이달 말에 개발 시작하여 다음 달 중순에 서비스에 연영 할 것입니다.
문제는 이 두 기능이 동일한 소스 코드를 수정 할 것이고, 각 기능을 담당한 개발자들끼리도 역시 마찬가지라는 것입니다.
이런 코드 충돌 문제를 해결하기 위해 마빡이 PM은 고민 끝에 아래와 같은 버전 관리 방법을 내놓았습니다.
1. 각 그룹의 리드 프로그래머는 트렁크로부터 브랜치를 만든다.
(동일 기능을 개발하는 그룹은 같은 브랜치를 이용한다.)
2. 해당 브랜치를 체크아웃하여 자신만의 작업본을 만든다.
3. 만든 작업본으로 개발을 하면서 매일 해당 브랜치에 커밋한다.
4. 개발 중 틈틈히 해당 브랜치에 트렁크의 변경분을 머지한다.
(이 머지는 각 그룹의 리드 프로그래머가 한다.)
5. 브랜치를 외부 테스트 하여 이상이 없으면 해당 브랜치를 트렁크에 다시 머지한다.
6. 트렁크를 다시 외부 테스트하여 이상이 없으면 해당 리비전을 태그로 만든다.
7. 해당 태그를 익스포트 하여 실서버에 반영한다.
8. 실서버 반영 후 수정이 있는 경우 1번부터 다시 반복한다.
과연 마빡이 PM이 내놓은 방법에는 문제가 없을까요? 더 좋은 방법이나 아이디어가 없을까요?
Forums:
옵션을 두는 건 어떨까요?
소스가 동작하는 IP나 로그인한 사용자의 권한 등에 따라 다르게 반응하는 분기를 짜서 한 코드 베이스 안에 돌아가도록 하는 건 어떨까요? #ifdef 같은 개념으로요.
브랜치를 나누고 트렁크와 맞춰가는 식으로는 리드 프로그래머가 해야 할 일이 꽤 크고 사고의 위험도 높아 보입니다.
.
저희의 경우는
주 개발은 head (trunk)에서 하고 branch에서 유지, 보수를 합니다. 실제 서비스에 반영된 후라도 개발과 무관한 수정 사항이 계속 발생하니까요.
즉 새 기능을 개발한다고 하면
1. head에서 새 기능을 개발합니다.
2. 기존 서비스의 유지 보수는 이전 릴리즈 브랜치에서 계속 진행합니다.
3. 개발이 완료되어 릴리즈 시점이 다가왔다면 이전 릴리즈 브랜치의 변화 내용을 head에 병합합니다.
4. 새로 릴리즈 브랜치를 만듭니다. 기존 브랜치는 더이상 업데이트하지 않습니다.
5. 릴리즈 브랜치에서 자잘한 버그를 수정하며 실 서비스에 반영합니다.
6. 이후 이 브랜치에서 유지, 보수 작업을 진행합니다.
한번에 개발하는 게 하나만 있다면 이 방법이 병합시 부담이 덜한 거 같습니다.