공유 라이브러리의 분기 및 버전 관리 전략

이 게시물 은 관련 이있는 것처럼 보이지만 내 두뇌가 녹기 시작했습니다.

제 고용주는 소스 제어를 사용하기 시작했습니다. 주로 더 많은 개발자를 고용하기 전에 "집"은 주로 집에서 일하는 고독한 개발자의 하드 드라이브였습니다. 그가 작성한 모든 .NET 코드는 대량 으로 체크인되었으며 복제 된 (읽기 : 복사하여 붙여 넣기) 기능이 많이 있습니다. 현재 SCM 시스템은 영광스러운 백업입니다.

복제 된 코드 중 일부를 공유 라이브러리로 가져오고 싶습니다. 원본 리포지토리 만 남겨두고 아무 것도 깰 필요가 없습니다. 필요한 경우 기존 코드를 이동 및 / 또는 리팩터링 할 수 있습니다. 그래서 라이브러리를 포함한 새로운 코드에 대해서만 리포지토리를 설정했습니다.

내 문제는 과도한 프로세스로 인해 우리를 방해하지 않고 라이브러리 버전을 유지하는 것입니다. 더 많은 개발자가 매우 유사한 코드를 작성하고 관리하고 다른 개발자는 재구성 할 수는 있지만 더 일관성있는 접근 방식이 필요하다는 것을 인정했지만 솔루션이 생산성에 영향을 미치기 시작하면 제대로 내려갑니다.

강박 관념에 이상적인 솔루션은 라이브러리를 개별적으로 빌드하는 것입니다. 각 종속 프로젝트는 의도적으로 선택되고 호환되는 버전에 대해 빌드됩니다. 그렇게하면 어떤 클라이언트가 어떤 버전의 라이브러리를 가지고 있는지 정확하게 알 수 있으며, 버그를보다 안정적으로 재현하고, 제품과 라이브러리에 대한 독립적 인 릴리스 브랜치를 유지하고, 공유 코드를 변경할 때 서로의 프로젝트를 중단하지 않습니다.

이것은 특히 집에서 일하는 개발자에게 라이브러리 업데이트를 번거롭게 만듭니다. 적어도 처음에는 공통 비트를 함께 가져 오기 때문에 라이브러리가 빠르게 변경 될 것으로 기대합니다. 그것은 내가 완전히이 지나친하고있어 우리가 좋은 단지 가장 최근의 라이브러리 커밋에 대해 모든 것을 구축 할 거라고 확실히 가능하지만 나는 적어도이 수에하고자 준비 우리는 일부 구성 요소가 독립적으로 버전이되어야한다는 결정 날과 분산. 일부 라이브러리를 GAC에 설치해야한다는 사실 때문에 버전 관리가 특히 중요합니다.

그래서 내 질문은 : 내가 무엇을 놓치고 있습니까? 하나의 솔루션으로 수정 한 것처럼 느껴지고 이제 더 부드럽게 변경하는 변형을 찾으려고합니다. 이전에 이런 종류의 문제를 해결하기 위해 어떤 종류의 전략을 사용해 보셨습니까? 나는이 질문이 모든 곳에 있다는 것을 알고있다. 불확실성을 정리하고 명확하게하기 위해 최선을 다하겠습니다.

그리고 Mercurial을 사용하고 싶을만큼 이미 중앙 상업 SCM (Vault)에 돈을 투자했으며 전환은 옵션이 아닙니다. 게다가, 여기서 문제는 버전 제어 도구의 선택보다 더 깊다고 생각합니다.

당신의 이니셔티브를 칭찬합니다. 이를 구현할 때 조직에 많은 이점이 있어야합니다. 코드를 복사하지 않고 이동합니다. 사본이 있으면 호환되지 않는 변경이 발생하여 해결해야합니다.

라이브러리가 개발되고 안정화되면서 약간의 고통이있을 것입니다. 완료되면 혜택이 제공됩니다. 라이브러리에 대한 인터페이스는 기본적으로 계약 작업을 수행하는 프로젝트와의 계약입니다. 이전 인터페이스가 사용되는지 확인할 수 있으므로 이전 인터페이스를 제거 할 수 있다는 이점이 있습니다.

