GitFlow를 사용하여 다른 지점에서 코드가 병합 될 때까지 대기하여 개발자 차단

우리 팀은 FogBugz & Kiln / Mercurial에서 Jira & Stash / Git로 전환했습니다. 우리는 분기에 Git Flow 모델을 사용하여 기능 분기 (Jira 기능의 Jira 하위 작업과 관련)에서 하위 작업 분기를 추가합니다. 우리는 풀 브랜치를 부모 브랜치로 다시 병합하기 위해 풀 요청을 만들 때 (보통 개발하지만 기능 브랜치로 하위 작업을 위해) 스 태시를 사용하여 검토자를 할당합니다.

우리가 찾고있는 문제는 여러 개발자가 동일한 기능을 위해 공동 작업하는 경우 (예 : 상호 의존적 인 코드에서 작업하는 경우) 프론트 엔드 및 백엔드와 같은 기능 사례를 가장 잘 계획하고 분석 한 경우에도 마찬가지입니다. 별도의 지점에서 한 개발자가 다른 개발자를 차단합니다.

우리는 우리가 발전함에 따라 서로의 지사를 당기려고 노력했습니다. 또한 각 개발자가 여러 분기에서 가져 와서 통합을 테스트 할 수있는 로컬 통합 분기를 만들려고 노력했습니다. 마지막으로, 이것은 지금까지 우리에게 가장 잘 작동하는 것처럼 보이지만 조금 더 많은 오버 헤드가 있으면 기능 분기에서 통합 분기를 즉시 작성하려고 시도했습니다. 서브 태스크 분기 (기능 분기 외부)가 풀 요청 및 코드 검토 준비가되면 변경 세트를이 기능 통합 분기에 수동으로 병합합니다. 그런 다음 모든 관심있는 개발자는 해당 통합 분기에서 다른 종속 하위 작업 분기로 끌어 올 수 있습니다. 이렇게하면 누구나 코드 검토를 통과 할 수있는 지점을 기다리는 것을 방지 할 수 있습니다.

나는 이것이 반드시 Git 문제는 ​​아니라는 것을 알고 있습니다. 그것은 우리 자신의 작업 과정과 문화가 혼합 된 여러 지점에서 상호 의존적 코드 작업과 관련이 있습니다. 개발을위한 엄격한 코드 검토 정책이없는 경우 (진정한 통합 브랜치) 개발자 1이 병합하여 개발자 2가 개발할 수 있습니다. 또 다른 문제는이 기능을 QA에 전달하기 전에 코드 검토 프로세스의 일부로 예비 테스트를 수행해야한다는 것입니다. 이는 프런트 엔드 개발자 1이 백엔드 개발자 2의 지점에서 직접 가져 오는 경우에도 마찬가지입니다. 백엔드 개발자 2가 완료되고 풀 요청이 일주일 동안 코드 검토에 들어간 경우 프런트 엔드 개발자 2는 코드 검토자가 코드 풀러를 수행 할 수 없기 때문에 풀 요청 / 코드 검토를 기술적으로 작성할 수 없습니다. 백엔드 개발자 2 '때문에 테스트

결론은 우리가가는 경로에 따라 이러한 인스턴스에서 병렬 접근보다는 훨씬 더 연속적인 방법으로 자신을 찾고 있으며 이것을 피하기 위해 사용할 프로세스를 찾고 싶다는 것입니다.

마지막으로 언급 할 것은 코드 검토 및 마무리되지 않은 브랜치간에 코드를 공유함으로써 실현한다는 점입니다. 그러나 본질적으로 다른 사람들의 베타 코드를 사용하고 있습니다. 어느 정도까지 나는 우리가 그것을 피할 수 있다고 생각하지 않으며 어느 정도 그것을 기꺼이 받아들입니다.

이 문제는 백엔드 개발과 프론트 엔드 개발간에 너무 엄격한 작업 분리에 놓여있을 수 있습니다.

프론트 엔드 개발자가 새로운 API를 필요로하는 경우, 백엔드에서 더미 API를 생성하여 (예를 들어 항상 같은 값을 반환) 레이아웃을 검증 할 수 없습니까? 그런 다음 스텁을 사용하여 해당 부분 구현을 커밋하고 두 번째로 백엔드 개발자가 실제 기능을 구현합니다.

의존성을 깨 뜨리면 더 나은 흐름을 얻을 수 있으며 병목 현상으로 작용하는 단일 작업을 기다리는 모든 것을 막을 수는 없습니다.

문제점 : Master의 Developer A 브랜치, Master의 Developer B 브랜치 모두 밀접한 관련 기능을 수행하며 불가피한 충돌로 인해 Master 브랜치로의 병합이 어렵다는 불가피한 사실은 모든 사람을 방해합니다.

이것이 예측 가능한 경우, A와 B는 먼저 공통 브랜치를 생성 한 다음이 공통 브랜치와 별도의 작업을위한 각 브랜치를 생성하고, 각각의 별도의 작업을 공통 브랜치에 병합하면 충돌이없는 브랜치가 생깁니다. 쉽게 통합 할 수 있습니다.

개발자 1이 기능 A에서 작업하고 개발자 2가 기능 A에 종속 된 기능 B에서 작업을 마친 경우, 기능 B를 병합하는 방법이 없습니다. 기능 A 없이는 테스트 할 수 없으며, 기능 A의 진행이 많을수록 기능 B가 변경 될 수 있으므로 아직 검토 할 필요가 없습니다.

그러나 개발자 2가 보류 중이라는 의미는 아닙니다! 개발자 2는 기능 C에 대한 작업을 시작하고 기능 A가 완료되면 기능 B의 검토 수정 주기로 돌아갈 수 있습니다. 아마 그렇지 않은 일에 측정 그 컨텍스트 전환이 최적이 아닌 알고 있지만 시간 이후는 전체 기능 A를 할게요 것을 나쁜 (당신이 15 분 사이드 작업에 대해 "존"그들을 잡아 당겨되지 않음)

상황을 돕기 위해 할 수있는 한 가지는 개발주기를 단축하는 방법을 잘 살펴 보는 것입니다.

개발자가 다른 개발자의 기능을 기다리는 경우 첫 번째 개발자 작업의 일부가 전체 기능보다 먼저 검토 및 통합을 통해 블록을 해제 할 수있는 방법이 있습니까?

통합주기를 계속 유지하기 위해 기능을 더 작은 작업 단위로 나누는 방법이 있습니까?

또한 통합에 시간이 얼마나 걸립니까? 빌드 또는 통합이 오래 걸리면 전체 대기열이 느려질 수 있습니다. 대기열이 더 빨리 해제되도록 빌드 시간을 단축하기 위해 수행 할 수있는 작업이 있는지 확인하십시오.