Jongbin Oh

I write something to think

2 minute read

작업 환경에 관련된 건 뭐든지 최악을 대비한다. 내가 없어도 원하는 건 할 수 있는 상황으로 만들어야 삶이 편하다. 우선은 돌아가니깐 출근 후에 관련된 일감(task)이나 메일을 보고 개선하거나 좀 더 두고 보는 결정을 하면 된다.

’Merge request approvals’ 기능을 켰다. 필요 승인자를 2명으로 설정했다. 여기서 걱정이 생긴다. 만약 승인자가 없는 경우에 merge 해야 할 상황이 생기면 어떻게 하나? 그래서 merge request에 댓글로 ’셀프 승인’을 달면 bot 계정이 나타나서 merge 하는데 필요한 승인을 하게 했다. gerrit은 더 느슨했다. merge 점수 제한이 2점일 경우 스스로 2점을 주고 merge 할 수 있었다.

제가 어제 퇴근 전에 merge 한 코드가 잘못됐습니다. 그래서 수정을 했는데, 시간이 조금 늦었죠. 동작하는 걸 확인하고 주위를 둘러보니 제가 올린 merge request를 승인할 수 있는 프로그래머가 없더라구요. 그래서 merge를 못 했습니다. 오늘 날짜 데일리 빌드는 클라이언트 크래시가 날 겁니다. 제가 올려놓은 merge request 좀 빨리 봐주세요. 아~ 빨리 한 명 더 와야 하는데.

개구멍은 만들어놨다. 적어도 이런 일을 벌어지지 않는다. 이제 좀 더 다듬을 차례다. KWH 팀장이 좋은 의견을 많이 줬다. ’셀프 승인’ 댓글 명령을 ’핫픽스’ 명령과 ’사소함’ 명령으로 대체했다. 동작이 아닌 의도를 나타낸다. 언제 써야 하는지 따로 설명할 필요 없다. bot이 나타나 merge request에 승인하고 난 후 slack 프로그래머 채널에 알리게 했다. 무분별한 사용을 막음과 동시에 사용법도 알려주는 용도였다.

리뷰를 염두에 둔 커밋을 만드는 게 가장 큰 장점이라 생각한다. 2점 이상 돼야 merge 할 수 있는 규칙. 커밋을 올린 사람도 2점을 줄 수 있는 느슨한 규칙을 사용했다. 느슨한 규칙을 사용했어도 리뷰를 염두에 둔 커밋을 만들 게 된다는 건 코드 품질 향상에 크게 기여한다고 생각한다. - #gerrit #codereview 사용 소감

그래도 다른 사람 확인 없이 merge 할 수 있게 하는 건 막아야 하지 않을까요? 코드 리뷰가 가진 가치 중에 방점을 어디에 두느냐에 따라 개구멍에 대한 태도가 다르다. 팀 전체 코드 품질 유지를 가장 큰 가치로 생각한다면 거부감이 들 수도 있을 것 같다. 난 리뷰를 염두에 둔 커밋을 만드는 것 자체가 가장 큰 장점이라고 생각해서 스스로 merge 할 방법을 열어놔도 문제없다고 생각한다.

jenkins를 사용했다. gitlab webhook을 추가하고 댓글이 달릴 때마다 발동되게 했다. jenkins gitlab 플러그인에서 댓글을 필터링해서 jenkins job을 시작한다. 봇 계정 personal access tokens를 사용해 merge request를 승인했다. 사용한 jenkins 플러그인은 HTTP Request. slack 채널에 알리는 건 slack notification 플러그인을 사용했다.

링크

You May Also Enjoy