라이브러리가 안정화되는 동안 새 라이브러리를 얻는 것이 코드 업데이트 프로세스의 일부가되어야합니다. 라이브러리 변경 커밋을 예약 할 수 있습니다. 코드를 이동하면 변경 내용 충돌을 줄이는 데 도움이 될 수 있습니다.

라이브러리는 별도의 프로젝트로 처리하고 가능한 빨리 안정화해야합니다. 일단 안정화되면 (특히 인터페이스) 변경 사항을 다른 프로젝트와 통합하는 것이 더 쉬워야합니다. 새 라이브러리는 이전 코드와 함께 작동해야합니다. 자체 릴리스 ID로 안정적인 라이브러리 릴리스에 태그를 지정하십시오. 라이브러리를 타사 라이브러리처럼 취급하십시오.

프로젝트간에 공유되는 코드는 자체 프로젝트로 취급되어야합니다. 타사 라이브러리와 동일하게 취급해야합니다. 다른 방법은 없습니다.

그룹에서 공유 코드 전략을 채택 할 수없는 경우 회사에서 공식적으로 사용하는 SCM이 아니더라도 Mercurial 또는 GIT와 같은 최신 소스 코드 관리 도구를 사용하여 자신을 채택 할 수 있습니다. 약간의주의를 기울이면 두 SCM은 다른 하나의 내부 파일을 무시하도록 지시함으로써 동일한 작업 디렉토리를 사용할 수 있습니다. SCM 하나를 사용하여 일상을 처리하고 회사 하나를 통합해야합니다.

여하튼, 다른 프로젝트가 공유 코드를 수정하여 작업 디렉토리를 업데이트 할시기를 담당해야합니다. 이러한 문제는 발생할 수있는 비 호환성을 처리 할 준비가되었을 때만 발생해야합니다. 그렇지 않으면 할 수있는 것 이상으로 작업이 불안정해질 수 있습니다.

그것들을 별도의 "모듈"프로젝트로 나눌 수 있다면, 나는 그 접근법을 취할 것입니다. 걱정해야 할 것은 코드 커플 링입니다. 우려 사항 을 구분 하여 분리 하여 작성 하는 것이 좋습니다.

몇 가지 장점 :

1. 각 모듈의 간단한 디버깅
2. 빠른 빌드주기 (변경되지 않은 라이브러리 재 구축 없음)
3. 무언가가 작동하면 해당 모듈 외부의 다른 영역 (100 %가 아니라 기회를 줄임)을 변경하여 중단 할 가능성이 줄어 듭니다.
4. 상호 의존적 인 혼란이 크지 않은 작업 할당을보다 쉽게 ​​분류 할 수 있습니다.
5. 하나의 라이브러리를 수정하면 더 작은 조각을 더 빠르게 배포 할 수 있습니다 (.dll / .so 파일이있는 큰 이유).

이 부분에 대해 한 가지 질문이 있습니다.

"저의 강박 관념에 이상적인 솔루션은 라이브러리를 개별적으로 빌드하는 것입니다. 각 종속 프로젝트는 의도적으로 선택된 호환 가능한 버전에 대해 빌드됩니다."

전체 프로젝트를 정적으로 연결합니까? 그렇다면 다음으로 이어질 것입니다. 6. 불필요한 코드 부풀림 감소.

일부 제외 어 :

1. 프로젝트가 작 으면 필요하지 않은 곳에 복잡성을 추가하는 것입니다.
2. 많은 모듈을 분기하면 실제로 큰 프로젝트의 유지 관리 문제가 될 수 있습니다. "Vault"를 모르기 때문에 분기 작업이 좋은지 확실하지 않습니다.

지금은 하나의 코드베이스가 한 번에 하나의 대상으로 빌드 된 것처럼 보입니다. 아마도 5 명 이상의 개발자가있을 것입니다. 라이브러리를 너무 많이 분리하는 유틸리티는 실제로 보지 못합니다. 코드-> 컴파일-> 실행에서 코드-> 컴파일-> DLL 복사-> 컴파일-> 실행 ... ick으로 워크 플로우를 변경하십시오.

