VCS에 소프트웨어 버전 번호를 저장하는 것이 좋습니다?

와 같은 제품 버전 v1.0.0.100은 소프트웨어의 고유 한 프로덕션 릴리스를 나타낼뿐만 아니라 해당 제품의 기능 세트와 핫픽스 단계를 식별하는 데 도움이됩니다. 현재 제품의 최종 패키지 / 빌드 / 이진 버전을 유지 관리하는 두 가지 방법이 있습니다.

1. 버전 관리. 파일은 어딘가에 버전 번호를 저장합니다. CI (Continuous Integration) 빌드 서버에는이 체크인 버전 번호를 사용하여 필요한 소프트웨어의 모든 영역 (2 진, 설치 프로그램 패키지, 도움말 페이지, 문서 등)에 적용하는 소프트웨어를 빌드하는 스크립트가 있습니다.

2. 환경 및 / 또는 빌드 매개 변수. 버전 관리 외부에서 유지 관리됩니다 (즉, 스냅 샷 / 태그 / 지점에 연결되지 않음). 빌드 스크립트는 같은 방식으로 숫자를 분배하고 사용하지만 값을 다르게 가져 옵니다 ( 소스 스크립트를 통해 소스 트리에 상대적인 위치를 알 수있는 대신 빌드 스크립트에 제공됨 ).

첫 번째 접근 방식의 문제점은 메인 라인 분기에서 병합을 복잡하게 만들 수 있다는 것입니다. 동일한 소프트웨어의 병렬 릴리스 2 개를 계속 유지하는 경우 마지막 병합 이후 버전이 모두 변경된 경우 두 메인 라인간에 병합 할 때 충돌이 해결됩니다.

두 번째 접근 방식의 문제점은 화해입니다. 1 년 전 릴리스로 돌아 가면 릴리스 정보를 식별하기 위해 태그 정보에만 의존합니다.

두 경우 모두 CI 빌드 이전에 알려지지 않은 버전 번호의 특정 측면이있을 수 있습니다. 예를 들어, CI 빌드는 실제로 자동화 된 빌드 번호 인 4 번째 컴포넌트 (예 : 지점에서 140 번째 빌드)를 프로그래밍 방식으로 배치 할 수 있습니다. VCS의 개정 번호 일 수도 있습니다.

소프트웨어의 버전 번호를 유지하는 가장 좋은 방법은 무엇입니까? "알려진"부분은 항상 VCS에 유지되어야합니까? 그렇다면 주요 지점 간 충돌이 문제입니까?

현재 CI 빌드 계획 (Atlassian Bamboo)에서 지정되고 유지 관리되는 매개 변수를 통해 버전 번호를 유지합니다. CI 빌드가 시작 되기 전에 master버전 번호가 올바르게 설정되어 있는지 지점으로 병합하기 전에주의해야 합니다 . Gitflow 워크 플로와 관련하여 소스 번호에서 버전 번호를 추적 한 release경우 릴리스 준비시 지점을 만들 때 버전 번호가 올바르게 설정 되었음을 보장 할 수 있습니다 . QA는이 지점에서 최종 통합 / 연기 / 회귀 테스트를 수행하고 사인 오프시 master릴리스 약속을 알리는 병합이 수행됩니다.

개인적으로 옵션 3 : VCS 메타 데이터 , 특히 태그 에 버전 관리 정보 유지를 선택 합니다.

Git은 git describe태그를 기반으로 한 커밋을 고유하게 설명 할 수 있는 command가 있기 때문에 그렇게하기가 매우 쉽습니다 . 작동 방식은 다음과 같습니다.

• 현재 커밋에 태그가 지정된 경우 태그 이름을 출력하십시오.
• 그렇지 않으면 태그를 찾을 때까지 히스토리를 뒤로 이동 한 후 다음 형식으로 설명을 출력하십시오 <tag>-<number of commits since the tag>-g<abbreviated commit hash>.
• 작업 트리에 커밋되지 않은 변경 사항이 있으면을 추가하십시오 -dirty.

따라서 릴리스 빌드를 수행하고 커밋에 태그가 지정된 1.2.3경우 출력 1.2.3됩니다. 현재 1.2.4에서 작업 중이고 1.2.3 이후에 4 개의 커밋을 만들고 트리에서 커밋되지 않은 변경 사항이 있으면이 결과가 출력 1.2.3-4-gdeadbee-dirty됩니다.

이것은 독특하고 단조롭고 사람이 읽을 수 있으므로 버전 문자열로 직접 사용할 수 있습니다 . 태그에 대한 적절한 이름 지정 규칙 만 있으면됩니다.

예. 대부분의 버전 번호를 vc로 유지하는 것이 좋습니다. 우리가 major.minor.patch.build가있는 의미 버전 관리 semver.org를 고려한다면 처음 3 개는 vcs에 있어야합니다. 마지막 것은 바이너리가 만들어진 특정 커밋을 역 추적하는 데 사용되는 빌드 서버에서 증가하는 숫자 일 수 있습니다.

.NET에서 이것을 용이하게하기 위해 git에 커밋 된 작은 cmd 줄 exe를 만들었습니다. 사전 빌드 이벤트에서는 빌드 중에 teamcity가 태그 한 빌드 번호를 선택합니다. 이 cmd 라인 도구는 빌드 번호를 포함하는 하나의 상수로 클래스를 자동 생성합니다. 나머지 버전 번호 : major.minor.patch는 다른 파일의 일반 상수입니다. 이 두 개의 공유 파일은 솔루션의 모든 어셈블리에 링크 (alt + shift-drag)로 포함됩니다.

이 접근 방식은 팀 시티가 코드를 작성하고 테스트 할 수있을만큼 강력합니다. azure로 푸시하고 kudu가 다시 빌드하지만 teamcity 빌드 번호를 dll 버전으로 사용하십시오.