버전 관리는 매우 열정적이며 사용하기 쉬운 버전 관리 시스템을 고안하는 데 오랜 시간을 소비 한 것입니다. 귀하의 질문에서 이미 말한 바에 따르면 한 가지 중요한 점을 이해 했으므로 어셈블리 버전 번호는 제품 버전과 동의어가 아닙니다. 하나는 기술적으로 주도되고 다른 하나는 비즈니스에 의해 주도됩니다.
다음은 어떤 형태의 소스 제어 및 빌드 서버를 사용한다고 가정합니다. 맥락에서 우리는 TeamCity 와 Subversion / Git을 사용합니다. TeamCity는 적은 수의 프로젝트에 대해 무료이며 매우 훌륭한 빌드 서버이지만 일부는 완전히 무료입니다.
버전 번호의 의미
한 사람에게 어떤 버전이 의미하는 것은 다른 사람과 다른 것을 의미 할 수 있습니다. 일반적인 구조는 주, 사소, 거시, 미시입니다. 내가 버전 번호를 보는 방법은 두 부분으로 나누는 것입니다. 전반부는 주 버전 (주요)과 주요 업데이트 (부)를 설명합니다. 후반은 언제 빌드되었으며 소스 코드 버전은 무엇인지 나타냅니다. 버전 번호는 컨텍스트에 따라 다른 의미를 가지며 API, 웹 앱 등입니다.
Major. Minor. Build.Revision
Revision 이것은 실제로 만들어진 것을 식별하기 위해 소스 컨트롤에서 가져온 숫자입니다.Build빌드 서버에서 특정 빌드를 찾는 데 사용할 수있는 숫자가 계속 증가하고 있습니다. 빌드 서버가 다른 매개 변수 세트로 동일한 소스를 두 번 빌드했을 수 있으므로 중요한 수입니다. 소스 번호와 함께 빌드 번호를 사용하면 빌드 된 내용과 방법을 식별 할 수 있습니다.Minor공용 인터페이스가 크게 변경된 경우에만 변경해야합니다. 예를 들어 API 인 경우 소비 코드가 여전히 컴파일 될 수 있습니까? 주 번호가 변경되면이 숫자를 0으로 재설정해야합니다.Major사용중인 제품의 버전을 나타냅니다. 예를 들어 모든 VisualStudio 2008 어셈블리의 Major는 9이고 VisualStudio 2010은 10입니다.
규칙의 예외
규칙에는 항상 예외가 있으며 규칙에 따라 적응해야합니다. 내 원래 접근 방식은 subversion을 사용하는 것이었지만 최근에는 Git으로 옮겼습니다. 중앙 저장소를 사용하는 서브 버전 및 소스 세이프와 같은 소스 제어에는 지정된 시간에서 특정 소스 세트를 식별하는 데 사용할 수있는 번호가 있습니다. Git과 같은 분산 소스 제어의 경우에는 해당되지 않습니다. Git은 각 개발 시스템에있는 분산 리포지토리를 사용하기 때문에 사용할 수있는 자동 증분 번호가 없으므로 체크인 횟수를 사용하는 해킹이 있지만 추악합니다. 이 때문에 접근 방식을 발전시켜야했습니다.
Major. Minor. Macro.Build
수정본 번호가 사라지고 빌드가 수정본 위치로 이동했으며 매크로가 삽입되었습니다. 당신은 당신이 맞는 것처럼 보이는 매크로를 사용할 수 있지만 대부분 혼자 남겨 둡니다. TeamCity를 사용하기 때문에 개정 번호에서 잃어버린 정보를 빌드에서 찾을 수 있습니다. 이는 2 단계 프로세스가 있지만 아무 것도 잃지 않았으며 수용 가능한 타협입니다.
무엇을 설정
가장 먼저 이해해야 할 것은 어셈블리 버전, 파일 버전 및 제품 버전이 일치하지 않아도된다는 것입니다. 다른 숫자 세트를 사용하는 것을 옹호하지는 않지만 종속 어셈블리를 다시 컴파일하지 않아도되는 공용 인터페이스에 영향을 미치지 않는 어셈블리를 약간 변경하면 인생을 훨씬 쉽게 만듭니다. 이 문제를 해결하는 방법은 어셈블리 버전에서 메이저 및 마이너 번호 만 설정하고 파일 버전에서 모든 값을 설정하는 것입니다. 예를 들면 다음과 같습니다.
- 1.2.0.0 (어셈블리 버전)
- 1.2.3.4 (파일 버전)
이렇게하면 어셈블리 버전이 일치하지 않지만 파일 버전 번호를보고 어셈블리의 개정 / 빌드를 볼 수 있으므로 기존 코드를 위반하지 않는 핫픽스를 롤아웃 할 수 있습니다. 이것은 일반적인 접근 방식이며 어셈블리 세부 사항을 볼 때 일부 오픈 소스 어셈블리에서 볼 수 있습니다.
팀 리더로서 중요한 변경이 필요할 때 부수를 늘릴 책임이 있습니다. 인터페이스에 필요한 변경을 롤아웃하지만 이전 코드를 위반하지 않는 한 가지 솔루션은 현재 코드를 사용하지 않는 것으로 표시하고 새 인터페이스를 작성하는 것입니다. 즉, 기존 코드에는 메소드가 더 이상 사용되지 않으며 언제든지 제거 할 수 있지만 모든 것을 즉시 중단 할 필요는 없다는 경고가 표시됩니다. 그런 다음 모든 것이 마이그레이션되었을 때 사용되지 않는 방법을 제거 할 수 있습니다.
함께 배선하는 방법
위의 모든 작업을 수동으로 수행 할 수 있지만 시간이 많이 걸리므로 다음은 프로세스를 자동화하는 방법입니다. 각 단계는 실행 가능합니다.
- 모든 프로젝트 AssemblyInfo.cs 파일에서
AssemblyVersion및 AssemblyFileVersion속성을 제거하십시오 .
- 공통 어셈블리 정보 파일 (VersionInfo.cs)을 만들어 모든 프로젝트에 링크 된 항목으로 추가하십시오.
- 추가
AssemblyVersion및 AssemblyFileVersion"0.0.0.0"의 값으로 버전 속성.
- 솔루션 파일을 빌드하는 MsBuild 프로젝트를 작성하십시오.
- VersionInfo.cs를 업데이트하는 빌드 전에 작업을 추가하십시오. 버전 번호를 설정할 수있는 AssemblyInfo 태스크를 포함하는 다수의 오픈 소스 MsBuild 라이브러리가 있습니다. 임의의 숫자로 설정하고 테스트하십시오.
- 빌드 번호의 각 세그먼트에 대한 특성을 포함하는 특성 그룹을 추가하십시오. 이곳에서 전공과 부전공을 설정합니다. 빌드 및 개정 번호는 인수로 전달해야합니다.
Subversion으로 :
<PropertyGroup>
<Version-Major>0</Version-Major>
<Version-Minor>0</Version-Minor>
<Version-Build Condition=" '$(build_number)' == '' ">0</Version-Build>
<Version-Build Condition=" '$(build_number)' != '' ">$(build_number)</Version-Build>
<Version-Revision Condition=" '$(revision_number)' == '' ">0</Version-Revision>
<Version-Revision Condition=" '$(revision_number)' != '' ">$(revision_number)</Version-Revision>
</PropertyGroup>
잘만되면 나는 분명했다. 그러나 많은 관련이있다. 질문하십시오. 더 간단한 블로그 게시물을 작성하기 위해 피드백을 사용하겠습니다.