A.J.Kuhn, Endless supply of passion!

序.
소프트웨어의 버전관리를 위한 여러 소프트웨어가 존재하고, 이들의 기능은 충분할 정도로 강력하다. 하지만 버전관리는 어떤 버전관리 시스템을 이용하느냐(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에 병합

終.
브랜치와 태그를 깊게 활용하되 그 룰을 최대한 간략화한 제안이다. 버전관리로 얻을수 있는 득과 실행(실천)가능성 사이의 고민의 산물이다. 절대적인 방안은 아니므로 프로젝트별로 현실에 맞게 적절히 응용해도 좋을 듯 하다.

서브버전을 이용한 실용적인 버전 관리 카테고리 자연과학/공학 지은이 Mike Mason (정보문화사, 2006년) 상세보기

오랜 기간 CVS를 사용해 왔고, 새로운 회사에 와선 Subversion을 사용하고 있지만, 그간 '버전관리'라는 개념조차도 정립하지 못한채 사용해 왔던 것 같다.

이러저러 개기가 되어 버전관리를 체계적으로 해보고 싶은 욕심이 생겼고, 이에 따라 이 책을 완독했다. 물론 이를 실제로 활용해 보아야 지식과 개념이 완성되겠지만, 통쾌하게 해소된 막혔던 궁금증들 때문에 지금은 자못 기대가 높다.

책을 읽은 후 느낌 감정은 후회와 자책이다. 내가 얼마간의 시간만 투자했더라면 그 간의 온갖 시행착오들은 우스운 수준에서 진정될 수 있었으리라...

엉뚱한 용도로 사용한 tag들...
엄청난 집중력을 발휘한 merge후 느꼈던 엉뚱한 자만심...(바보냐;;)
실수를 남발한 타인에 대한 비난...

버전관리 처럼 '개념'과 '도구'를 활용하여 클리어하게 해결 할 수 있는 문제가 이쪽 업계에서 또 있을까... 이 조차도 제대로 알지 못하면서 내가 가졌던 짠밥이니 뭐니 하는 Senior로써의 위세... 부끄럽다.

책은 아주 훌륭하다. 아주 실용적인 관점(제목 그대로..)에서 버전관리를 바라보고 있으며, 번역도 아주 이해하기 쉽게 되어 있다. 타성적으로 버전관리 시스템을 사용해온 엔지니어들에게 꼭 권하고 싶다.

'세상의 모든 PM들이여... trunk/branch/tag는  각 프로젝트의 특성에 맞게 적절히 활용할 수 있을만큼 완전하게 개념을 이해하도록 구성원들 모두에게 독려하라.... 아니 그러하면 프로젝트 완료 후가 재앙의 시작이 될 것이다.'
                                                                                                             - A.J.Kuhn(응?) -