오픈소스) gerrit을 통한 리뷰 시스템

 

이전글에서 "git review" 명령어를 사용하면

코드는 gerrit 레포지토리에 올라가고

코맨트와 함께 투표를 통해 코드를 리뷰(review) & 머지(merge)를 수행한다고 정리했는데

 

전반적인 기여 프로세스를 보면 다음과 같음

 

이미지 출처: https://docs.opendev.org/opendev/infra-manual/latest/gettingstarted.html

 

1. 개발자는 수정하고자하는 프로젝트의 코드를 로컬 환경으로 'clone'

2. 로컬 환경에서 수정하고자하는 버그에 대해서 브랜치 생성.

3. 변경사항을 저장 -> 유닛 테스트 수행 -> git commit 

4. git review를 통해 Gerrit 리뷰 시스템에 변경사항을 제출

5. 자동 테스트 툴(Zuul)을 통해, 빌드 및 테스트를 진행하고 제출한 코드에 대한 리뷰 진행

6. 변경사항을 재수정해야할 경우, 코드를 변경하고 git commit --amend를 통해 다시 변경사항을 제출(--amend 옵션은 가장 최근 커밋을 수정하는 옵션으로 반드시 사용해야함)

 

순서로 진행하게 됨

 

코드 리뷰과정은 투표로 진행되며, 각 리뷰어는 다음과 같은 투표 점수와 함께 리뷰를 진행.

 

 

간단히 요약하자면,

-2 ~ +2 까지 총 5단계의 투표가 있으며

-2와 +2는 프로젝트의 핵심 리뷰어가

-1과 +1은 일반 리뷰어가

0은 기타 다른 사람이 투표없이 코맨트를 남길 때 사용

 

Code Review +2

+2점의 투표는 핵심 리뷰어들만 사용 할 수 있음. 일부 프로젝트에서는 +2점 만을 요구하고, 많은 프로젝트에서는 특정 상황(ex: 사소한 변경)에 대해 요구 사항을 완화하기도함. 주의할 점은 2개의 +1과 하나의 +2점은 같은게 아니라는데... 이건 더 해봐야 할듯

 

Code Review +1

핵심 코어 리뷰어가 아닌(non-core reviewer) 경우, +1점은 해당 변경 사항을 검토했으며 머지(merge)에 동의한다는 의미. 

단순히 +1점만 주는 것은 리뷰 이력이 없는 한 별로 유용하진 않다고(하지만 코어 팀에 합류할 가능 성이 있다고함).

 

코어 리뷰어 역시 +1점을 사용할 수 있음. 패치가 괜찮다고 생각되지만 아직 논의, 피드백의 여지가 있어 후속 변경에서 수정될 수 있다고 판단될 때 +1점을 사용. 이런 경우, 기여자가 스스로 수정할 기회를 주는 것이 좋음(기여자가 스스로 수정을 원하는지, 멘토링을 원하는지 물어보는 것 또한 방법).  이러한 방법은 -1점을 주는 것보다 기여자를 격려하고 신뢰를 유지하는 데 훨씬 더 효과적임. 또한, 후속 패치 세트를 다시 거토할 때, 이전에 기본적으로 동의했던 사항을 참고할 수 있어 차이점만 확인하면 되므로 더 빠르게 검토 가능.

 

코어 리뷰어라도 코드에 익숙하지 않고 확신이 없다면 +1점을 투표할 수 있음

 

Code Review 0

변경 사항에 대해 강한 찬반 의견이 없거나, 의견을 형성하기 위해 단순히 질문이 필요한 경우 리뷰 없이 댓글만 남길 수 있음. 질문에 대한 답이 문제를 드러낼 것이라고 확신하지 않는 한, 처음부터 -1점을 투표하는 것보다는 +0점이 바람직함. -1점 투표가 없는 댓글은 실수로 지나치기 쉬우므로, 시간이 진도 답변이 없거나 새로운 패치 세트가 게시되었는데도 아무도 댓글에 응답하지 않는 경우, 제출자와 IRC에서 연락을 시도하거나 -1점 투표를 고려해야 할 수도 있음.

 

Code Review -1

