홀수 회사 릴리스주기 : 분산 소스 제어?

이 긴 글에 대해 죄송하지만 그만한 가치가 있다고 생각합니다.

나는 방금 작업 한 다른 장소와는 약간 다르게 작동하는 작은 .NET 상점으로 시작했습니다. 이전의 다른 직책과 달리 여기에 작성된 소프트웨어는 여러 고객을 대상으로하며 모든 고객이 동시에 최신 소프트웨어 릴리스를받는 것은 아닙니다. 따라서 "현재 프로덕션 버전"이 없습니다. 고객은 업데이트를 받으면 마지막 업데이트 이후 소프트웨어에 추가 된 모든 기능을 얻습니다. 소프트웨어는 고도로 구성 가능하며 기능을 켜고 끌 수 있습니다. "기능 토글"이라고합니다. 릴리스주기는 여기서 일정하지 않습니다. 기능이 완료되면 소프트웨어가 관련 고객에게 배포됩니다.

작년에만 팀이 Visual Source Safe에서 Team Foundation Server로 이동했습니다. 문제는 여전히 VFS처럼 TFS를 사용하고 단일 코드 분기에 Checkout 잠금을 적용한다는 것입니다. 버그 수정이 현장에 나올 때마다 (단일 고객이라도) TFS에 무엇이든지 빌드하고 버그가 수정되었는지 테스트하고 고객에게 배포합니다! (제약 및 의료 기기 소프트웨어 배경에서 나 자신은 믿기지 않습니다!). 결과적으로 절반의 구운 개발자 코드는 테스트조차받지 않고 생산에 투입됩니다. 버그는 항상 릴리스 빌드로 빠져 나가지 만, 버그가있는 기능을 사용하지 않으면 빌드를 방금받은 고객이이 버그를 보지 못할 수 있습니다. 갑자기 큰 고객들과 더 작은 고객들이 등장합니다.

버그가 있거나 완료되지 않은 코드의 배포를 없애고 팀 릴리스의 다소 비동기적인 특성을 희생시키지 않기 위해 소스 제어 옵션을 살펴 보라는 요청을 받았습니다. 나는 경력에 VSS, TFS, SVN 및 Bazaar를 사용했지만 TFS는 내 경험의 대부분이었습니다.

이전에 내가 작업 한 대부분의 팀은 한 달 동안 개발자가 Dev에서 직접 작업 한 다음 변경 사항이 Test와 Prod로 병합되거나 또는 "완료되었을 때"로 승격되는 Dev-Test-Prod의 2 개 또는 3 개의 지점 솔루션을 사용합니다. 고정 사이클. 크루즈 컨트롤 또는 팀 빌드를 사용하여 자동화 된 빌드가 사용되었습니다. 나의 이전 작업에서 Bazaar는 SVN 위에 앉아 사용되었습니다. 개발자는 자신의 작은 기능 지점에서 일한 다음 SVN으로 변경 사항을 푸시했습니다 (TeamCity에 연결됨). 변경 사항을 쉽게 분리하여 다른 사람들과 공유 할 수 있다는 점에서 좋았습니다.

이 두 가지 모델에는 코드가 푸시되는 중앙 개발 및 생산 (및 때로는 테스트) 분기가 있었고 (라벨을 사용하여 릴리스가 나온 제품을 빌드하는 데 표시했습니다 ... 버그 수정을 위해 분기로 만들었습니다. 릴리스하고 다시 dev로 병합). 그러나 이것은 여기서 일하는 방식에 실제로 적합하지 않습니다. 다양한 기능이 출시 될 때까지의 순서는 없으며 완료되면 푸시됩니다.

이 요구 사항을 통해 "지속적인 통합"접근 방식이 나옵니다. 지속적인 통합으로 새로운 기능을 구현하려면 dev-test-prod를 통해 기능을 푸시해야하며 개발에서 완료되지 않은 작업을 캡처합니다.

나는 이것을 극복하기 위해 우리는 dev-test-prod 브랜치가없는 무거운 피처 브랜치 모델을 내려 가야한다고 생각합니다. 소스는 개발 작업이 완료되면 잠금, 테스트, 고정, 잠그는 일련의 피처 브랜치로 존재해야합니다. 테스트하고 릴리스했습니다. 다른 피처 브랜치는 다른 브랜치가 필요 / 원할 때 다른 브랜치의 변경 사항을 가져올 수 있으므로 결국 모든 변경 사항이 다른 모든 사람에게 흡수됩니다. 이것은 내가 마지막 직장에서 경험 한 것에서 순수한 Bazaar 모델과 매우 잘 어울립니다.

