序.
소프트웨어의 버전관리를 위한 여러 소프트웨어가 존재하고, 이들의 기능은 충분할 정도로 강력하다. 하지만 버전관리는 어떤 버전관리 시스템을 이용하느냐(What) 보다, 어떻게 사용하는가(How)가 중요한데, 실제적으로 이에 관한 논의는 부족해 보인다.
오로지 trunk에다가 commit/update를 반복하고만 있지는 않은가? 대부분의 프로젝트들이 이런식으로 진행되는 것이 현실이다.
버전관리 방안은 프로젝트 내에서 개발자 전체가 공통으로 지켜야만 의미가 있으며, 그렇지 않을 경우 되려 프로젝트에 방해가 될 수 있다. 때문에 룰이 너무 복잡하지 않은... 모두가 따를만한 실용적인 방안을 제안하고자 한다.(Subversion 기준)
1. Glossary
* SVN : 버전관리 시스템 Subversion의 약자
* revision : Subversion의 버전번호. 하나의 commit때마다 1씩 증가됨
* trunk : 관습적으로 Subversion에서 버전의 줄기 이름이자 디렉토리 이름으로 사용됨
* branch : 버전의 가지를 의미하며, 보통 주요 릴리즈마다 생성됨 각 릴리즈에서의 버그패치는 여기서 이루어짐
* tag : 의미있는 특정revision에 부여하게 되며, 보통 특정tag의 소스는 변경하지 않는 것이 원칙
* RB : Release Branch의 약자. 배포용 branch이름의 prefix로 흔히 쓰인다.
* REL : Release의 약자, 배포용 tag이름의 prefix로 흔히 쓰인다.
* BUG : 버그수정용 branch이름의 prefix로 흔히 쓰인다.
* PRE : 버그수정이전 tag의 prefix로 흔히 쓰인다.
* POST : 버그수정이후 tag의 prefix로 흔히 쓰인다.
* TRY : 실험적인 용도의 branch의 prefix로 흔히 쓰인다.
2. 방안
프레임워크에 관한 관리방안과, 서비스/어플리케이션에 대한 관리방안을 별도로 가져갈것을 제안한다.
2.1. 공통사항
* branch와 tag생성시는 모든 개발자가 commit을 완료한 후에 이루어져야 한다. 따라서 생성시에는 모든 개발자에게 통보/합의 되어야 한다.
* tag에서는 절대 변경을 가하여선 안된다.
* branch와 tag명은 명명 규칙을 반드시 지킨다.
RB, REL, BUG, PRE, POST, TRY
* RB(branch), REL(tag)는 반드시 생성시키되, 각각의 룰을 따른다. BUG/PRE/POST/TRY는 권장하지 않으며, 반드시 필요할 때만 생성한다.(숫자를 줄이기 위해서 이다)
* 개발자들의 trunk/branch/tag 작업본은 동일한 디렉토리 구조로 받도록 권장한다.
* 외부 모듈은 바이너리형태로 버전관리하는 것을 원칙으로 한다.
* Branch의 생성시에는 반드시 tag도 생성한다.
2.2. Framework
* Framework는 반드시 충분히 테스트 된 후 릴리즈 tag를 생성해야 한다.
* 중대한 변화(클래스 대량추가등), 혹은 하위호환이 깨지는 변경이 일어나기 직전에 반드시 branch를 생성한다.
* 반드시 tag버전으로 타 Application에 binary를 배포한다.
* 릴리즈 tag 생성 후, 하루 이 내에 반드시 trunk에 병합한다.
2.3. Application/Service
* 신규 서비스의 사내오픈 직전에 반드시 branch를 생성한다.
* 서비스 개편에 따른 사내오픈 직전에 반드시 branch를 생성한다.
* 상용서버에 Deploy직전에는 반드시 tag를 생성한다.(사내오픈/상용오픈 모두).
* 사내오픈 후에는 당분간 branch만 가지고 작업하고. 상용오픈의 안정성을 확인 한 후 병합한다.
3. 시나리오
* 3개월 전 REL-1.1을 배포하여 이상없이 서비스 중... 현재는 trunk에서 차기버전을 개발 중이다.
* 현재 서비스중인 서비스에 작은 기능의 추가 요구사항이 있어 RB-1.0에서 기능을 개발하여 REL-1.1.1을 배포함.
* 배포 후 1시간 만에 갑자기 서비스가 Hang되는 상황이 발생하여 긴급히 REL-1.1을 다시 배포하여 서비스 재개
* REL-1.1.1에서 치명적인 버그를 발견하여 이를 수정하고 REL-1.1.2 를 다시 배포
* 서비스 안정을 확인 후 REL-1.1과 REL-1.1.2사이의 변화내용을 trunk에 병합
終.
브랜치와 태그를 깊게 활용하되 그 룰을 최대한 간략화한 제안이다. 버전관리로 얻을수 있는 득과 실행(실천)가능성 사이의 고민의 산물이다. 절대적인 방안은 아니므로 프로젝트별로 현실에 맞게 적절히 응용해도 좋을 듯 하다.