각 스프린트마다 여러 지점 / 개발자의 통합 코드를 어떻게 처리합니까?

개발자들이 각 스프린트의 마스터 브랜치에 자신의 이야기를 통합하는 것에 대해 우려를 표명 한 레트로 콜을 받았습니다. 개발자는 모두 자신의 지사 내에서 그리고 스프린트 끝까지 모든 코드를 하나의 마스터 지사로 병합합니다.

그런 다음 한 개발자 (일반적으로 동일한 개발자)는 모든 것이 다른 개발자의 코드와 잘 통합되도록하는 임무를 맡게됩니다 (대부분의 변경 사항은 같은 페이지에 있습니다. 예를 들어, 데이터 표시 스토리, 데이터 필터링 스토리 및 SLA 표시기).

이 부담을 어떻게 줄이고 코드를 쉽게 병합 할 수 있습니까? 내 관점에서 볼 때 PO 또는 SM이 스토리를보다 효율적인 방식으로 우선 순위를 지정하면 동일한 스프린트에 이러한 종류의 종속성이 없으므로 일부 문제를 해결할 수 있습니다. 다른 사람들은 어떻게이 문제를 해결합니까? 아니면이 과정의 일부입니까?

Git을 사용하는 경우 각 개발자는 develop지점 에서 자체 기능 지점으로 가져 와서 현재 기준에서 너무 멀리 가지 않도록해야합니다. 그들은 매일 그렇게 할 수 있기 때문에 며칠 이상 걸리는 작업은 동기화 상태를 유지하고 병합 문제는 여전히 작지만 해결됩니다.

개발자가 작업을 완료하면 풀 요청 을 작성합니다 . 승인되면 develop지점으로 병합됩니다 .

develop지점은 항상 코드를 작업하면서, 언제든지 릴리스에 대한 준비를해야합니다. 실제로 릴리스를 수행하면 릴리스와 병합 develop하여 master태그를 지정합니다.

Continuous Integration Server가 좋은 경우 변경 사항을 체크인 할 때 (특히 풀 요청에 대해) 각 분기를 작성합니다. 일부 빌드 서버는 Git 서버와 통합되어 빌드가 실패하거나 자동화 된 테스트가 실패 할 경우 풀 요청을 자동 승인 또는 승인 취소합니다. 잠재적 인 통합 버그를 찾는 또 다른 방법입니다.

나는 우리가 같은 문제로 어려움을 겪고있는 팀에서 일했다. 통합하기 전에 시간이 짧을수록 어려워지는 것을 알았습니다. 나는 지속적인 통합을 가르치는 대부분의 사람들이 몇 분마다 커밋에 대해 이야기한다는 것을 알고 있습니다. 우리는 실제로 매시간 정도 커밋했을 것입니다.

우리는 또한 건물만으로는 충분하지 않다는 것을 발견했습니다. 우연히 서로의 코드를 위반하지 않도록하기 위해 좋은 테스트 적용 수준이 필요했습니다.

• 가지를 오래 유지하십시오 (이미 이미하고있는 것처럼 들립니다).
• 테스트 결과를 스스로 말하게하십시오.
• 스프린트가 끝날 때까지 기다리지 마십시오.

이것을 위해 TDD를 구독 할 필요조차 없습니다. 개발자의 기능이 올바르게 작동하고 있음을 입증하는 테스트 만 있으면됩니다. 여기에는 단위 테스트 및 통합 테스트가 포함될 수 있지만 중요한 기능에 대한 자동화 된 엔드 투 엔드 테스트가 이상적입니다. 표준 회귀 팩 내용.

그런 다음 병합이 완료되면 자동화 테스트 보고서를 함께 확인하고 모든 것이 성공적으로 통합되었는지 확인할 수 있습니다.

저자가 Git PR이 각 개발자가 자신의 작업을 병합하도록하여이 문제를 해결할 것이라고 언급 한 다른 답변 중 하나에 동의합니다.

마지막 단락까지 떠날만큼 중요한 또 다른 요점입니다. 스프린트가 끝날 때까지 기다리지 않고 야간 빌드에서 수동 테스트를 실행하는 것이 좋습니다. 개발자는 기능이 완료되는 즉시 통합하여 가능한 빨리 통합, 배포 및 테스트 할 수 있도록해야합니다.