-1점 리뷰는 변경 사항이 병합되기 전에 반드시 수정되어야 한다고 강하게 믿는 중대한 문제가 발견되었을 때 사용. -1점을 투표하는데는 정당한 이유가 많을 수 있음(ex. 변경 사항이 새로운 버그를 유발하거나, 커밋 메시지에서 오타가 발견되는 경우). 항상 최선의 판단을 사용하되, -1점을 투표함을써 다른 사람의 작업을 방해하게 된다는 점을 명심해야함. 그러므로 -1점은 후속 변경으로 해결할 수 없는 중요한 이유가 있는 경우에만 사용해야함.

또한, 많은 (바쁜)리뷰어들은 이미 부정적인 리뷰가 달린 변경 사항을 우선적으로 검토하지 않을 가능성이 큼. 따라서 -1을 투표하는 것은 제출자에게 수정 작업을 요구할 뿐만 아니라, 추가적인 피드백을 받을 기회를 제한할 수도 있음.

-1점 리뷰는 반드시 실행 가능한 피드백이 담긴 댓글과 함께 작성되어야함.

패치 세트 수정이 많이 이루어진 변경 사항을 늦게 검토하는 경우, 이상한 점이 있다면 이전 기록을 확인하는 것을 잊지 마세요. 이는 이전 이리뷰어에 의해 요청된 사항일 수 있음. 코어 리뷰어로서 다른 코어 리뷰어의 조언과 반대되는 피드백을 제공해야하는 상황이 발생한다면, 다른 리뷰어와 합의에 도달하고 이를 문서화하는 것이 책임. 가능핟면 -1점을 투표하기 전에 합의를 도출하는 것이 이상적. 그러나 변경 사항이 실제로 문제를 유발하는 경우라면, 상충되는 조언이 있다는 점을 명시하고 가능한 한 빠릴 해결하겠다는 댓글 필요. 코어 리뷰어 간의 의견 차이를 해결하는 것은 패치 제출자의 책임이 아님.

 

Code Review -2

-2점 투표는 코어 리뷰어만 사용할 수 잇음. 다른 투표와 달리 -2점 투표는 '고정(sticky)'되어 있으며, 제출자가 새로운(실질적으로 다른) 패치 세트를 푸쉬하더라도 변경 사항에 계속 남아 있습니다. 따라서 -2점을 제거하려는 동일한 코어 리뷰어가 직접 조치를 취해야하므로 신중하게 사용해야함.

-2점 투표의 목적은 제출자에게 해당 변경 사항에 추가적인 시간을 투자해도 거의 확실히 낭비가 될 것임을 알리기 위함. 

-2점 리뷰는 항상 변경사항이 프로젝트 목표와 맞지 않는 이유를 설명하는 댓글과 함께 제공되어야하며, 이를 통해 제출자가 이유를 이해하고 향후 기여를 보다 생산적으로 재조정할 수 있도록 도와야함.

 

 

아래 'procedural -2' 를 제외하면, -2점 투표에는 다른 정당한 사용 사례가 없음

 

procedural -2

일부 프로젝트에서는 기능 동결(Feature Freeze) 후 다음 릴리스 브랜칭(branching) 이전에 기능 변경 사항에 -2 투표를 부여. 이는 동결 기간 동안 새로운 기능이 실수로 병합되지 않도록 하기 위함. 이러한 -2를 추가한 사람은 마스터 브랜치가 새로운 기능을 받을 수 있도록 열리면 해당 -2를 다시 제거. 이 과정에서 정확히 어떤 일이 진행 중인지 설명하는 댓글을 남겨야 .

제출자는 동결 기간 동안에도 변경 사항을 계속 수정할 수 있음.

 

 

Workflow -1

workflow -1 투표는 변경 사항이 현재로서는 종합적인 검토를 받을 준비가 되어 있지 않음을 나타. 이 투표는 코어 리뷰어와 해당 변경 사항의 원래 작성자만 사용. 변경 사항에 대해 새로운 패치 세트가 제출되면 모든 Workflow 투표는 초기화. 이는 진행 중인 작업에 대한 피드백을 얻는 더 나은 방법이며, 특정 리뷰어에게만 보이는 이전 방식의 Draft 변경과 달리 모든 리뷰어와 투명하게 공유됨.

코어 리뷰어는 또한 workflow -1 투표를 사용하여 일시적인 조건 하에서 변경 사항이 병합되는 것을 방지할 수 있음. 이 경우, 코드 리뷰 프로세스 자체는 방해받지 않도록 할 수 있습니다.

 

 

출처
https://docs.opendev.org/opendev/infra-manual/latest/gettingstarted.html

https://docs.openstack.org/project-team-guide/review-the-openstack-way.html