소규모 팀에 버전 관리 분기 정책 소개

저는 최근에 회사에서 시작한 계약자입니다.

팀은 2 명의 중급 개발자로 구성된 3 명의 개발자이며 곧 같은 레벨의 다른 개발자와 나 자신 (6 년 xp)입니다. 기존 개발자 모두에게 대학 / 대학에서 첫 번째 직업이되었으며, 이전에는 자신의 업무를 감독하는 선임 개발자가 없었습니다.

명시적인 버전 관리 정책이 없습니다. 개발자는 트렁크에서 모든 개발을 수행 한 다음 개발 시스템에서 직접 프로덕션 환경에 배포합니다. 기존 팀은 분기에 익숙하지 않습니다.

이 모든 것을 바꾸고 CI, TDD 테스트 / 준비 / 프로덕션 서버 등을 버전 관리 정책과 함께 소개하고 있습니다.

소스 제어 시스템은 TFS이며, 이전에는 사용해 본 적이 없습니다. 하나의 거대한 저장소로 구성되어 있습니다.

나는 그들을 위해 몇 가지 조언을 작성했지만 팀의 경험을 염두에두고 추가 / 수정해야 할 것이 있습니까?

버전 관리 정책

트렁크에서 개발 완료

변경 사항이 일주일 이상 걸리는 것으로 예상되면 분기에서 분기를 수행해야합니다. 트렁크에서 분기로 정기적으로 병합하여 두 가지가 동기화되지 않도록합니다.

생산 코드를 위해 생성 된 릴리스 지점. 해당 분기에는 안정적인 코드 만 포함되어야합니다. 스프린트 당 한 번 트렁크에서 업데이트되는 릴리스 분기를 하나 또는 매주마다 별도의 릴리스 분기를 만들 수 있습니다.

프로덕션 코드에 영향을 미치는 긴급한 버그 수정이 필요한 경우 릴리스 분기에서 수정되어 트렁크로 다시 병합됩니다.

하나의 릴리스 브랜치 전략을 채택하면 스프린트 당 스프린트 끝을 향해 스프린트 당 한 번 트렁크가 릴리스 브랜치로 병합됩니다.

릴리스 당 별도 지점을 채택하면 트렁크가 릴리스 지점으로 병합되지 않습니다.

일부 시나리오에서는 분기가 너무 많이 분기 된 경우 다른 분기에서 버그를 두 번 수정해야 할 수 있습니다. 짧은 스프린트를한다면 너무 자주 발생해서는 안됩니다.

세 대의 서버를 보유 할 계획입니다. 항상 리포지토리에서 최신 코드를 실행하는 테스트 환경. 릴리스 후보 코드 및 UAT 목적을 준비 / 테스트하기위한 최신 릴리스 후보 및 프로덕션 환경을 실행하는 준비 환경.

내가 이것을 계획하는 이유는 지금까지 클라이언트가 내부 소프트웨어 만 수행했기 때문입니다. 최신 프로젝트는 유명 미디어 고객을위한 것이며 내 생각은 팀이 현재 수행하는 것보다 더 전문적인 개발 모델을 채택해야한다는 것입니다.

예를 들어, 현재 사용자는 버그 보고서로 팀에 전화를 걸 수 있습니다. 개발자는 버그를 찾아 수정하고 자체 머신에서 빠른 시선 테스트를 한 다음 바로 프로덕션 환경에 배포합니다. 자동화 된 테스트 또는 다른 것은 없습니다.

뒤늦게 살펴보면 기능 분기가 너무 멀다고 생각하고 제거하겠습니다.

따라서 본질적으로 a) 분기가 전혀 없음 b) 릴리스 분기 및 트렁크 c) 릴리스 및 트렁크 당 릴리스 분기

나는 후자를 향해 기울고 있었다. 내 초기 생각은 릴리스 후보와 릴리스가 동시에 별도의 서버 (UAT / 생산)에 있어야한다고 생각하지만 실제로 트렁크는 언제든지 특정 시점에 릴리스 후보이므로 릴리스는 미치도록 기울고있다. 내 생각은 이해 관계자가 개발 코드를 보지 못하게하려면 별도의 릴리스 후보 분기가 필요하지만 YAGNI와 그 모든 것이 필요하다는 것입니다.

3-4 명으로 구성된 팀의 경우 WAY가 너무 많은 지점을 제안하고 있습니다.

생성하는 모든 브랜치는 비용과 함께 발생하는 추가 오버 헤드입니다 (병합 시간, 위치 등 추적). 지점을 가지면 얻을 수있는 이점이 비용을 능가하는지 확인해야합니다.

브랜치에 대한 유일한 실제 이점은 코드 격리입니다. 즉, 코드를 분리하려는 구체적인 이유가 필요합니다.

모든 스프린트 마다 별도의 릴리스 브랜치를 갖는 것은 미친 짓입니다. 한 스프린트의 코드가 다음 코드와 분리 된 이유는 무엇입니까? 왜 각 스프린트로 이월되는 안정된 단일 릴리스 브랜치가 있습니까?

