티스토리 뷰
이번 포스트에서는, 변경 사항에 대해서 어떻게 추적하고, 각 리뷰 점수가 어떤 의미를 갖는지 알아보겠습니다.
변경사항 추적하기
변경사항을 제출하고 난 후, 여기서 변경사항을 추적할 수 있습니다. 로그인 후, 제출한 변경사항에 대해서 "Outgoing reviews", 리뷰하고 있는 변경사항에 대해서 "Incoming reviews", 본인이 리뷰어이거나 소유자인 변경사항에 대해 "Recently closed"인 대시보드를 볼 수 있습니다.
리뷰어 추가하기
때로는 우리의 패치에 대해서 의견을 내줄 사람들이 필요할 때가 있습니다. 왜냐하면 그 사람들은 여러 권한을 가지고 있을 수도 있고, 당신을 돕는 멘토일 수도 있기 때문입니다. 우리가 새로운 패치나 패치셋을 업로드했다는 것을 알리는 가장 쉬운 방법은 gerrit 웹 UI에서 그 사람들을 리뷰어로 추가하는 것입니다. 우리는 이름, gerrit 이메일 주소, ssh 사용자 이름 또는 gerrit ID로 검색할 수 있습니다.
일반적으로 패치마다 각 상호작용(새로운 패치셋, 코멘트, CI 시스템 투표 등)이 해당 패치에 대한 모든 리뷰어들에게 이메일 알림을 보낼 것이기 때문에 이 기능을 과도하게 사용하지 않는 것이 좋습니다.
만약 우리가 패치에 대해서 리뷰한다면 자동으로 리뷰어 목록에 추가됩니다.
Gerrit 웹 에디터
우리는 로컬에서 변경하지 않고 Gerrit 웹 인터페이스에서 패치를 편집하고 변경 내용을 게시할 수 있습니다. 작업하고 있는 로컬 브랜치가 자동으로 업데이트되지 않으므로, 양이 많은 코드 업데이트에는 일반적으로 권장되지 않습니다. 패치가 기본적으로 작은 pep8 failure(whitespace at the end of line, needing to wrap a line 등)을 제외하고 병합할 준비가 돼있는 몇몇 경우에, 이 gerrit 기능은 'git add', 'git commit --amend', 'git review' 과정을 거치지 않고 변경사항을 수정하고 게시하는데 매우 편리할 수 있습니다.
Gerrit 웹 에디터에 접근하기 위해, 파일의 Gerrit Code Review 페이지의 상단에 있는 패치셋 숫자 옆에 있는 종이 위에 글을 쓰고 있는 연필 같이 생긴 아이콘을 클릭하세요.
변경사항 리뷰하기
거의 모든 레포지토리에서, Gerrit은 패치에 대해 5가지 투표 선택사항을 제공합니다. +2점과 -2점은 프로젝트의 핵심 리뷰 팀의 멤버들만 사용할 수 있습니다. 모두가 -1점과 +1점을 투표할 수 있습니다. 우리는 0점으로 아무 투표 없이 코멘트를 남길 수도 있습니다. 모든 경우에 우리는 최선의 판단을 하지만, 우리를 가이드하기 위해 커뮤니티의 경험으로부터 이러한 휴리스틱을 제공합니다.
OpenStack을 발전시키는 것은 패치 커미터들입니다. 리뷰어로써, 우리가 커미터들에게 서비스를 제공한다는 것을 기억하세요. 그 반대가 아닙니다. 커미터로써, 모든 사람이 동일한 규칙을 적용받는다는 것을 기억하세요. 우리의 패치에 투표하는 핵심 리뷰어들도 그들의 검토사항에 대해 동일한 리뷰 과정을 거칩니다.
Code Review +2
+2점의 투표는 핵심 리뷰어들만 사용할 수 있습니다. 일부 프로젝트에서는 +2점 만을 요구하고, 많은 프로젝트에서는 특정 상황(사소한 변경 등)에서 요구사항을 완화하지만, 변경사항이 병합되기 전에 2개의 +2점을 요구하도록 권장됩니다. 만약 핵심 리뷰어인 경우, 로컬 정책을 확인하세요. 헷갈리지만, 2개의 +1점과 +2점은 같은 게 아닙니다!
승인 없이 +2점을 투표하는 것은 다른 핵심 리뷰어가 변경사항을 승인하는 것에 만족한다는 것을 나타냅니다. 만약 다른 핵심 리뷰어가 이미 +2점을 투표했다면, 우리는 일반적으로 동시에 변경사항을 승인할 것입니다. 하지만 작성자나 다른 리뷰어가 적절하다고 생각될 경우, 사소한 피드백에 응답할 기회를 주기 위해 승인을 보류할 수 있습니다. 만약 피드백이 충분히 사소한 것이라면, +1점만 투표하는 것이 더 바람직합니다.
만약 다른 핵심 리뷰어가 이전의 패치셋에서 +2점을 투표했고, 해당 패치 이후 리뷰어들이 충분히 만족할 것으로 확신할 수 있는 사소한 방식으로만 변경된 경우, 다시 검토하기를 기다리지 말고 +2점으로 승인하세요. 이렇게 할 때에는 왜 그런 결정을 내렸는지 설명하는 코멘트를 남기세요.
Code Review +1
핵심 리뷰어가 아닌 경우, +1점은 변경사항을 검토했으며, 변경사항을 병합하는데 만족한다는 것을 나타냅니다. 우리의 기록이 핵심 리뷰 팀에게 알려지지 않는 경우, 코멘트 없이 +1점만 남기는 것은 그다지 유용하지 않습니다. (이 경우 곧 핵심 리뷰 팀에게 알려질 가능성이 큽니다.) 변경사항이 합당한 경우, 코멘트를 남기세요. 만약 패치를 테스트한 경우, 그렇게 말하세요: 올바른 패치인지 확인하기 위해 참조한 어떤 것이라도 있다면, 다음 리뷰어를 위해서 참조 링크와 함께 코멘트를 남기세요.
핵심 리뷰어들도 +1점을 사용할 수 있습니다. 패치가 괜찮다고 생각하지만 열린 질문이 있거나, 후속 변경에서 고칠 수 있는 사소한 피드백이 있지만 그 기여자에게 변경사항을 스스로 고칠 수 있는 기회를 주고 싶을 때 +1점을 주는 것을 고려해보세요. 예를 들어, 리뷰어들도 우리의 의견을 원하거나 우리를 도와주고 싶어 하기 때문입니다. 만약 기여자가 멘토를 찾고 있는지, 아니면 패치를 수정하거나 후속 변경사항을 직접 제출하기를 원하는지 확실하지 않은 경우, 직접 물어보세요! 많은 기여자들이 핵심 리뷰어들의 +1점에 빠르게 응답할 것입니다. 왜냐하면 기여자들은 그것이 +2점에 거의 다 왔다는 것을 알고 있고, 이것이 기여자를 격려하고 호의를 베푸는 데 -1점보다 훨씬 낫기 때문입니다.
핵심 리뷰어들조차 프로젝트의 모든 부분에 익숙하지 않을 수 있습니다. 자신 없는 영역에서 변경사항이 생기면 +1점을 투표할 수 있고, 그렇지 않다면 +2점을 투표하면 됩니다. 항상 그렇듯이, 왜 그런지 말하는 코멘트를 남기는 것이 도움이 됩니다.
Code Review 0
만약 우리가 변경 사항에 대해서 어떤 쪽이든 강한 느낌을 가지고 있지 않거나, 의견을 결정하기 위해 대답해야 할 질문이 있다면, 리뷰 없이 코멘트를 남길 수 있습니다. 만약 우리가 질문에 대한 답이 문제를 드러낼 것이라고 확신이 안 든다면, 처음에 -1점을 투표하는 것이 낫습니다. -1점이 없는 코멘트는 실수로 놓치기 쉬우므로, 답변이 없는 채로 시간이 꽤 지났거나, 우리의 코멘트에 아무도 답변을 하지 않고 새 패치셋이 게시된 경우, IRC로 제출자에게 연락하거나 -1을 고려해봐야 할 때일 수도 있습니다.
Code Review -1
-1점을 사용해서 변경사항이 병합되기 전에 패치가 수정되어야 한다고 굳게 믿는 문제를 발견했다는 것을 알리세요. 변경사항에 의해 유발된 새로운 버그부터 커밋 메시지의 오타(만약 git 기록에서 핵심 단어에 패치를 찾기 어렵게 만드는 오타가 있는 경우)처럼 사소한 것에 이르기까지 -1점을 주는 여러 가지 이유가 있습니다. 다시 한번, 최선의 판단을 하되, -1점을 투표할 때는 우리가 다른 사람의 일을 방해하는 것이므로 다른 방법(예: 후속 조치 변경)으로 해결할 수 없는 타당한 이유인지 확인하세요.
많은 리뷰어들이 이미 부정적인 리뷰가 있는 변경사항에 대해 우선순위를 두지 않을 것이라는 것을 기억하세요. 따라서 -1점을 투표함으로써 제출자에게 다른 개선을 요구하는 것뿐만 아니라, 더 많은 피드백으로부터 -1점을 잠재적으로 차단할 수 있습니다.
-1점의 리뷰에는 항상 실행 가능한 피드백이 포함된 코멘트가 동반되어야 합니다.
만약 많은 수의 패치셋이 있는 변경사항에 대해 리뷰할 경우, 이상한 점이 보이는지 이전의 기록을 돌아보는 것을 잊지 마세요. 그게 이전의 리뷰어에 의해 요청되었을지도 모릅니다. 만약 우리가 핵심 리뷰어이고, 우리가 다른 핵심 리뷰어에 의해 주어진 조언에 반대되는 조언을 할 필요가 있다고 생각한다면, 다른 리뷰어와 합의에 도달하는 것이 우리의 책임이고, 둘 다 문서화하는 것이 이상적입니다. -1점을 투표하기 전에, 변경사항이 무언가 망가트리지 않는 이상(이 경우, 상충되는 의견이 있고, 그 문제를 가능한 한 빨리 해결하기 위해 작업 중이라는 것을 알리는 코멘트를 남기세요), 핵심 리뷰어들 간의 의견 불일치를 다루는 것은 패치 제출자의 책임이 아닙니다.
Code Review -2
+2점의 투표는 핵심 리뷰어들만 사용할 수 있습니다. 다른 투표와 다르게, -2점은 'sticky'합니다. -2점은 제출자가 새로운 패치를 푸시해도 변경되지 않습니다. 즉, -2점을 지우려면 동일한 핵심 리뷰어의 조치가 필요하므로 주의하세요. -2점의 목적은 변경 제출자에게 그 변경 사항에 대해 작업하는 시간은 분명히 낭비될 것이라는 것을 알리는 것입니다. 만약 변경사항에 대해 -2점의 리뷰를 받는다고 기분 나쁘게 생각하지 마세요! 그 리뷰어는 우리의 소중한 시간과 에너지를 병합될 가능성이 있는 변화로 돌리려고 하는 것입니다.
-2점의 리뷰는 항상 그 변경사항이 프로젝트의 목표에 부합하지 않는 이유를 설명하는 코멘트를 첨부해서, 제출자가 그 이유를 이해하고 추후의 기여에 대해서 더 생산적으로 집중할 수 있도록 해야 합니다.
아래의 'Procedural Code Review -2'를 제외하고, -2점의 적법한 용도는 없습니다.
Procedural Code Review -2
일부 프로젝트에서는 Feature Freeze 후, 다음 릴리즈로 branching 하기 전에 Feature Freeze 동안 의도치 않게 기능이 병합되지 않도록 변경사항에 대해 -2점을 투표합니다. -2점을 투표한 사람은 마스터 브랜치가 새로운 기능을 위해 다시 열리면 -2점을 제거할 것입니다. -2점을 투표한 사람들은 무슨 일이 일어나고 있는지 설명하는 코멘트를 남겨야 합니다. 제출자들은 Freeze 기간 동안 변경 사항을 계속 수정할 수 있습니다.
Workflow -1
Workflow -1점은 변경사항이 현재 전체적인 리뷰를 위한 준비가 되어있지 않음을 나타냅니다. 핵심 리뷰어와 변경 소유자만 Workflow -1점에 투표할 수 있습니다. 모든 Workflow 투표는 새 패치셋을 제출할 때마다 삭제됩니다. 이것은 (명시적으로 추가되지 않은 리뷰어들로부터 가려진) Draft 변경사항의 레거시 방법보다 진행 중인 작업에 대해 피드백을 얻는 더 나은 방법입니다.
핵심 리뷰어들도 코드 리뷰 프로세스를 중단하지 않고 일시적인 조건 중 변경사항이 병합되는 것을 방지하기 위해 Workflow -1점에 투표할 수 있습니다.
Workflow +1
Workflow +1점은 변경사항이 핵심 리뷰어로부터 승인될 때 사용됩니다. Workflow +1점 없이 아무리 2개의 Code Review +2점을 받았다고 하더라도 변경사항은 병합되지 않습니다.
다른 변경사항 살펴보기
Gerrit에서 다른 기여자의 패치를 확인하고 변경할 수 있지만, 작업하기 전에 항상 그 기여자와 변경사항에 대해 논의해야 합니다.
git-review -d <change ID><change ID>는 Gerrit의 web UI에서 찾을 수 있습니다.
패치에 대해 체크아웃한 후, 자동으로 새로운 브랜치로 변경될 것이고, 거기서 우리는 새로운 변경사항에 대해 작업할 수 있습니다.
Cherry-picking
만약 우리의 커밋이 작업을 시작한 후 업데이트된 변경사항에 대해 의존적이고, 해당 변경사항으로부터 새로운 패치셋을 가져와야 할 경우, 우리의 변경사항 위로 cherry-pick을 할 수 있습니다.
git-review -x <change ID><change ID>는 이전의 경우와 동일합니다.
Merging
만약 변경사항이 승인되고 게이트 작업을 통과하면 Gerrit은 자동으로 최신 패치셋을 병합합니다.
각 패치셋은 테스트하기 전에 브랜치의 HEAD에 병합됩니다. Gerrit이 패치셋을 병합할 수 없는 경우, -1점 리뷰를 주고 병합 실패에 대한 코멘트를 추가합니다.
변경사항이 병합될 때마다, "merge-check" 파이프라인은 동일한 프로젝트에 열려있는 모든 변경사항이 여전히 병합 가능한지 검증합니다. 만약 어떤 작업이든 병합할 수 없다면, Zuul은 -1점의 리뷰를 주고, 병합 실패에 대한 코멘트를 추가합니다.
변경사항이 병합된 후에는, 프로젝트별로 사후 작업이 실행됩니다. 대부분의 post 작업은 문서를 게시하거나, coverage를 실행하거나, 번역 서버에 문자열을 전송합니다.
Project Gating
프로젝트 게이팅은 개발자의 패치셋이 병합되기 전에 회귀 테스트(regression test)를 실행하는 과정을 말합니다. 회귀 테스트를 실행하는 목적은 소스 코드 저장소에 제출된 새로운 변경사항이 새로운 버그를 유발하지 않는지 검증하는 것입니다. 게이팅은 일련의 테스트가 성공적으로 통과된 후에 패치셋이 개발의 주류로 병합되도록 함으로써 퇴보를 방지합니다.
게이팅에 사용되는 시스템은 Zuul로, Gerrit 이벤트 스트림을 listen 하고 YAML 파일로 구성하여 이벤트에 응답하여 실행할 일련의 테스트를 정의합니다.
대기열의 작업은 핵심 리뷰어가 변경사항을 승인하고(+1 Workflow를 사용하여) verified 된 +1점 투표가 존재하면 실행됩니다. 승인 시 최소 1개의 +2점 코드 리뷰 투표가 존재해야 합니다. (핵심 리뷰어가 승인할 때 부여할 수 있습니다.) 즉, 이 컨벤션은 승인을 위해 2개의 +2점 코드 리뷰가 필요하다는 것입니다.
구성된 게이트 파이프라인에서 승인된 패치셋에 대해 모든 작업이 성공하면, Gerrit은 trunk로 코드를 병합할 것입니다.
게이트 테스트를 실행하는 것 외에도, 게이트 파이프라인은 여러 프로젝트들에 대해서 병합하기 위한 변경사항들의 순서를 결정합니다. 변경사항들은 이 순서에 따라 테스트되고 병합되므로, 각 변경사항에 대해 다른 모든 레포지토리의 상태를 확인할 수 있습니다.
여기서 각 작업들의 상태를 확인할 수 있습니다.
본 포스트는 다음 주소를 참고하였습니다.
'Cloud Computing > Openstack' 카테고리의 다른 글
| [OpenStack에 contribute하기 - 6] 실전 (2) (0) | 2020.01.27 |
|---|---|
| [OpenStack에 contribute하기 - 6] 실전 (1) (0) | 2020.01.27 |
| [OpenStack에 contribute하기 - 5] Gerrit 사용하기 (1) (0) | 2020.01.05 |
| [OpenStack에 contribute하기 - 4] Gerrit Account 구성하기 (0) | 2019.12.29 |
| [OpenStack에 contribute하기 - 3] Git (2) (0) | 2019.12.29 |
- Total
- Today
- Yesterday