빌드 버전 관리를 위한 최고의 빌드 프로세스 솔루션

https://stackoverflow.com/questions/57730

09-06-2019
|

문제

저는 여러 개의 독립적인 응용 프로그램을 사용하여 다소 복잡한 프로젝트를 실행하고 있습니다.그러나 이들은 몇 가지 공유 구성 요소를 사용합니다.그래서 아래와 같은 소스 트리가 있습니다.

내 프로젝트
- 응용 프로그램 A
- 공유1
- 공유2
- 애플리케이션 B
- 애플리케이션 C

모든 애플리케이션에는 프로젝트와 필요한 모든 공유 리소스를 빌드하는 자체 MSBuild 스크립트가 있습니다.또한 CruiseControl로 제어되는 지속적 통합 빌드 서버에서 이러한 빌드를 실행합니다.

애플리케이션이 배포되면 로드를 분산하기 위해 여러 서버에 배포됩니다.이는 다음과 같은 의미입니다. 극도로 각 서버에 배포된 빌드/개정을 추적하는 것이 중요합니다(예: "1.0.0.68"과 같이 DLL 버전에 현재 버전이 있어야 함).

무언가가 의도한 대로 작동하지 않은 경우(예, 그런 일이 발생했습니다...) 롤백할 수 있도록 구축된 개정/빌드를 다시 생성할 수 있는 것도 마찬가지로 중요합니다.현재 우리는 소스 제어를 위해 SourceSafe를 사용하고 있지만 그에 대한 합당한 이유를 제시할 수 있다면 변경할 수도 있습니다(SS 실제로는 괜찮습니다). 그래서 멀리).

우리가 따르려고 하는 또 다른 원칙은 우리가 추가로 배포하는 통합 서버에 의해 빌드되고 테스트된 코드만 있다는 것입니다.

"CrusieControl 빌드 라벨" 솔루션

우리는 위의 문제를 해결하기 위한 몇 가지 아이디어를 가지고 있었습니다.첫 번째는 지속적인 통합 서버를 구축하고 프로젝트를 로컬로 배포하고 테스트하는 것이었습니다(지금은 그렇게 하고 있습니다).아마도 CruiseControl에서 성공적인 빌드가 빌드 라벨을 생성하고 이를 사용하여 실행 파일의 DLL 버전을 설정할 수 있다는 것을 알고 계실 것입니다(따라서 빌드 라벨 35는 "1.0.0.35"와 같은 DLL을 생성합니다).아이디어는 또한 이 빌드 라벨을 사용하여 완벽한 소스 트리.그러면 해당 레이블을 확인하고 나중에 빌드를 다시 생성할 수 있을 것입니다.

전체 트리에 레이블을 지정하는 이유는 실제 애플리케이션 코드(소스 트리의 한 위치에 있음)뿐만 아니라 모든 공유 항목(트리의 다른 위치에 있음)도 포함하기 위해서입니다.따라서 "Application A"의 성공적인 빌드는 예를 들어 "ApplicationA35"라는 레이블을 사용하여 전체 트리에 레이블을 지정합니다.

그러나 이 빌드를 다시 생성하고 배포하기 전에 DLL 버전을 설정하려고 하면 더 이상 CruiseControl 생성 빌드 라벨에 액세스할 수 없으므로 문제가 발생할 수 있습니다.모든 CrusieControl 빌드 라벨이 모든 프로젝트에 대해 고유한 경우 라벨링에 번호만 사용할 수 있지만 그렇지 않습니다(애플리케이션 A와 B가 동시에 빌드 35에 있을 수 있음). 상표.따라서 SourceSafe 레이블은 "Application35"입니다. 그런 다음 빌드 34를 다시 만들고 빌드 35를 빌드한 후 1.0.0.34를 DLL 버전 번호로 설정하려면 어떻게 해야 합니까?

"개정 번호" 솔루션

예를 들어 Subversion은 체크인할 때마다 전체 소스 트리에 대한 개정 번호를 생성한다고 누군가가 말했습니다. 이게 사실이야?SourceSafe에도 비슷한 것이 있나요? 이것이 맞다면 최신 버전을 얻을 때 해당 개정 번호를 가져와 CruiseControl 서버에 구축하는 것이 좋습니다.그런 다음 개정 번호를 사용하여 DLL 버전 번호(예: "1.0.0.5678")를 설정할 수 있습니다.그런 다음 필요한 경우 Subversion에 대한 특정 개정판을 얻을 수 있으며 여기에는 해당 응용 프로그램과 과거의 특정 버전을 다시 만들 수 있는 모든 공유 항목이 포함됩니다. 이것이 효과가 있고 SourceSafe를 사용하여 달성할 수도 있습니까?

요약하다

따라서 두 가지 주요 요구 사항은 다음과 같습니다.

가능하다 빌드 및 배포된 DLL의 빌드/개정 번호를 추적합니다.
가능하다 과거 개정/빌드를 다시 빌드하고 해당 빌드의 실행 파일에 이전 빌드/개정 번호를 설정합니다. (요구사항 1을 준수하기 위해).