변경 사항이 일주일 이상 걸리는 것으로 예상되면 분기에서 분기를 수행해야합니다. 트렁크에서 분기로 정기적으로 병합하여 두 가지가 동기화되지 않도록합니다.

개발, 개발자 테스트, 일일 중단 및 기타 활동 등을 고려한 후 거의 모든 새로운 기능이 실시간으로 최소한 1 주일이 소요됩니다.

또한 "정규 병합"이란 무엇입니까? 매일? 주간? 모든 병합에는 시간이 필요합니다. 변경 후 대상 병합 분기가 빌드되고 실행되는지 확인해야합니다. 소규모 팀에서는 자주 병합하는 것이 많은 오버 헤드입니다.

1 백만 라인 코드베이스에서 작업하는 4 명의 개발자로 구성된 팀이 있습니다.

• 모든 개발이 완료된 본점
• 주요 릴리스 당 한 지점 (연간 약 1 회 완료)

하나의 주요 규칙은 빌드되지 않은 코드를 체크인하지 않는 것입니다.

그게 다야. 간단하고 이해하기 쉽고 필요한 격리 기능을 제공합니다 (언제든지 모든 버전의 릴리스 빌드를 만들 수 있음).

한 지점에서 모든 개발 작업을 수행 할 경우의 장점 :

1. 개발자는 항상 서로 동기화되어 있습니다. 두 명의 개발자가 몇 주 동안 자체 지점에서 떨어져서 호환되지 않는 변경 사항을 생성했기 때문에 고통스러운 병합이 없습니다.
2. 부서진 빌드는 같은 날에 발견됩니다. 메인에서 최신 코드를 실행하는 야간 빌드가 있습니다. 어떤 이유로 빌드되지 않은 코드를 누군가가 체크인하면 즉시 알 수 있습니다.
3. 모든 사람이 항상 같은 코드로 작업하면 나중에 버그가 발견 될 가능성이 높아집니다.
4. 분기를 릴리스하기위한 대상 수정 이외의 병합 오버 헤드가 없습니다. 소규모 팀에서는 이것이 큰 팀입니다.

당신은 그들에 대한 몇 가지 포인터를 작성했지만, 왜 당신의 접근 방식이 이미 사용하는 것보다 나은지 설명하지 않았습니다 . 문제가 될 수 있습니다. 당신이 "6 년 동안의 전문적인 경험을 가지고 있기 때문에 우리는 내 방식대로 노력할 것입니다." 귀하의 개념을 적용 할 수없는 모든 일을하려는 팀원.

해결해야 할 문제가 있습니까? 그들이 실제로 문제를 가지고 있고 당신의 제안을 환영 할 것입니다, 또는 그들이 현재하고있는 것처럼 완벽하게 잘 작동하고 있고, 당신이 선호하기 때문에 당신이 그들 에게 일하는 방식을 밀어 붙이고 있기 때문에,이 질문에 먼저 대답하는 것이 중요 합니다. 이런 식으로 작동하십시오.

결국 분기를 사용하도록 강요하면 매우 부정적인 영향을 줄 수 있습니다 . 특히 민첩한 환경에서 트렁크 작업이 쉽습니다. 개발자는 트렁크에 변경 사항을 적용하여 작은 충돌을 처리하며 이러한 변경 사항은 Continuous Integration 플랫폼에서 즉시 사용됩니다. 가지로 :

• 개발자는 변경 위치를 고려해야합니다.

• 누군가 지점을 관리하고 지점에서 트렁크로 병합해야합니다.

• 브랜치 간의 병합은 커밋보다 덜 빈번하게 수행됩니다. 즉, 두 커밋 간의 충돌보다 더 크고 처리하기 어려운 충돌을 누군가가 처리해야합니다.

• 모든 커밋이 Continuous Integration에 반드시 필요한 것은 아니며, 개발자가 커밋이 미칠 수있는 영향 (특히 회귀)에 대한 정보를 지연시킵니다.

사실 그:

기존 팀은 분기에 익숙하지 않습니다

상황을 더욱 악화시킵니다. 나는 경험이없는 프로그래머들로 구성된 팀에서 일했고, 경험이없는 관리자가 지점과 함께 플레이하기로 결정했습니다. 이 많은 (결과 많은 낭비 시간) 당신이 마감 시간을 가진 프로젝트 피하고 싶은 정확히 것입니다.

Mainma가 말했듯이 분기에주의하십시오. 몇 주마다 분기를 언급하는데 실제로 많은 분기가 필요합니까?

또는 푸시 모델 대신 '풀'모델을 사용할 수도 있습니다. Git 또는 Mercurial을 사용하는 경우 중앙 서버로 푸시하기 전에 통합 서버가 변경 사항을 확인하도록 할 수 있습니다. TFS에서는 gated check-in을 사용하여 비슷한 작업을 수행 할 수 있습니다 . 이런 식으로 유효성 검사를 수행하고 분기의 복잡성을 피할 수 있습니다.