TFS 소스 제어 사용과 관련하여 모범 사례를 제시하려고합니다. 현재 빌드를 할 때마다 TFS에 체크인되는 파일에 버전 번호를 표시합니다. 이 접근 방식은 단순히 파일을 확인하고 주석에 버전 번호를 갖는 것보다 좋거나 나쁩니 까? 그런 다음 변경 집합을 사용하여 필요한 경우 되돌릴 수 있습니까? 아니면 레이블이 여전히 더 다양합니까?TFS : 레이블 대 변경 집합
감사합니다.
두 가지 목적이 있습니다. 변경 세트는 파일이 실제로 변경된 경우이며 변경 사항에 대한 영구 기록을 유지하려는 경우입니다. 레이블은 파일의 특정 버전을 표시하므로 쉽게 그 지점으로 되돌아 갈 수 있습니다. 빌드가 소스 제어에서 실제로 파일을 변경하지 않고 이러한 변경 사항을 기록하려는 경우가 아니면. 라벨을 붙여야합니다.
또한 라벨 지정은 리소스 집약이 훨씬 적습니다. 또한 동일한 버전의 파일에 여러 라벨을 지정할 수 있습니다.
는 지금, 우리는 빌드를 수행 언제든지, 우리는 버전 번호 당신은이 작업을 수행 할 필요가 없습니다
으로 TFS로 확인되는 파일을 레이블을 붙입니다. TFS는 다양한 방법으로 코드베이스의 상태를 참조 할 수 있습니다. 레이블은 사실 하나이지만 빌드와 심지어 변경 세트입니다. 당신은 Get Specific Version...을 수행하고 Type 드롭 다운에서 옵션을 검사하여 특정 시점을 재구성 할 수있는 가능한 방법을 볼 수
Changeset
Date
Label
Latest Version
Workspace Version
Changeset 방금 어떤 변경 집합 후 얻을 수를; Date은 분명합니다. Label도 마찬가지입니다. 자동으로 * 라벨을 만듭니다.이 드롭 다운에서 Label을 선택한 다음 Find Label 대화 상자에보세요.
* 자동으로 생각합니다! 그게 아니라면 특별히 그 순간에 내가 설정 한 게 아니라면 ...
빌드 정의 설정 (고급 섹션 아래)에서 옵션을 선택하면 팀 빌드가 자동으로 레이블을 지정할 수 있습니다. – jessehouwing
빌드를 구성하는 소스 파일의 버전에 라벨을 지정해야합니다. TeamBuild를 사용하는 경우 자동으로 수행됩니다. 빌드 정의, 날짜 및 빌드 번호의 이름을 결합합니다. 따라서 아무 것도 할 필요가 없습니다.
다른 옵션은별로 일반적이지 않으며 많은 불필요한 작업이 필요합니다. 올바르게 이해한다면 빌드 프로세스 중에 소스 파일을 체크 아웃 한 다음 체크 인 주석에 지정된 버전 번호로 다시 체크인하십시오. 이것은 Alex가 빌드 프로세스 및 소스 제어 저장소와 관련하여 매우 리소스 집약적이라고 언급했기 때문입니다. 또한 버전 정보가 주석에 포함되어있는 경우 특정 버전의 소스 파일을 어떻게 얻을 수 있습니까? 매우 어려울 것이므로 TFS 소스 제어 API를 사용하여 체크 인 주석의 버전 번호를 검색하여 작업 영역에 소스 파일을 다운로드하는 자신 만의 응용 프로그램을 작성해야합니다. 이것은 불필요한 복잡성과 골치 거리를 만듭니다.
대신 레이블을 사용하는 경우 VS IDE에서 가져 오기 레이블을 사용하여 해당 레이블을 구성하는 소스 파일을 다운로드 할 수 있습니다. 빌드 자동화 중에 최신 소스 파일을 다운로드하는 대신 레이블을 사용하도록 TeamBuild에 지시 할 수도 있습니다. 그렇게하면 이전 버전의 응용 프로그램을 쉽게 빌드 할 수 있습니다. 레이블을 사용하면 나중에 해당 레이블을 가져온 다음 특정 변경 집합을 가져온 다음 빠른 레이블을 지정하거나 새로운 레이블을 작성하여 코드가 변경된 경우 나중에 변경 집합을 기존 레이블에 적용 할 수 있습니다.
레이블 지정은 매우 강력하고 사용하기 편리하며 TFS의 일부입니다. 작업 및 유지 관리에 많은 노력을 기울이는 사용자 지정 솔루션을 준비하는 대신 이미 사용 가능한 솔루션을 사용하십시오.
StackOverflow는 위의 답변에 대해 언급하지 않으므로 새로운 "답변"으로 작성하고 있습니다. 위에 열거 한 오해의 일부를 명확히하고 싶습니다.
먼저 TFVC 레이블을 사용하면 변경 집합을 사용하는 것보다 리소스가 많이 소모됩니다. 훨씬 더. 분기, 병합 및 레이블 가져 오기와 같은 명령은 속도가 느립니다. 거대한 데이터베이스가있는 엔터프라이즈 서버의 경우 레이블을 사용하고 싶지 않습니다.
둘째, 기본 빌드 단계에 레이블을 만드는 단계가 포함되어 있지만 빌드에서는 자동으로 레이블을 만들지 않습니다.
셋째, 앞서 언급 한 다른 것들처럼 레이블을 이동하거나 삭제할 수 있기 때문에 불변의 변경 집합보다 훨씬 덜 신뢰할 수 있습니다.
전체적으로 레이블을 사용하지 않는 것이 좋습니다. 가장 간단한 대안은 빌드의 변경 세트 번호를 기억하는 것입니다. 또는 다른 릴리스 버전을 분리하려는 경우 릴리스 분기를 만들어야합니다.
레이블은 소형 시스템에는 적합하지만 대기업에는 적합하지 않습니다.
설치가 완료되면 VSTS 에이전트의 빌드 프로세스에서 해당 코드 버전의 레이블을 만듭니다. 이것은 당신이 말한 성능 문제를 완화시키지 못하지만, Chanset 번호처럼 영구적이고 결정적인 것을 참조하는 레이블을 더욱 신뢰할 수있게합니다. 이를 통해 Build에 포함 된 코드의 버전을 쉽게 찾을 수 있지만, 누군가 Label을 편집하거나 삭제하면 재앙이되지 않습니다. –
라벨이 무섭거나, 코드베이스의 일부에만 적용될 수 있으며, 사실 이후에 변경할 수 있으며 삭제 될 수 있습니다. CS 번호는 상수입니다. TFS 관리자가 Destroy를 사용하여 소스 제어에서 파일을 삭제하는 경우가 아니면 레이블을 복원 할 수없는 경우를 제외하고는 항상 최신 버전을 가져야합니다. 필자가보기에는 사람이 읽을 수있는 이름을 붙일 수 있고 검색 할 수 있기 때문에 라벨이 멋지다. CS 번호는 대안으로 잘 작동합니다. – jessehouwing