코드 검토 중 반복 빌드: OpenStack 커뮤니티에 대한 실증 연구

코드 검토는 개발자들이 서로의 변경 사항을 비판하는 인기 있는 관행입니다. 자동화된 빌드가 저수준 문제(예: 구문 오류, 회귀 버그)를 식별할 수 있기 때문에 소프트웨어 조직이 코드 검토 과정에 자동화된 빌드를 통합하는 것은 드문 일이 아닙니다. 이러한 코드 검토 배포 시나리오에서 제출된 변경 집합은 동료 코드 검토자와 자동화된 빌드 봇 모두의 통합 승인을 받아야 합니다. 자동화된 빌드는 변경 집합의 상태에 대해 신뢰할 수 없는 신호를 생성할 수 있기 때문에(예: "플레이키" 또는 비결정적 실행 동작으로 인해), Gerrit과 같은 코드 검토 도구는 개발자가 변경 집합을 업데이트하지 않고 빌드 프로세스를 반복하도록 요청할 수 있는 "재검사"를 요청할 수 있도록 허용합니다. 우리는 무제한 재검사 명령이 신중하게 적용되지 않을 경우 시간과 자원을 낭비한다고 추측합니다. 재검사 명령이 실제 환경에서 어떻게 적용되는지를 탐구하기 위해, 본 논문에서는 OpenStack 커뮤니티의 66,932건의 코드 검토에 대한 실증 연구를 수행합니다. 우리는 (i) 빌드 실패가 얼마나 자주 재검사되는지; (ii) 재검사를 호출함으로써 빌드 실패 결과가 얼마나 변경되는지; 및 (iii) 재검사를 호출함으로써 얼마나 많은 낭비가 발생하는지를 정량적으로 분석합니다. 우리는 (i) 55%의 코드 검토가 실패한 빌드가 보고된 후 재검사 명령을 호출하고; (ii) 재검사 명령을 호출하면 실패한 빌드 결과가 42%의 경우에만 변경되며; (iii) 재검사 명령을 호출하면 평균 2,200%의 검토 대기 시간이 증가하고 187.4 컴퓨팅 연년의 낭비로 이어져 지구에서 가장 오래된 육상의 동물과 경쟁할 수 있는 충분한 컴퓨팅 자원을 생성함을 관찰했습니다. 우리의 관찰은 재검사 명령이 빌드 실패 후 자주 사용되지만, 높은 빌드 성공 가능성을 달성하지 못한다는 것을 나타냅니다. 개발자 설문조사와 우리의 역사 기반 정량적 발견을 바탕으로, 우리는 검토 팀이 재검사 전에 두 번 생각하고 낭비를 고려할 것을 권장합니다. 현재 재검사는 많은 낭비된 컴퓨팅 자원과 대기 시간을 증가시키고 있지만, 낭비를 줄일 수 있는 솔루션을 제안할 연구자와 도구 개발자에게는 흥미로운 미래의 기회를 제공합니다.