하지마

사용하는 언어와 편집중인 파일에 따라 각 개발자가 자신의 분기에서 해당 파일을 편집하는 것이 적합하지 않을 수 있습니다. 예를 들어 C #에서는 한 번에 한 사람 만 UI 디자이너 파일을 편집하는 것이 가장 좋습니다. 이들은 자동 생성 된 파일이므로 코드가 명백한 이유없이 이동되기도합니다. 이로 인해 대부분의 병합 도구가 혼란스러워집니다.

이는 UI 작업이 완료 될 때까지 일부 스토리가 다른 스토리를 차단할 수 있음을 의미합니다. 그리고 / 또는 UI를 레이아웃하기 위해 새로운 스토리가 만들어지고 다른 스토리는 기능을 구현합니다. 또는 한 개발자는 모든 UI 작업을 수행하고 다른 개발자는 해당 UI의 기능을 구현할 수 있습니다.

관련 메모에서 여러 스토리가 모두 같은 파일에 닿는다는 사실을 알고 있다면 동시에 모든 작업을 피하고 싶을 수 있습니다. 모두 같은 스프린트로 잡아 당기거나 하나 이상의 작업이 완료 될 때까지 작업을 시작하지 마십시오.

지연 및 대규모 병합을 피할 수있는 또 다른 방법은 기능 플래그입니다 . 구성하기 전에 (이상적으로 동적으로) 구성 가능한 플래그를 사용하여 변경 사항을 보호하면 의도 한대로 변경되지 않습니다.

이를 통해 변경 사항을 조기에 하나 master또는 공동 개발 지점 으로 병합 할 수 있습니다 . 그런 다음 다른 개발자는 이러한 변경 사항을 기능 분기로 다시 병합하거나 분기를 리베이스 할 수 있습니다.

다른 답변에서 이미 지적했듯이 이것은 지속적인 통합 솔루션과 결합되어야합니다.

기능 플래그에는 추가 이점이 있습니다 (예 : A / B 테스트를 쉽게 수행 할 수 있음). 자세한 내용은 Martin Fowler의이 기사 를 참조하십시오.

각 기능에 대해 별도의 개발 지점에 대한 접근 방식을 따르고 있으며 통합 테스트 환경에서 테스트하기 위해 지점을 QA 지점에 병합합니다.

회귀 및 통합 테스트가 완료되면 준비된 기능을 릴리스 지점으로 쉽게 옮길 수 있습니다.

모든 것이 잘되면 릴리스 브랜치를 다시 마스터 브랜치로 병합합니다.

간단히 말해 커밋하고 병합하면 병합 충돌의 기회가 줄어들고 충돌이 크게 줄어 듭니다. 다른 부분은 실제로 리드에 의한 계획으로, 작업 흐름을 원활하게 보장 할 수 있습니다.

다른 답변은 커밋에 대한 모범 사례에 대한 훌륭한 통찰력을 제공하며 단순히 병합 문제의 대부분을 줄일 수있는 지침을 따르면됩니다. 합병이 많을수록 거의 필연적이지만 소규모 팀의 경우 개인당 지점 접근 방식이 충분히 효과적 일 수 있습니다. 물론, 더 확장 가능한 관행에 들어가는 것은 아프지 않습니다!

그러나 가장 중요한 질문 중 하나 인 같은 코드 영역을 만질 때해야 할 일을 아무도 다루지 않은 것 같습니다. 코드 기반에 익숙하고 다양한 작업의 종속성을 인식 할 수있는 리더를 보유하는 것이 유용합니다. 그들이 작업 및 커밋의 타이밍을 조정하지 않으면 병합 충돌 및 라인 별 해결로 끝날 것입니다. 대규모 팀에서는 작업 / 타이밍을 구성하는 것이 훨씬 어렵지만 소규모 팀에서는 이러한 충돌하는 작업을 식별 할 수 있습니다. 그런 다음 리드는 충돌을 완전히 피하기 위해 모든 관련 작업을 동일한 엔지니어로 옮길 수도 있습니다.