공통 비즈니스 코드, WCF 서비스 및 단일 데이터베이스를 공유하는 여러 클라이언트 UI (데스크톱, Silverlight, iPhone)로 구성된 제품이 있다고 가정 해 보겠습니다. 모든 소스는 단일 자식 저장소에 있습니다.클라이언트 앱과 서비스의 버전 번호는 각각 구분 되나요?
각 UI 조각과 WCF 서비스를 독립적으로 빌드하고 버전을 관리해야합니까? 아니면 새 빌드에서 모든 버전 번호를 증가시켜야합니까?
공통 비즈니스 코드, WCF 서비스 및 단일 데이터베이스를 공유하는 여러 클라이언트 UI (데스크톱, Silverlight, iPhone)로 구성된 제품이 있다고 가정 해 보겠습니다. 모든 소스는 단일 자식 저장소에 있습니다.클라이언트 앱과 서비스의 버전 번호는 각각 구분 되나요?
각 UI 조각과 WCF 서비스를 독립적으로 빌드하고 버전을 관리해야합니까? 아니면 새 빌드에서 모든 버전 번호를 증가시켜야합니까?
내 머리 꼭대기에는 여러 가지 방법으로 처리 할 수 있으며 그 중 어느 것도 "올바르지 않습니다." 그것은 모두 릴리스 프로세스 및 고객에게 제품을 제공하려는 방법에 따라 다릅니다.
lockstep으로 구성 요소를 테스트하고 릴리스하면 버전 번호를 잠금 단계로 이동하는 것이 유용 할 수 있습니다. 그런 식으로 모든 사람들은 1.4.4 버전의 데스크탑 UI가 1.4.4 iPhone 버전이 동일한 기능을 가져야한다는 것을 알고 있습니다.
사용자 인터페이스가 다른 시간에 다른 기능을 가질 수 있지만 (데스크톱에서 기능을 릴리스하려면 서두르지 만 iPhone을 기다릴 수 있음) 분명히 다른 버전 번호를 갖게됩니다. 그러나 주요 릴리스에서 버전 번호를 X.0.0으로 다시 동기화해야합니다.
제품을 평소 <major>.<minor>.<maintenance-patch>
부분에 대한 자체 버전 일정을 따르고 빌드 번호를 마지막 구성 요소로 포함 시키면 다소 문제가 될 수 있습니다. 따라서 <major>.<minor>.<patch>.<build>
으로 끝날 것입니다. 이 방법의 장점은 다른 시간대에 다른 구성 요소를 릴리스 할 수 있으며 빌드의 기록을 여전히 얻을 수 있다는 것입니다. 이 경우 빌드 번호는 일반적으로 중앙 집중식 빌드 시스템에 의해 관리되는 단조롭게 증가하는 숫자 여야합니다. 나는 일반적으로 빌드 시스템에 버전 번호를 제어하는 것을 좋아하지 않는다. 마케팅, 제품 라인 관리 등과 같이 주제에 대해 많은 민감성이있을 수 있기 때문이다. 빌드 번호를 갖는 것은 매우 유용하지만 최소한으로 만든다. 버전 번호의 중요한 부분.
한 가지 사항은 한 번에 빌드 프로세스가 "세상을 구축하는"것입니다. 분명히 개발자의 편의를 위해 별도의 UI를 만들 수 있지만, 한 번에 모든 종속성을 가진 모든 가능한 구성 요소를 빌드하는 야간 빌드 프로세스를 관리하는 것이 훨씬 쉽습니다. 그리고 모든 UI가 리포지토리에서 동일하고 현재의 공유 구성 요소를 사용하는지 확인하십시오. 서로 다른 버전의 공유 구성 요소가 필요한 경우 모든 것을 올바르게 빌드하려고 할 때 상처를 입히는 것이 좋습니다. 그런 다음 UI의 빌드를 트리거하는 다양한 구성 요소에 대한 별도의 빌드가 생성됩니다.