유연성이있는 것처럼 어딘가에 개발 트렁크 또는 제품 분기가없는 것은 이상한 것처럼 보이며 분기를 다시 통합하지 않아도 분기 또는 다른 지점과 개발자가 불평하지 않는 작은 늦은 변경이 걱정됩니다. 재난 병합 ...

이것에 대한 사람들의 생각은 무엇입니까?

두 번째 최종 질문 : 분산 소스 제어의 정확한 정의에 대해 다소 혼란 스럽습니다. 일부 사람들은 TFS 또는 SVN과 같은 중앙 저장소가없는 것에 대해 제안하는 것 같습니다. 그리고 TFS는 완벽하게 작동하는 오프라인 모드를 가지고 있습니다) 그리고 다른 사람들은 그것이 기능 브랜치와 부모-자식 관계가없는 브랜치 간 병합의 용이성에 관한 것이라고 말합니다 (TFS는 기본이없는 병합을 가지고 있습니다!). 아마도 이것은 두 번째 질문입니다!

DVCS 란 무엇입니까?

분산 저장소의 모든 복제가 모든 정보를 가지고 DVCS의 수단 적 건드리지 않고, 업데이트, 분기, 병합을 커밋 또는 저장소의 모든 버전을 검색하는 데 필요한 서버를 . 오프라인에서 할 수있는 유일한 것은 svn실제로 파일을 편집svn 하는 것입니다. grepping과 같은 간단한 작업을 포함하여 거의 모든 명령에 대한 서버 액세스가 필요 svn log하므로 실제로 90 %보다 0 %에 가깝습니다!

모든 권한을 중앙 저장소 는 워크 플로우 DVCS에 설정할 수 있습니다 즉 또 다른 클론 당신이 유일한 시간 이 필요 그것은 다른 사람들이 볼 수 있도록 자신의 변경을 누르면 다른 사람들 업데이트를 아래로 당기거나 할 때입니다와 상호 작용 다른 모든 작업은 오프라인으로 수행 할 수 있습니다.

어떤 분기 모델이 적합합니까?

나는 당신이 지금 처한 상황에 처해있었습니다. 그러한 시스템은 정말 고통 스러울 수 있지만 당신은 그들이 이렇게 된 실용적인 이유를 이해하고 그것들이 구속을 넘어서는 것이 아님을 깨달아야합니다 . 이러한 종류의 복잡성을 관리 하는 데 도움이 되는 많은 도구가 개발되었습니다 .

우선, 당신이 무엇을하든 사람들에게 성공적인 자식 분기 모델을 보여주지 마십시오. 혼동하고 끌 것입니다. 대신 기존 워크 플로우 를 반영 하면서 기존 워크 플로우 의 문제점을 해결하는 고유 한 모델을 개발하십시오 .

고려할 수있는 일부 리소스에는 git 하위 모듈 과 같은 것들이 포함되어 있는데,이를 통해 서로 다른 고객 릴리스에서 서로 다른 고객 구성, 응용 프로그램 모듈 및 라이브러리 조합을 지정할 수 있습니다. 다른 옵션은 패치 관리 시스템 을 사용하여 고객 / 제품 별 패치 대기열을 적용하는 것입니다.

이 두 가지 옵션 모두 현재 워크 플로보다 훨씬 뛰어난 유연성, 투명성 및 안전성을 제공하며보다 복잡한 지점 전용 전략보다 사용하기가 더 쉬울 수 있습니다. 나는 당신의 상황에있을 때이 도구에 액세스 할 수 있기를 바랍니다.

이러한 옵션에 대한 자세한 내용 은 모듈 식 시스템 에서 버전 제어를 사용 하는 전략에 대한 내 대답 , Git 리포지토리에서 Subversion 리포지토리를 사용하는 방법을 참조하십시오. 및 응용 프로그램의 소스 / 버전 관리는 여러 회사에서 사용 .

궁극적으로 이것은 다른 팀과 함께 개발해야 할 부분입니다. 이미 가지고있는 것보다 더 나은 것을 제안하고 동료 개발자를 인수 할 수있는 비전을 가지고 있다면 훨씬 더 쉬운 시간을 가질 수 있습니다.

가장 중요한 것은 동료들 에게 당신이 제안한 것이 그들의 삶을 더 편하게 만드는 방법 을 보여주는 것입니다 . 일단 그들이 확신하면 경영진이 TFS에 대한 투자 를 포기 하고 작업 방법에 더 적합한 모델을 사용하게 될 가능성이 훨씬 높아집니다 .

