다중 컴포넌트 프로젝트를 버전 화하는 가장 좋은 방법은 무엇입니까

5 가지 주요 구성 요소로 구성된 프로그램이 있습니다. 각 구성 요소의 버전을 확인하고 싶기 때문에 표준 버전 번호가 너무 제한적입니다.

누구든지 각각 별도로 나열하는 것 이외의 쉬운 방법을 찾았습니까?

우리는 제품과 동일한 문제를 가지고 있으며 각 구성 요소에 대해 개별 버전 번호를 사용하기로 결정했으며 제품 버전은 특정 버전의 다양한 구성 요소로 구성된 마케팅 버전 일뿐입니다.

특정 구성 요소 구성을 설명하는 표준 버전 번호 인 "시스템 릴리스 버전"이 있으며, 별도의 파일에는 해당 특정 시스템 릴리스의 개별 구성 요소 버전이 나열됩니다. 고객은 5.2.1이라고 말하지만 필요한 경우 개별 빌드를 찾을 수 있습니다. 일반적으로 주요 릴리스의 경우 모든 개별 버전을 동기화하여 모든 것이 동일한 지점 번호로 다시 빌드됩니다.

버전 관리는 구성 요소 기반 응용 프로그램 개발과 별 개인 문제입니다. 각 구성 요소의 버전을 지정하거나 전체 응용 프로그램의 버전을 지정하려고합니다.

버전 관리에 대한 잘 알려진 패턴은 Microsoft의 것입니다 .

major version.minor version.build number.revision

예를 들어 .NET 플랫폼의 DLL 파일에서 2.0.3600.1 또는 이와 유사한 버전을 사용할 수 있습니다.

따라서 전체 시스템 또는 해당 구성 요소를 버전 화할지 여부를 먼저 결정하는 것이 좋습니다. 전체 시스템을 버전 화하려면 각 통합 후 전체 프로젝트를 빌드 하고 빌드 번호 부분을 늘리십시오 . 그렇지 않은 경우 빌드시 각 구성 요소의 버전을 지정하십시오.

버전 관리에주의를 기울이면 사용자를 죽일 수 있습니다.

다음과 같은 접근 방식이 도움이 될 것입니다.

원하는 버전 관리 스키마를 사용하여 각 구성 요소의 버전을 개별적으로 관리하십시오. 귀하의 의견으로는 VCS가 있음을 이해합니다. 또한 각 구성 요소에는 버전이 유지되는 파일이 있다고 가정합니다 (오른쪽?). 일주일에 한 번 (팀에 더 잘 작동하는 경우) VCS의 최신 개정판 중 하나에 태그를 추가하여 해당 개정판을 최신 공식 개정판으로 표시하고 선택적으로 수퍼 개정판 번호를 증가시킵니다. 이제 VCS에 해당 태그가 포함 된 개정판을 쿼리 한 다음 해당 공식 빌드에서 구성 요소의 버전을 찾을 수 있습니다.

로컬로만 원한다면 코드에 저장된 위치에서 각 구성 요소의 버전을 집계하는 작은 스크립트를 작성하십시오.

더 멋지게 만들려면 태그를 지정하면 특정 구성 요소에 속하는 파일을 식별 할 수 있다는 점을 고려하여 각 구성 요소에 속하는 파일을 볼 수 있습니다. 변경된 경우 해당 특정 구성 요소의 버전을 늘리십시오. 대안은이 작업을 수동으로 수행하는 것입니다. 또 다른 대안은 버전 추적과 분기 및 병합의 조합입니다.

대부분의 버전 번호는 마케팅에 따른 주 버전과 부 버전을 사용하므로 개별 구성 요소 버전을 추적하는 데 사용할 수 없습니다. 즉, 개별 구성 요소의 버전을 추적하는 데 사용할 수있는 버전의 다른 부분을 찾아 전체 패키지를 추적하기 위해 주 버전과 부 버전 번호를 예약해야합니다.

Microsoft 패턴과 유사한 것을 따르는 경우 :

major-version.minor-version.build-number.revision

.revision을 사용하여 각 개별 구성 요소의 버전을 추적 할 수 있고, 부 및 주요 개정 번호를 사용하여 일반적인 방식으로 전체 제품 변경을 추적 할 수 있습니다.

이와 유사한 패턴을 따르는 경우 :

Major-Version.Minor-Version.Build-Number

개별 구성 요소 버전을 추적하려면 빌드 번호를 사용해야합니다.

버전 관리 소프트웨어에 대한 전체 책이 작성되었습니다.

내가 사용하는 접근 방식은 다음과 같습니다.

각 부분에는 다음과 같은 형식의 버전이 있습니다.

major.minor.developmental

이들 각각은 0부터 시작하는 숫자입니다.

정식 릴리스 (예 : 고객)의 경우 정책 상 개발 부분은 항상 0이어야합니다.

전공은 마케팅 결정에 따라 증가합니다.

마이너는 출시 된 기능 세트에 따라 증가합니다.

예:

• 새 구성 요소에서 개발을 시작하므로 버전 번호가 0.0.1이됩니다. 예를 들어 내부 테스트를 위해 책상에서 동료에게 릴리스하면 개발 번호는 0.0.2, 0.0.3 등으로 증가합니다.

