| sitelink1 | http://sysnet.pe.kr/100110506912 |
|---|---|
| sitelink2 | |
| sitelink3 |
Label 을 사용하는 대표적인 시나리오는 "특정 시점으로 소스 코드를 돌리고 싶은 경우" 입니다. 그런데, 엄밀히 따지고 보면 이 기능은 사실 changeset에도 이미 있습니다. 곧바로 실습으로 들어가볼까요!
지난 번 마지막으로 설명했던 changeset 55 에 이어서 진행해보겠습니다. 솔루션 탐색기의 프로젝트 노드에서 마우스 오른쪽 버튼을 눌러 "View History" 메뉴를 선택하고 "Source Location" 에서 솔루션 파일명을 제거하고 새로 고침을 합니다.
현재는 위의 실습을 진행하면서 label을 해둔 적이 없기 때문에 테스트가 안되므로, 간략한 테스트를 위해 현재의 changeset 55 번에 label을 지정해 두도록 하겠습니다. 소스 컨트롤 탐색기를 열고 팀 프로젝트 노드(또는, 원하는 하위 노드)에서 "Apply Label" 메뉴를 선택합니다.
"New Label" 대화창에서 "Name" 과 간단한 주석을 달아놓고 "Create" 버튼을 누릅니다.
자, 이제부터 각자 여러 번의 체크인을 해보시기 바랍니다. 저 같은 경우 다음과 같은 식으로 changeset 기록을 남겼습니다.
- Class1.cs 파일 삭제, Class2.cs 파일 추가: Changset 56
- 프로젝트 속성에서 Target Framework 속성을 .NET 2.0에서 .NET 3.5 로 변경: Changeset 58
- AssemblyInfo.cs 의 AssemblyCompany 특성 값을 "Test Company"로 변경: Changeset 59
(위의 그림을 보시면 Changeset 57 번이 없는데요. 왜냐 하면, 다른 팀 프로젝트에서 이 시점에 check-in을 했기 때문입니다. 이전에도 설명했지만, 체크인 번호는 팀 프로젝트 단위가 아닌 팀 프로젝트 컬렉션 단위로 증가합니다.)
자, 이제 그럼 문제가 발생해서 changeset 55 번 당시의 소스 코드 상태로 통째로 돌려야 하는 상황이 발생했다고 가정합니다. 그럼, 간단하게 목록에서 changeset 55번을 선택하고 "Get This Version" 메뉴를 실행하면 됩니다.
"Output"창을 통해서 Changeset 59번, 58번, 56번, 55번 순으로 차례대로 소스 코드가 자동 복원되는 것을 확인할 수 있습니다.
물론, 이 기능은 Label 에서도 동일하게 적용됩니다. 55번 체크인 단계에서 Label 을 설정해 놓았기 때문에 "Labels" 탭에서 해당 Label 을 선택한 후 "Get This Version" 메뉴를 실행하면 마찬가지로 그 시점으로 소스 코드가 모두 복원됩니다.
결과가 그러한데, Changeset 과 Label 을 굳이 중복해서 둘 의미가 있을까요? 뭐랄까? 편의성 차원이라고 봐도 무방할 것 같습니다. Changeset은 현실적으로 너무 자주 발생해서 목록이 너무 많다는 것이고, 그에 반해 Label은 좀 적기 때문에 찾기가 쉽습니다. (물론, S/W 개발 방법론에 따른 "dsk#3042jdlajfas#r3wkj432039456(*(^&%&^%" 의 이유가 있을 것입니다.)
사실, Label은 위에서 했던 것처럼 별도의 수작업을 거쳐서 사용자가 직접 생성해 주어야만 하거나, 또는 (기본값으로) 팀 빌드 시에 자동으로 Label 생성이 됩니다.
Label은 그래서 팀에서 결정되는 정책에 따라 그 활용 방안이 다양해 질 수 있습니다.
예를 들어, 어떤 팀은 반드시 제품을 외부에 배포시에만 Label을 해둔다거나, 아니면 팀 빌드 중에서도 하루 한번만 하는 "Night Build"에서만 Label을 생성하도록 한다든지... 일 것입니다.
활용 시나리오를 생각해 보면, 원래는 응용 프로그램이 "메모리 누수" 현상이 없었는데, 어느 순간 부터인가 발생해서, 하루 단위로 적용되었던 Label을 이용해서 소스 코드를 돌리면서 메모리 누수 현상이 없던 순간의 소스 코드를 찾아들어갈 수 있습니다. 일단 정상적인 소스 코드 였던 때를 발견하면 그 이후에 변경된 소스 코드와 비교를 통해서 문제의 원인을 찾아낼 수 있습니다. (물론, 디버깅 능력이 뛰어난 팀원이 있다면 이런 수고가 필요없을 수 있습니다.)
또는, 1년 전에 A 라는 고객에게 배포된 1.0 버전에서 오류가 발생했는데, 고객은 현재의 새로운 2.0 버전을 적용하길 원치 않고 그 버그만 수정되길 바라는 상황일 수도 있는데요. 그럴 때, 당시의 배포 버전에 Label 을 해두었다면 그 소스 코드로 원복해서 branch를 한 후 버그만 수정해서 전달해 줄 수 있습니다.
또는, 배포 시마다 Label을 해놓았는데 A, B, C 순으로 배포를 하는 과정에서 B 배포본부터 심각한 오류가 있다는 것을 뒤늦게 알게 되어, A 배포본으로 금방 배포본을 만들어 고객에게 줄 수 있습니다. (물론, 바이너리 수준에서 A 배포본으로 돌아가는 것을 뛰어넘어 소스 코드까지 그 당시로 돌릴 수가 있다는 것을 잊지 마세요!)
또는... 기타 등등!!!
부가적으로, 혹시나 저한테 Label을 사용하는 기준을 묻는다면? 다음과 같이 말씀드리고 싶습니다.
- 개발 초반: 하루 한번씩 자동 빌드되는 Night build에 Label을 적용.
- 개발 후반: "배포 시점"마다 Label을 적용하는 것을 "추가"
- 개발 완료 후 유지 보수 단계: "배포 시점만" Label을 적용. (Night Build 자체를 제거, 또는 Night Build 시의 Label 기능 제거)
[출처] TFS 소스 코드 관리 기능 (3) - Label|작성자 techshare
