설치 프로젝트를 빌드해야 할 때 Subversion에서 유지 관리/버그 수정 분기를 관리하는 방법은 무엇입니까?

Question

우리는 VB6로 작성된 관련 제품군을 일부 C# 및 VB.NET 프로젝트와 함께 가지고 있으며 모든 소스는 단일 Subversion 저장소에 보관됩니다.

우리는 Subversion에서 분기를 사용하지 않았지만 (현재 태그 릴리스를하고 있지만) 트렁크에서 모든 개발을 수행하여 트렁크가 충분히 안정적 일 때 새 릴리스를 만듭니다. 이로 인해 새 버전을 출시 할 때 슬픔의 종식이 발생하지 않으며 문제가 발견되고 이미 트렁크의 새로운 기능이나 주요 변경 사항에 대한 작업을 시작했습니다.

1. 서둘러, 트렁크를 안정 문제를 해결하고 출시 : 과거에는, 우리는 문제의 심각성 방법 안정에 따라 두 가지 방법 중 하나로이 문제를 해결 것이라고 우리는 트렁크라고 생각 HEAD 개정판을 기반으로하는 유지 관리 업데이트이지만 버그를 수정했지만 출시 된 기능이나 버그가있는 트렁크로 인해 새로운 문제가 발생한 릴리스의 부작용이있었습니다.

2. 고객은 다음 공식 릴리스 (보통 몇 달간)가 오기까지 기다리십시오.

이 상황을보다 잘 처리하기 위해 정책을 변경하고자합니다. 공식 릴리스에 태그를 추가 할 때마다 Subversion에서 "유지 관리 지점"을 만드는 것을 고려하고있었습니다. 그런 다음 트렁크에서 새로운 개발이 계속되고 트렁크의 특정 수정 사항을 유지 관리 분기에 주기적으로 병합하고 충분한 수정 사항이 누적되면 유지 보수 릴리스를 생성 할 수 있으며 다음 주요 업데이트를 병렬로 계속 진행합니다. 나는 우리가 더 안정적인 트렁크를 가질 수 있고 대신 새로운 업데이트를위한 브랜치를 만들 수 있음을 알고 있지만, 트렁크의 현재 개발을 유지하는 것이 나에게 더 단순 해 보인다.

주요 문제점은 릴리즈 태그에서 소스 코드를 쉽게 분기하고 해당 릴리즈의 바이너리를 얻기 위해 다시 컴파일 할 수 있지만 설치 및 설치 프로젝트를 처리하는 방법이 확실하지 않다는 것입니다. 우리는 QSetup을 사용하여 모든 설치 프로그램을 만들고 현재는 설치 프로젝트를 수정해야 할 때 현재 위치의 프로젝트 파일 만 편집합니다 (모든 설치 프로젝트와 컴파일하지 않은 종속성은 모두 저장됩니다). 별도의 서버에 설치해야하며 해당 시스템에서만 항상 설치 프로젝트를 컴파일해야합니다. 그러나 코드가 변경됨에 따라 파일을 설치에 추가하거나 제거 할 수 있기 때문에 오늘날의 설치 프로젝트가 어제의 소스 코드와 함께 작동한다는 보장이 없습니다.

나는이 문제를 해결하기 위해 모든 QSetup 프로젝트를 Subversion에 넣으려고했지만이 접근법에 몇 가지 문제점이 있습니다.

가능한 한 자동화 된 설치 프로그램을 만들고 싶습니다. 최소한 (Subversion에서 코드를 가져 오는) 원하는 빌드를 빌드 할 수있는 별도의 빌드 시스템이 필요합니다. Subversion에서 해당 릴리스에 대한 설치 프로젝트를 실행 한 다음 설치 프로그램을 다시 컴파일 한 다음 QA 테스트 및 최종 릴리스를 위해 네트워크의 다른 위치로 설치를 복사하십시오.