• 나는이 새로운 것을 1.0.0으로 출시했다. 개발 종료에서 릴리스로 변경 될 수있는 유일한 변경은 버전 번호를 변경하는 것이었다 (예 : 0.0.43-> 1.0.0).

• 몇 가지 새로운 기능이 추가됩니다. 1.0.0 기준에서 작업을 시작하여 이러한 기능을 추가하므로 테스트를 위해 동료에게 릴리스하는 버전은 1.0.1, 1.0.2 등입니다.

• 다음 기능은 1.1.0으로 출시되었습니다.

• 마케팅은 다음 큰 것이 실제로 클 것이라고 결정하므로 2.0.0으로 나갑니다. 1.1.x를 진행하면서 1.1.1에서 작업을 시작하고 2.0.0으로 릴리스합니다.

따라서주기가 반복됩니다.

각 구성 요소에 대해이 접근 방식은 조상의 추적 성을 제공합니다.

소스 (및 오브젝트) 개정 관리 시스템 내부에서 분기 및 태그 (현재 사용하는 용어가 무엇이든 레이블)를 사용하여 개발을 관리하십시오.

그런 다음 개정 관리에서 개발 분기 및 각 레이블 / 태그를 사용하여 각 구성 요소를 완전히 개별적으로 관리 할 수 ​​있습니다. 또는 모두 함께 묶을 수 있습니다.이 경우 작업 패키지별로 분기 할 수 있습니다. 그러나 각 구성 요소의 릴리스별로 레이블 / 태그를 지정하십시오 (필요한 경우 비트에 대한 비트뿐만 아니라 모든 항목에 레이블 / 태그 지정) 이 방법으로 당시의 모든 상태에 대한 스냅 샷을 얻을 수 있습니다.)

릴리스 프로세스에는 신중한 생각이 필요할 수 있습니다. 이 방법을 사용하면 몇 가지 수동 단계가 포함되며 바람직하지 않을 수 있습니다. 이는 빌드 시스템이 버전 번호를 최종 객체에 찌르는 방법에 따라 다릅니다. 버전 번호가 이름이 지정된 숫자 (예 : C 코드로 정의 된 #) 인 임베디드 코드의 경우, 수동으로 수행 할 수밖에 없습니다. 멋진 GUI를 갖춘 데스크탑 플랫폼은 종종 이것을 훨씬 더 친숙하게 만듭니다.

요약

저에게있어 소프트웨어 버전을 안정적으로 유지하는 유일한 방법은 버전 관리 시스템 의 해시 또는 변경 집합 식별자 를 사용하는 것 입니다.

전체 빌드 버전 번호가 유용 할 수 있지만 빌드 서버가 있거나 각 릴리스에 서명 한 경우에만 고유하게 보장됩니다. 우리 중 많은 사람들에게 이것은 단순히 실행 가능하지 않습니다.

프로젝트가 여러 버전 제어 저장소로 분할 된 경우 사용자 인터페이스가 각 종속 저장소를 쿼리하고 해시를 사용자에게 다시보고 할 수있는 메커니즘을 빌드해야합니다.

개인적인 경험의 예

우리는 (내부) 고객이 소프트웨어를 수정하고 다시 컴파일하는 데 문제가 있었던 이전 고용주의 프로젝트에서 수은 해시가 각 응용 프로그램과 라이브러리에 컴파일되는 프로세스를 도입했습니다. 소프트웨어가 시작될 때마다 모든 소프트웨어 구성 요소를 쿼리하여 개정 문자열이 작성되었습니다.

이 개정 문자열은 about 페이지로 이동할 때 표시되었으며 응용 프로그램이 시작될 때마다 로그 파일에 기록되었습니다. 형식은 다음과 같습니다.

Application name     (6a72e7c61f54)
    Library1         (b672a13a41e1)
        Library2     (9cc35769b23a)
    Library2         (9cc35769b23a)
    Library3         (4e9f56a0186a+)
        Library2     (9cc35769b23a)
    Library4         (2e3b08c4ac76)
        Library1     (b672a13a41e1)
            Library2 (9cc35769b23a)

이것으로부터 나는 그들이 Library3을 수정하고 저장소에 대한 변경 사항을 커밋하지 않았 음을 쉽게 알 수 있었으므로 제어되지 않는 코드를 사용하고 있습니다. 또한 해시를 현재 테스트 시스템과 비교하여 Library1을 이전 버전으로 되돌 렸음을 확인할 수 있습니다.

즉, 버그를보고 할 때마다 문제가 발생했을 때 항상 사용중인 코드를 정확하게 다시 작성하거나 최소한 설정을 재현 할 수 없다는 것을 알 수있었습니다.

내가 사용한 빌드 시스템, 내가 이것을 달성 한 방법, 내가 가진 문제, 사람들이 피하기 위해 제안한 것에 대한 자세한 내용은 스택 오버플로 질문을 살펴보십시오 .

참고 :이 시스템은 주어진 작업 디렉토리에 파일 혼합이 포함될 수있는 경우 주어진 해시가 작업 디렉토리에 동일한 파일 세트 (예 : git 및 mercurial)를 생성하는 개정 제어 시스템을 사용하는 경우에만 실제로 실행 가능합니다. 여러 개정판의 디렉토리 (예 : svn)를 사용하면 작업 디렉토리의 상태와 관련하여 모든 베팅이 해제 되며이 방법은 전혀 작동하지 않습니다.