첫째, DVCS는 현재 가지고있는 문제에 대한 청각입니다. 사용중인 버전 제어 도구는 해결해야 할 문제의 근본이 아닙니다. DVFS 솔루션에는 TFS보다 "더 나은"측면이 있지만이 시점에서 수정해야 할 사항은 없을 수 있습니다.

조직에 적합한 실행 가능한 분기 구조가 필요하다는 것을 확인했습니다. 기능이 완료되면 트렁크로 다시 병합되어 닫히는 트렁크가 여전히 있다고 생각합니다. 공통 종속성을 구현하는 방법에 대한 좋은 생각이 있습니다.

또한 지속적인 통합 작업을 수행해야합니다 (각 지점마다 자동화 된 빌드를 구축하지 않아도 해당 지점을 구축 할 수 있고 관련 테스트를 통과 할 수 있다는 확신을 가지지 않아도 됨). 커밋 (또는 적어도 "푸시")이 빌드를 트리거하지 않는 곳은 불편합니다.

또한 모든 수준에서 자동화 된 테스트를 시작해야하지만 특히 새로운 버그가 발생할 가능성을 줄이려면 단위 테스트 및 통합 테스트를 시작해야합니다. 이 마지막은 거대하고 여전히 어려움을 겪고 있지만 일단 당신이 일단 물건을 만들 수 있다는 것이 가장 가치가 있다는 것이 분명합니다.

배포 패키지가 빌드 서버에서 제공되고 배포가 가능한 한 자동화되었는지 확인하기 위해 이것을 결합해야합니다. 최소한의 노력으로 최소한의 스트레스로 빌드 서버 아티팩트에서 실제 배포 된 코드로 이동할 수 있어야합니다.

흠, 나는 잘 정돈 된 이슈 트래킹 설정이 있다고 가정했다. 이상적으로는 라이브 응용 프로그램이 오류를이 시스템 (또는 심사의 경우)에 자동으로 피드백하기를 원합니다.

마지막으로, 한 번에 모든 문제를 해결하려고 시도하지 마십시오. 빌드하고 테스트하면 내가 먼저 집중해야 할 곳인 것 같습니다.

두 번째 질문은 더 쉽고 짧으므로 시작하겠습니다.

DVCS는 "권한있는"코드 소스 (사용시 "동의"제외) 및 데이터의 P2P 교환이 추가 계층 (개인, 비정규 정의)없이 가능한 시스템입니다.

주제 첫 번째 질문

"어떻게 관리되고 예측 가능한 코드"를 얻기 위해 회사는 워크 플로를 재구성하고 스타일에 대해 재고해야합니다. TFS에 대해서는 말할 수 없습니다 (개인의 의견과 느낌을 제외하고는 버전 관리 부분의 약한 시스템입니다 /베이스리스 병합은 악의적입니다). 그러나 귀하의 상황에서 VCS에 대해서는 ( "제품"은 독립적 인 "모듈"로 설정됩니다. 각 "고객"이 다른 "제품"을 얻습니다-이 가정이 맞습니까?) 모듈을 개별 브랜치로 분할하는 것을 선호하고, 제품을 "슈퍼 모듈"(또한 브랜치?)로 지정합니다. 각 모듈은 모듈의 특정 개정판에 연결되어 있습니다. branch, module-development는 branch-per-task 패러다임을 사용합니다 (그리고 module-branch는 mergeset으로 만 구성됩니다).

이런 식으로 항상 "제품"을 구성하는 "컬렉션"(즉, 모듈 세트 및 해당 개정판)이 CI ( 완료 및 병합 된 작업 브랜치에 대해), 단위 테스트 및 빌드 를 수행 할 가능성이 있음을 항상 알 수 있습니다.

광고 주요 질문 : 당신이 말하는 것은 git 성공적인 분기 모델 (그리고 그것을 지원하기위한 도우미 도구 git flow )에 관한 것입니다. 항상 배포 가능한 상태 인 마스터 분기가 있고 모든 기능 분기에서 작업합니다.

동일한 기본 원칙에서 파생 된 git 자체에서 사용하는 프로세스를 사용할 수도 있습니다. git-core 개발에서 모든 작업은 기능 분기에서 발생합니다. 기능 분기는 통합 자에게 제출되며, 통합자는 스크립트를 실행하여 모든 기능을 병합하여 이름이 지정된 분기 pu(제안 된 업데이트) 를 작성합니다 . 다양한 사람들이이 지점을 가지고 그것을 테스트하기 위해 협력합니다.

통합 기 대신 빌드 시작시 지속적인 통합 서버가이 병합을 수행하도록 할 수 있습니다. 이렇게하면 팀의 누군가가 기능 저장소로 중앙 저장소에 변경 사항을 푸시 할 때마다 (어쩌면 일부 명명 규칙을 사용하여 선택해야하는 분기를 알려줍니다).