그러나 누군가가 설치 프로젝트를 변경해야 할 때 (트렁크가 필요로하는 새로운 종속성을 추가하거나 다른 변경 사항을 적용해야하는 경우) 문제가 있습니다. 소스 파일과 같이 처리하고 편집하기 위해 자신의 컴퓨터에서 체크 아웃하면 빌드 머신에 추가해야하는 파일을 먼저 복사하지 않으면 프로젝트에 파일을 추가 할 수 없습니다 (따라서 다른 개발자가 사용 가능), 빌드 시스템의 다른 모든 종속성을 자신의 시스템에 복사하고 폴더 구조 이 정확히과 일치하는지 확인하십시오. 여기서 문제는 QSetup이 설치 프로젝트에 추가 된 모든 파일에 절대 경로를 사용한다는 것입니다.그러나 이는 개발 컴퓨터에 설치 종속성을 많이 설치하는 것을 의미합니다. 이는 지저분 해 보입니다 (누군가가 실수로 설치 프로젝트를 컴퓨터에서 실행하는 경우 개발 환경을 불안정하게 만들 수 있습니다).

또한 타사 종속성을 어떻게 관리합니까? 예를 들어 현재 유지 관리 지점에서 MSXML 3.0을 사용하고 트렁크에 MSXML 4.0이 필요한 경우 빌드 컴퓨터의 MSXML 라이브러리를 이미 최신 버전으로 교체 한 경우 되돌릴 수 없으며 유지 관리 릴리스를 만들 수 없습니다 (두 버전 동일한 파일 이름을 가짐). 내가 생각할 수있는 유일한 해결책은 Subversion에 모든 타사 종속성을 소스 코드와 함께 넣거나 다른 라이브러리 버전을 별도의 폴더에 넣는 것입니다 (예 : C:\Setup\Dependencies\MSXML\v3.0 및 C:\Setup\Dependencies\MSXML\v4.0). 편도가 다른 편보다 "더 낫거나"공통적입니까?

이 상황을 처리하는 모범 사례가 있습니까? 기본적으로 우리가 v2.0 소프트웨어를 릴리스하면 v2.0.1에서 v2.0.1, v2.0.2 및 v.2.0.3을 릴리스 할 수 있지만 전체 설치/설치 프로젝트 및 설정 의존성 문제로 인해 일반적인 "Subversion에서 분기를 만들고 필요에 따라 다시 컴파일"대답보다 복잡해집니다.

Answer 1

필자의 입장에서 핵심은 절대 경로와 "잘 알려진"네트워크 위치를 제거하는 것입니다. 그들을 가지지 마라. 이제까지.

내가 일하는 곳에서는 모든 설정 파일, 프로젝트, 종속성 (모두 포함)을 기본 코드가있는 동일한 코드 저장소에 보관합니다. 이렇게하면 분기를 만들 때 모든 설정 작업이 함께 분기되고 분기 시점과 완전히 동일한 형식으로 보존됩니다.

여기에서 볼 수있는 유일한 문제는 QSetup에서 절대 경로를 사용한다는 것입니다. 이것이 완전히 우스꽝 스럽지만, 나는 당신이 아마도 더 전문적인 것으로 전환하는 것을 고려하지 않을 것임을 이해한다. (우리는 NSIS를 사용한다.)

그러나 비교적 간단한 해결책이 적용될 수 있습니다. 여기서 QSetup은 프로젝트를 텍스트, 인간 이해 가능 형식으로 유지한다고 가정합니다 (그렇지 않으면 이해할 수 없을 정도로 우습다). 따라서 QSetup 프로젝트 파일의 사본을 만들고 모든 경로를 처음에 마커와 함께 상대 경로로 바꿀 수 있습니다. 예 : %ROOT%\Dependencies\SomeDep.dll

그런 다음 빌드 스크립트 QSetup을 호출하기 바로 전에 간단한 유틸리티를 실행하십시오. %ROOT%을 리파지토리가 체크 아웃되는 적절한 경로로 대체하여 "실제"프로젝트 파일을 생성합니다.

이 기능을 구현 한 후에는 지정된 빌드 머신이나 개발 시스템 또는 다른 머신에서 빌드를 만들 수 있습니다.