일부 회사 (Google 및 Amazon)에는 개발을위한 충분한 인프라가있어 별도의 많은 라이브러리를 별도로 구축하는 것이 쉽지 않습니다. 고통없이 만드는 인프라에는 SCM에있는 라이브러리 버전을 지정하는 방법, SCM에있는 종속성 버전을 지정하는 방법,이를 이해하고 모든 것을 올바르게 컴파일 할 수있는 빌드 서버가 포함됩니다. , 빌드 서버 및 로컬 작업 공간에서 적절한 빌드 아티팩트를 가져 오는 방법입니다. 나는 당신이 그것을 의심합니다.

해당 인프라가 없으면 다음 중 하나가 적용될 때 프로젝트를 분리합니다.

• 이 라이브러리에 따라 여러 제품 또는 고유 한 응용 프로그램이 있습니다
• 한 번에 며칠 동안이 라이브러리에서 독점적으로 작업
• 라이브러리의 기능은 비즈니스 관련 요소 (예 : 플랫폼 별 API 래퍼)와는 크게 다릅니다.
• 결합 된 프로젝트의 빌드 시간이 너무 커짐

많은 프로젝트가 있고 일부에는 전용 개발자와 독립적 인 릴리스주기가있을 때 해당 인프라를 구축하는 것이 걱정됩니다.

당신이 할 수 와 해야 지금하는 신뢰성, 반복 빌드에 대한 빌드 서버를 설정하고 당신이 특정 실행 파일에서 소스 버전을 찾을 수 있는지 확인한다. .NET을 사용하고있는 것 같습니다. 버전 번호를 포함하여 버전 문자열을 삽입하도록 CruiseControl.NET을 설정하는 것은 매우 간단합니다.

빌드 서버가 있으면 라이브러리를 분리하면 Vault에서 라이브러리를 이동하고 CC.NET에 다른 대상을 추가하고 결과 DLL을 기본 프로젝트의 라이브러리 폴더에 복사하여 커밋하는 것이 중요합니다. 일상적인 개발보다 SCM 측면에서 더 쉽습니다.

Mercurial에는 하위 리포지토리라는 기능이 있습니다. 최근에 Kiln 에서이 블로그 를 읽고 작동 방식을 설명했습니다.

기본적으로 프로젝트를 라이브러리 리포지토리의 특정 버전에 연결합니다. 종속 프로젝트를 중단하지 않고 원하는만큼 라이브러리를 업데이트 할 수 있습니다. 준비가되면 라이브러리의 새로운 기능을 프로젝트로 가져 와서 파손을 처리 할 수 ​​있습니다. 다른 프로젝트는 라이브러리의 다른 개정판에 링크 될 수 있으므로 모두 동기화되어 동일한 라이브러리 개정판을 사용할 필요는 없습니다.

Vault의 기능이 비슷할 수 있습니다.

SC의 각 모듈에 메타 데이터 파일을 추가하여 종속 된 다른 모든 모듈의 이름을 나타냅니다. 제품에는 제품에 필요한 각 종속 모듈의 버전을 나타내는 두 번째 메타 데이터 파일이 있습니다. 이 외에도 메타 데이터 파일을 분석하고 필요한 모든 모듈을 체크 아웃하고 IDE 용 프로젝트를 생성하는 도구가 있습니다.

이를 통해 빌드를 항상 재현 할 수 있으며 올바른 헤더 파일을 항상 컴포넌트간에 공유 할 수 있습니다. 요구가 발전함에 따라 다른 복잡성이 계층화 될 수있다. SC의 모든 독립 모듈에서 변경된 소스 파일, 체크인 주석, 버전 주석, 작성자를 지정하여 제품의 두 빌드 간의 차이점에 대한 보고서를 생성 할 수있는 도구가 있습니다. 우리는 코드베이스에서 엄청난 양의 재사용을 얻습니다.