그렇다면 이 문제를 어떻게 해결하시겠습니까? 귀하가 선호하는 접근 방식은 무엇이며, 어떻게 당신은 그것을 해결하시겠습니까?(아니면 완전히 다른 생각을 갖고 계십니까?)**자세한 답변 부탁드립니다.**

보너스 질문 개정 번호와 빌드 번호의 차이점은 무엇이며 실제로 둘 다 필요한 경우는 언제입니까?

해결책

귀하의 계획은 VSS에서 건전하고 달성 가능합니다. 대안을 고려해 보라고 제안하지만 VSS는 실제로 오래된 제품입니다.

"CI" 빌드의 경우 버전 관리를 수행합니다. MSBuild 커뮤니티 작업 프로젝트 "버전" 작업이 있습니다.일반적으로 소스 트리에 "Version.txt"가 있고 MSBuild 작업은 개발자가 Major.Minor.Release.Revision 번호를 제어하는 동안 "릴리스" 번호를 증가시킵니다(이것이 내 클라이언트가 원했던 방식입니다).원하는 경우 개정판을 사용할 수 있습니다.

그런 다음 해당 버전으로 AssemblyInfo.cs 파일을 편집하는 "FileUpdate" 작업이 있고 EXE 및 "DLL"은 원하는 버전을 갖게 됩니다.

마지막으로 VSSLabel 작업은 모든 파일에 적절하게 레이블을 지정합니다.

"Rebuild" 빌드의 경우 - "Get"을 수정하여 해당 레이블에서 파일을 가져오며, 분명히 "Version" 작업을 실행하지 않고(빌드할 버전을 선택하므로) FileUpdate 작업에서 해당 버전 번호를 사용합니다.

보너스 질문:

이것은 모두 "사용하려는 방법"입니다. 빌드 번호를 사용하여 빌드 번호를 늘릴 것입니다.CI를 사용하는 경우 매우 많은 빌드가 있을 것입니다. 대다수는 어디에도 배포할 의도가 없습니다.

메이저와 마이너는 자명하지만 저는 항상 "핫픽스" 표시를 위해 개정판을 사용해 왔습니다.나는 "1.3" 릴리스를 계획하고 있습니다. 실제로는 1.3.1234.0 버전의 제품이 될 것입니다.1.4에서 작업하는 동안 버그를 발견하여 1.3.2400.1의 핫픽스가 필요합니다.그런 다음 1.4가 준비되면 1.4.3500.0이 됩니다.

다른 팁

댓글이 직접적으로 허용하는 대로 응답하는 것보다 더 많은 공간이 필요합니다...

감사해요!좋은 답변입니다!차이점은 무엇인가, 예를 들어 Subversion을 사용하여 이것을 더 잘 해결하는 것이 무엇입니까? Richard Hallgren (15 시간 전)

VSS의 문제는 이 예와 관련이 없습니다. (제가 생각하는 "레이블 지정" 기능은 비효율적으로 구현되었지만...)

VSS와 관련된 몇 가지 문제는 다음과 같습니다.

1) 분기는 기본적으로 불가능합니다. - 대부분의 상점의 시점까지는 완전히 신뢰할 수 없습니다.

4의 경우 문제는 VSS가 파일 시스템에서 "플랫 파일"로 표시되는 전체 저장소에 의해 구현된다는 것입니다.저장소가 특정 크기(4GB라고 생각하지만 그 수치에 대해서는 확신할 수 없음)를 초과하면 "손상"이 발생할 수 있습니다.규모가 커질수록 부패 가능성은 거의 확실해질 때까지 커집니다.

따라서 저장소 크기를 살펴보고 기가바이트에 도달하는 경우 VSS 교체 계획을 시작하는 것이 좋습니다.

그럼에도 불구하고 - "VSS Sucks"라는 구글은 30,000번의 조회수를 제공합니다...만약 당신이 대안을 사용하기 시작했다면, 당신은 그것이 노력할만한 가치가 있다는 것을 깨닫게 될 것입니다.

CC.net에서 성공적인 빌드에 라벨을 지정하도록 하세요.
솔루션의 각 프로젝트를 어셈블리 및 파일 버전 특성이 포함된 공통 Solutioninfo.cs 파일에 연결합니다(각 프로젝트에서 Assemblyinfo.cs 제거).
빌드를 순항 제어하기 전에 msbuild regex 바꾸기(msbuild 커뮤니티 작업에서)를 실행하여 cc.net 빌드 레이블(msbuild 작업에 매개 변수로 전달됨)을 사용하여 버전 정보를 업데이트합니다.
솔루션 구축, 테스트 실행, FX 경찰 등
선택적으로 솔루션 정보 파일을 되돌립니다.

결과적으로 cc.net 게시된 빌드의 모든 어셈블리는 소스 코드 저장소의 레이블을 따르는 동일한 버전 번호를 갖게 됩니다.

UppercuT는 애플리케이션을 분할하는 맞춤형 패키징 작업을 통해 이 모든 작업을 수행할 수 있습니다.소스의 버전 번호를 얻으려면 Subversion을 생각해 보세요.

시작하는 것도 엄청나게 쉽습니다.

http://code.google.com/p/uppercut/

여기에 좋은 설명이 있습니다: 어퍼컷

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow