우리의 레서피는 이제 아주 좋아졌습니다.
체인지셋 번호를 한번 유심히 살펴봅시다.
처음에 있는 숫자 13은 짧고 보기 편합니다. 하지만 한가지 문제가 있는데 그건 안정적이지 않다는 겁니다.
팀의 여러 사람이 개별적으로 작업을 하고 그 작업들을 병합할 때 이 짧은 체인지셋 번호는 서로 맞지 않습니다.
그래서 저는 팀원들에게 "그래 체인지셋 13번을 릴리즈하도록 하자"라고 얘기할 수가 없습니다. 왜냐하면 이 13이라는 번호가 가리키는 문서는 각자마다 다르기 때문입니다. 그래서 이 복잡한 16진 번호가 있는겁니다.
이 16진 번호는 모든 레포지토리에서 유일성이 보장되며 절대 바뀌지 않습니다.
자~ 그래서 이제 저는 팀원들에게 말합니다. "어이~ 우리 오늘 릴리즈할 거야. 체인지셋 번호 1b03ab783b17 번으로..." 좀 쉬운 이름을 부여할 수 있으면 좋겠다는 생각이 들지 않나요?
그렇게 할 수 있으며 그건 태그(tag)라고 합니다.
이제 로그를 살펴보면...
태깅한다는 것은 자동으로 커민하고 새로운 체인지셋을 만든다는 걸 유의하십시요. 이렇게 태그를 달아두면 우리가 릴리즈한 코드에 대해 Version-1.0이라고 부를 수 있습니다. 1b3ab783b17 대신에요.
우리는 이제 구아카몰 2.0에 대한 작업을 할 준비가 되었습니다.
수정이 되었으면 커밋합니다.
이렇게 갓 만들어진 구아카몰 2.0은 아직 안정된 상태가 아닙니다. 아직 제대로 테스트되지 않았습니다. 그런데 고객이 불만을 합니다. "너무 짜요~" 구아카몰 2.0을 안정화하고 짠 문제를 해결하기 위해서는 시간이 너무 많이 걸립니다.
다행히 우리는 태그를 붙여 놓았습니다. hg update 커맨드를 통해 레포지토리에 있는 어떤 버전으로라도 돌아갈 수 있습니다.
안정화된 Version-1.0을 받은 뒤에 다음과 같이 소금 문제를 해결합니다.
그리고 커밋합니다.
Mercurial은 새로운 헤드가 만들어졌다고 알려줍니다. 이제 두개의 헤드가 있습니다. 2.0 헤드는 아까 작업하던 것이고 1.1 헤드는 좀 전에 커밋한 것입니다.
이제 수정된 버전을 Version-1.1로 태깅하고 고객에게 릴리즈할 수 있습니다. 그리고 저는 다시 2.0 버전 작업을 계속 합니다.
한가지 문제점은 소금에 대한 수정이 여기에는 없다는 겁니다. 어떻게 해결할 수 있을까요?
어 이런~ 저는 태그를 병합해야 하네요. 이건 Mercurial의 아주 성가신 버그 입니다. 문제는 Mercurial의 태그가 단순히 .hgtags 라고 이름 붙여진 파일이라는 겁니다. 그리고 이 파일은 레포지토리에 포함되어 있습니다. 그래서 종종 당신은 .hgtags 파일을 수작업으로 병합해야 하는 경우가 생깁니다. 이 문제의 해결은 아주 쉽습니다. 단순히 양쪽 모두를 한 파일에 합쳐 놓으면 됩니다.
이렇게 태깅된 버전으로 되돌아가서 이미 납품된 코드를 약간 수정하는 건 쉽게 할 수 있습니다. 근데 사실 모든 소프트웨어 프로젝트에서 이런식의 일이 빈번하게 일어납니다. 하지만 Mercurial은 아주 편리하게 이런 걸 처리하게 해 줍니다.
이런식으로 1.0 버전 이후의 모든 변경을 되돌리고 고객에게 납품했던 1.0버전으로 되돌아갈 수 있는 기능은 고객이 겪고 있는 버그를 바로 재현할 수 있다는 점에서 매우 편리합니다. 그러면서도 새로운 버전의 개발을 계속해 나갈 수 있구요.
하나의 레포지토리를 놓고 이전 버전과 현재 버전을 왔다 갔다하는 방법 대신에 stable과 dev라는 두개의 레포지토리를 가져가는 방법도 있습니다.
stable 레포지토리는 고객에게 납품했던 가장 최신의 메이저 버전을 보관하고 있습니다. 아주 급한 버그를 수정하려면 그저 stable 레포지토리에서 수정하면 됩니다. 이런 변경은 1.0 버전의 패치들이 됩니다.
dev 레포지토리는 2.0 버전으로 가는 주요 개발 과정을 담습니다.
1.0 버전을 납품하자 마자 stable 을 복제해서 dev 레포지토리를 만듭니다.
저는 이제 두개의 똑같은 레포지토리를 가지고 있습니다.
체인지셋 14까지의 모든 히스토리는 동일하기 때문에 Mercurial은 하드링크(hard link)라는 파일시스템 기능을 이용하여 실제 데이타를 복사하지 않고 가볍게 복제하는 효과만 냅니다. 이런 이유로 hg clone은 아주 빠르고 간편합니다. 그러므로 클론(clone)을 여러개 만드는 걸 망설일 필요가 없습니다.
이제 dev 레포지토리에서 구아카몰 레서피를 계속 수정합니다.
그리고 아까와 같이 너무 짠 문제를 stable 레포지토리에서 수정합니다.
이를 1.1 버전으로 태깅합니다.
이제 stable의 수정사항을 dev로 당겨 옵니다.
우리가 한게 이런 겁니다.
만일 저 복잡한 그림을 이해할 수 있다면, 당신은 Mercurial을 잘 이해하고 있는 겁니다. 요점은 stable 레포지토리는 오직 버그 픽스만 가지고 있는 반면 dev 레포지토리는 당신의 새로운 코드와 버그 픽스를 병합하여 같이 가지고 있다는 겁니다.
여러개의 레포지토리를 사용하는 다른 방법들도 있습니다.
- 당신은 몇명이 같이 어떤 기능을 개발하는 팀 레포지토리를 만들 수 있습니다. 그들이 새로운 기능을 개발하여 잘 돌아간다면 이 팀 레포지토리를 메인 개발 레포지토리로 푸쉬할 수 있습니다. 그래서 다른 사람들이 이 새로운 코드를 볼 수 있게 합니다.
- 당신은 테스터들을 위해 QA 레포지토리를 만들 수 있습니다. 그래서 테스트할 코드를 메인 레포지토리에 푸쉬하기 보다는 QA 레포지토리에 푸쉬하는 겁니다. 테스터들이 테스트를 끝내고 문제없음이 확인되면 당신은 QA 레포지토리에서 메인 레포지토리로 푸쉬합니다. 이런식으로 해서 메인 레포지토리는 항상 검증된 코드들만 적재됩니다.
- 각 개발자가 자신의 레포지토리를 가지고 있기 때문에, 당신은 팀의 다른 사람에게 영향을 주지 않고, 동료로부터 실험적인 체인지셋을 당겨와서 테스트할 수 있습니다.
스스로 해보세요
튜토리얼을 보았다면 이걸 할 수 있어야 합니다.
1. 오래된 버전을 태깅하고 그 버전으로 돌아간다.
2. stable과 dev 레포지토리를 사용하도록 팀을 꾸린다.
자 이제 우리는 튜토리얼의 마지막에 도달했습니다. 튜토리얼에서는 Mercurial의 극히 일부분만 설명했을 뿐입니다. 그리고 세상에는 더 깊이있고 자세한 내용의 문서들이 많습니다. Bryan O'Sullivan이 쓴 Mercurial: The Definitive Guide 라는 책은 Mercurial의 모든 것을 자세하게 다루고 있는 책입니다. 그리고 어떤 질문이 있으면Kiln Knowledge Exchange라는 지식 데이타베이스를 활용하는 것도 좋습니다.
댓글 없음:
댓글 쓰기