자식에 기능에 진행 이상의 지점 next, master또는 maint따라 어떤에가 (MAINT는 전류 - 준비 자료와 그 이후의 일에 대한 다음의 현재 릴리스, 마스터 버그를 수정입니다)에서 목표로 출시,하지만 당신은 많은이 없습니다.

기능은 pu(git 관리자의 용어에서 "요리")에 있지만, 되감기 고 pu매번 브랜치를 버리고 다시 생성하기 때문에 검토하기가 쉽지만 다른 작업을 수행하기에는 부적합합니다. 기능 분기가 메인 라인 중 하나로 병합되면 되감기를 위해 닫히고 새 커밋으로 추가 수정이 수행됩니다.

나는 개인적으로 git가장 좋습니다. 더 유기적으로 자라기 때문에 처음에는 배우기가 조금 어렵지만 결국에는 가장 유연 해 보입니다. 그러나 git, mercurial 및 bazaar의 세 가지 분산 시스템 중 하나가 잘 작동합니다 (예를 들어, mercurial은 git 저장소로 가져오고 밀어 넣을 수 있으며 시장도 가능합니다).

두 번째 질문 : 저는 일반적으로 "분산"이란 물체를 움직일 수 있고 물체의 정체성을 유지한다는 의미입니다. 분산 버전 제어는 정확히 다음과 같습니다. 리포지토리를 복제하고 동일한 커밋을 포함하고 동일한 커밋을 포함합니다. 분기의 용이성과 연결 끊김 작업은 커밋 이동 원리와이를 허용하는 직접 그래프 레이아웃을 따르는 주요 사용자 수준 기능입니다.

불행히도, 코드 버그에 대한 알려진 해결책은 없습니다 :)

따라서 완성되지 않은 체크인이 기본 릴리스에서 잡히지 않도록하려고합니다. 이에 대한 유일한 대답은 각 개발자의 브랜치 워크 병합입니다. Clearcase를 사용하는 이전 회사 에서이 작업을 수행했지만 12 명의 Clearcase 관리자가 있어야했지만 꽤 잘 작동했습니다.

이제 각 고객이 현재 보유하고있는 제품 버전에 대해 버그 수정을 수행한다고 가정합니다. 따라서 버전 A에서 버전 Z까지 버그 수정을 가져 오는 병합 문제가 있습니다. 그러나 각 배송 버전에 대한 지점이 있어야합니다. 이 문제를 해결하는 가장 좋은 방법은 기능 분기를 최신 버전으로 만 유지하고 고객이 업그레이드하여 새 기능을 얻도록하는 동시에 릴리스 분기에서 직접 버그 수정을 수행하여 다른 모든 릴리스 분기로 병합하는 것입니다. 완료되면.

너무 좋지는 않지만 놀랍도록 잘 작동 할 수 있습니다. 코드를 체계적으로 정리하고 멋지게 분리하십시오. 다른 개발자들도 쉽게 이해할 수 있습니다. "코드"에 직접 작은 버그 수정이 있습니다. 몇 줄 이상은 전용 브랜치에서 수행되며 완료하는 데 오래 걸릴 수 있습니다. (병합 문제를 정렬하고 2 명의 개발자가 동시에 2 개의 기능에 대해 작업하면 괜찮습니다!)

잠시 후 버그를 수정 한 다음 병합하는 릴리스 브랜치에 기능 브랜치를 도입 할 수 있지만 IMHO는 일반적으로 필요 이상으로 많은 노력을 기울입니다. 그래도 이전 릴리스에 기능을 추가해야하는 경우이 릴리스의 접근 방식을 따라야합니다. 릴리스 분기에서 분기 한 다음 코드를 해당 릴리스로 다시 병합하고 변경 사항을 이후 릴리스로 병합하십시오. 여러 버전을 반복적으로 테스트해야하기 때문에 릴리스가 크게 지연되고 테스트 팀은 새로운 코드를 시작하기 전에 많은 병합을 수행해야하기 때문에 테스트 팀이 매우 불행하게 만듭니다. 이것은 주로 우리가 가진 일의 양이 항상 최대한 빨리 완료되어야하기 때문에 발생합니다).

DVCS :

기본적으로 DVCS는 모든 사람이 자신의 서버 저장소 사본을 가지고있는 곳입니다. 이 기능에는 몇 가지 장점이 있지만 (특히 통신이 제한적인 분산 팀에서) 몇 가지 단점이 있으므로 DVCS로 전환하기 전에 확인하십시오. Windows 상점이라면 Mercurial이 최고의 DVCS임을 알게 될 것입니다.