풀 리퀘스트가 속도를 늦추고 있습니다.

풀 리퀘스트는 소프트웨어 개발에서 표준 코드 변경의 일부로 사용될 때 지속적인 전달 속도를 늦춥니다. 풀 리퀘스트를 사용한다면 스스로에게 물어봐야 합니다.

매일 풀 요청 승인을 기다리는 데 얼마나 많은 시간을 소비하고 있습니까?

풀 요청을 열 때 통합 테스트가 통과할 것이라고 얼마나 확신하십니까?

예상대로 작동하지 않는 코드가 승인된 횟수는 몇 번입니까?

지속적인 전달에는 통합 테스트가 필요합니다.

소프트웨어를 개발할 때 우리는 빠른 피드백을 받고 빠르게 개선할 수 있도록 가능한 한 자주 소프트웨어를 테스트하고 릴리스하기를 원합니다.

소프트웨어를 제공하려면 시스템의 동작을 확인하고 문제를 식별할 수 있도록 통합 테스트를 실행해야 합니다.



하지만 그 전에 …

통합 테스트에는 코드 통합 및 배포가 필요합니다.

유효한 통합 테스트를 실행하기 전에 코드 변경 사항을 통합하고 테스트 환경에 배포해야 합니다.



이 프로세스는 기본 브랜치에 대한 변경 사항을 커밋하고 자동 배포 및 테스트를 기다리는 것처럼 간단할 수 있습니다. 그러나 많은 팀에게 이는 다음을 의미합니다.

풀 요청으로 분기를 생성합니다.

코드 검토를 요청하는 다른 팀 구성원에게 메시지를 보냅니다.

풀 요청에 대한 설명을 검토합니다.

코드를 변경합니다.

올바른 수의 승인이 제공될 때까지 2단계부터 반복합니다.

코드를 병합하고 배포 및 테스트를 기다리는 중입니다.

끌어오기 요청이 방해가 되는 방법

코드 변경에 대한 풀 요청 승인을 기다리는 데 몇 분, 몇 시간 또는 며칠이 걸릴 수 있습니다. 이 시간은 통합 테스트를 실행하기 전에 발생하기 때문에 코드 변경에 대한 피드백을 받는 능력에 직접적인 영향을 미칩니다.



완전히 테스트하지 않은 코드의 승인을 기다리는 데 시간을 낭비하는 대신 코드에 대한 확신이 생기면 즉시 승인을 받거나 검토를 완료하는 것을 목표로 해야 합니다.

우리는 어떻게 더 빨리 움직일 수 있습니까?

끌어오기 요청이 속도를 늦추어 소프트웨어 개발 수명 주기를 방해하는 것을 방지하는 두 가지 주요 옵션이 있습니다.

페어 프로그래밍

화면, 키보드 및/또는 컴퓨터를 공유하면서 코드 작업을 함께 수행하는 두 개발자는 풀 리퀘스트를 열고 승인하는 사이의 중단 시간을 최소화하는 데 사용할 수 있습니다.



이것은 함께 작업하는 두 개발자가 코드를 이해하고 구현에 동의하며 동시에 사용할 수 있어야 하기 때문에 작동합니다.

출시 전 코드 검토

배포 및 테스트 후 릴리스 전에 코드 검토를 완료하면 풀 요청의 필요성을 대체할 수 있습니다. 이것은 여전히 ​​동일한 수준의 검토를 허용하지만 개발자에게 통합 테스트를 먼저 실행하는 것에 대한 자신감과 빠른 피드백을 제공합니다.



배포 파이프라인에 몇 가지 추가 단계를 추가하여 이 코드 검토 프로세스를 구현할 수 있습니다.

먼저 git 명령으로 수행할 수 있는 현재 코드와 새 버전을 비교해야 합니다.

git diff e237udbas r2bghur392

그런 다음 코드 변경 사항을 검토한 후 릴리스를 수동으로 트리거해야 합니다.

어떻게 생각해?

이는 소프트웨어를 지속적으로 제공할 때 끌어오기 요청으로 인해 속도가 느려지는 것을 방지하는 방법의 몇 가지 예일 뿐입니다.

이러한 아이디어가 소프트웨어 개발을 개선하는 데 도움이 될 수 있다고 생각하십니까? Twitter 또는 이메일로 알려주세요[email protected]