Practice : Gerrit Git Review with Jenkins CI Server

[SangHee Kim]

Jenkins CI는 필연적으로 다른 시스템들과 연동되어서 사용됩니다. (간단한 예, Jenkins Ci + VCS) 그러한 조합중에 Gerrit code review 라는 리뷰 시스템과의 연동에 대해서 2011년에 만들어진 10분짜리 동영상이 있는데 청취를 권합니다.

http://alblue.bandlem.com/2011/02/gerrit-git-review-with-jenkins-ci.html

간단히 설명을 드리자면 1) 개발자가 Gerrit 으로 Git을 이용하여 커밋을 하면 2) Jenkins 가 이를 가져다가 간단한 빌드나 테스트를 하고 3) 그 결과를 Gerrit 에 알려주어 코드 리뷰에 도움을 주는 방법입니다.

실제 이 방법을 구글이나 퀄컴등에서 안드로이드 개발에 사용하고 있습니다. 단지 CI 서버를 어떤걸 쓰느냐 (예, Jenkins, Electric Commander 등...)와 빌드와 테스트의 구성이 각 회사마다 다를뿐입니다.

위에 사용된 시스템들은 아래 링크에서 확인 가능합니다.

- Gerrit : http://code.google.com/p/gerrit/

- Git : http://www.git-scm.com/

[joonhee park]

형상관리 통합전 빌드검증이 자동화되고 코드리뷰 프로세스와 연계되는 것이 장점이죠.
이상적으로 생각하면 검증된 코드만 형상에 통합되어 문제있는 코드의 전파를 막을 수 있습니다.

커밋에 대한 빌드점수를 주는 방법도 연계할 수 있는데 CI game plugin 이라고 있습니다.

다만 모든 도구와 프로세스가 그러하듯이 조직이 동의하고 수용하는데는 여러 어려움이 있습니다.
최근에 저희가 컨설팅하고 구축하였던 고객사에도 가이드 하여드렸지만, 관리자들한테 쪼임의 구실이 될 것을 우려해 거부하더군요.

[Kyunam Jo]

2011년에 해당시스템을 저희회사에 도입할때도 마찬가지 이유로 반대하는 사람들이 많았습니다 저희경우는 결국 호의적인 집단과 연계하여 성과를 보여주고 일일이 설득하여 지금은 긍정적인 사람들이 많아지고 해당 프로세스도 어느정도 자리잡았지요 ^^ 그러나 아직도 많은 사람이 부정적인식을 가지고있는게 현실입니다 ㅎㅎ

[SangHee Kim]

조직의 모든 부서나 구성원의 동의나 호의를 얻어서 수행할 수 있는 일은 매우 적습니다. 제 경우 괜찮다고 생각하는 구성원이 비교적으로 많은 곳부터 시작합니다. 그곳에서 성과를 내서 전파를 하면 더 나은 결과가 생깁니다.

다시 말하자면 일단 내가 해보고, 내 주변 사람들과 해보는 과정을 몇 달 해보면 '이 프로세스가 쓸만한가 아닌가?' 에 대한 답이나 보완해야 하는 것들이 나옵니다. 그 상태에서 공유를 통해 호의적인 사람들이 많은 파트부터 전파를 해서 다시 답과 보완책을 구하는 과정을 가져가면 성공확률이 높아집니다. 이러한 과정은 시간이 오래 걸리지만 1) 성공확률이 상당히 높아지고 2) 착안점이나 보완점을 많이 발견할 수 있는 장점이 있습니다.

말씀하신 '관리자들에게 쪼임의 구실' 에 해당하는 부분은 기술적인 부분보다는 심리적인 컨설팅 부분으로 풀어야 하는 면이 있는것 같습니다. 이 부분에 대해서는 아래 링크에 있는 서적들이 도움이 된다고 생각합니다.

http://www.ac2.kr/reading

2013년 2월 3일 일요일 오후 12시 19분 57초 UTC+9, joonhee park 님의 말:

[joonhee park]

와우 읽어야 될 책들이 많네요~

파일럿을 수행하고 적용 후 객관적으로 성과를 평가한 다음 개선하고 확산하는 단계를 가져가는 것에 대해 동의합니다.

다만, 계약과 일정을 가지고 움직여야 하는 외부 업체 입장에서 공유와 전파의 시간을 얻어내기가 여의치 않고,

내부 성원들의 동의를 구해가는 과정에 대해 영향을 끼치는데 한계가 있습니다.

사전 교육과 심리적인 컨설팅이 답이기는 한거 같습니다.

좋은 자료 감사드립니다.

2013년 2월 4일 월요일 오전 9시 49분 24초 UTC+9, SangHee Kim 님의 말:

[Sunjoo Park]

Svn 의 Commit, git 의 push 단계가 완료되기 이전에 chaned code 들이 빌드를 깨먹지는 않는지, 혹은 정해진 Rule를 지키고 있는지를 검사하고

그걸 만족하지 않는 경우는 코드를 받아들이지 않는 역할..일명 Gate Keeper 역할을 하는 것이라고 할 수 있을겁니다. 

문제는 이 역할을 실행하는 단계에서 Respone time 을 최대한 줄이기 위해선 다음의 두가지가 먼저 필요하다는 것이지요

1.   Build script 구조에 다른  Buid time 

2.  물리적인 시스템의 지원

1번이야 사람들의 머릴ㄹ 돌리면 얼마든지 가능하겠습니다만,

2번은 돈이랑 관련있는 거라서, 생각보다 무작정 늘리기가 복잡합니다. ..@_@ 

윗분들의 쪼임..어찌보면 돈 그리고 실적이랑 연관있는 부분들이 많아서요..ㅠ.ㅠ

[SangHee Kim]

안녕하세요 .선주님 (맞나요?)

말씀하신 물리적인 비용의 문제는 CI 에 명시된 단점입니다.

http://en.wikipedia.org/wiki/Continuous_integration#Advantages_and_disadvantages

따라서 해당 부분은 플랫폼의 특성 (예, 빌드 시간, inspection 의 복잡도, test 성숙도) 에 따라서 비용 스펙트럼이 넓습니다. 이러한 면 때문에 문제가 되는 경우는 제 경우 대개 1) 비용 대비 기대치가 높거나 2) 한번에 너무 많은 것들을 하려고 할 때 생겼습니다.

만약, 빌드나 테스트 서버의 확장에 예산등으로 제한적인 요소가 있다면 아래와 같이 하는 것도 좋은 방법입니다.

- 커밋 단위 빌드와 테스트가 아닌 시간단위와 커밋 묶음 단위로 빌드와 테스트 (예, 5개의 커밋이 들어오거나 20분에 한 번씩 빌드와 테스트 돌리기)

제가 일전에 테스트 한 결과 fail rate 가 20% 미만이여서 위와 같은 경우 비용을 상당히 줄일 수 있었습니다. 다만, build or test fail 시에 묶여있는 커밋중에 어떤게 문제가 있는지 나눠서 빌드하는 단계가 필요하겠구요. 일전에 미국의 대규모 칩 벤더에 갔을때 빌드와 테스트를 이와 유사하게 진행하길래 그 아이디어에서 차용해서 해본건데 상당히 괜찮았습니다.

더불어 제 생각에 gerrit 을 사용하는데 빌드가 response time 에 큰 문제를 준다면, 그것은 리뷰와 같은 인간이 개입해야 하는 과정이 제대로 수행되지 않고 있는게 아닐까 합니다. Gerrit 의 주 목적은 code review 입니다. 그것을 CI의 한 부분으로 사용하는 것이구요.

덧. SVN용은 Rietveld 라는 Gerrit 의 부모뻘 되는 오픈소스 툴이 있습니다. 또한 Gerrit 은 push 가 완료되기 전이라기 보다 Gerrit 에 push 된 커밋을 Main repo 에 merge 하기 전에 리뷰와 테스트 하는거라 생각됩니다. (실제 구조 자체가 그렇구요)

2013년 2월 9일 토요일 오후 10시 59분 18초 UTC+9, Sunjoo Park 님의 말:

[SangHee Kim]

준희님 안녕하세요.

2013년 2월 5일 화요일 오전 10시 44분 35초 UTC+9, joonhee park 님의 말:

와우 읽어야 될 책들이 많네요~

파일럿을 수행하고 적용 후 객관적으로 성과를 평가한 다음 개선하고 확산하는 단계를 가져가는 것에 대해 동의합니다.

다만, 계약과 일정을 가지고 움직여야 하는 외부 업체 입장에서 공유와 전파의 시간을 얻어내기가 여의치 않고,

내부 성원들의 동의를 구해가는 과정에 대해 영향을 끼치는데 한계가 있습니다.

맞습니다. 외부 업체와 같은 경우 단기간에 서베이를 하고 구현해서 교육하고 전파까지 해야하니 그 부분은 저의 경험과 다른 면이 있을거라 생각합니다. 이러한 부분은 '갑'이 1) 전파할 대상을 최대한 작게 잡고, 2) 도입하려는 의지가 있는 대상을 선정해줘야 할 의무가 있다고 생각합니다. 혹시 나중에 같이 일하게 될 경우가 있다면 이 부분은 같이 노력하면 좋을것 같습니다. (4년 안에는 없어요 ㅠㅠ)

 

사전 교육과 심리적인 컨설팅이 답이기는 한거 같습니다.

좋은 자료 감사드립니다.

제가 관련 분야를 만으로 5년간 하면서 가끔 이런 생각을 했습니다. '정말 돈과 시간만 있으면 되나?' 결국 '돈도 있어야 하고, 인지 심리학에 기반을 두고 사람들을 몰아가는 능력'도 필요하다 였습니다. 그 부분에서 저기에 열거된 책들이 도움이 될 것 같습니다. 저는 저기에 있는 책들중에 열 권 정도 접한 것 같습니다.

[Sunjoo Park]

1. 

좋은 말씀 감사합니다. ^^ 저의 주 고민은 리소스에 대한 통제권이 제 손을 벗어나 있다는것에 기인하는  문제이지요.

대부분의 기업에서 장비신청을 위해서 예산을 짜서 올리거나 이만큼 필요하다고 해서 올려봤자, 예산부서나 윗선에서 짤리는 경우가 좀 많습니다..ㅠ.ㅠ 

그러면서 요구사항은 그대로인 케이스가 되면..정말 답이 안나오지요...;; 머신수가 줄어들었는데 모든 Commit 에 대해서 빌드 검증을 해달라거나

저장 공간은 그대로인데 모든 결과물을 저장해 달라거나...;; 답이 안나옵니다...

2. 

Gerrit 의 주 목적이 Code Review  일 수는 있겠습니다만, 코드가 main  branch  에 들어오기 전에 만족해야할 내용을 검증하는 역할 역시 포함되어야 합니다. 

그래서 Gerrit 에서도 Review/Verify 가 나누어져 있지요. 물론 적용은 사용하는 사람들의 몫입니다만. 

Build Time의 경우는 Source 의 사이즈, 모듈화 같은 것에 영향을 많이 받는 부분이라 Code Review 만으로 걸러 내기에는 한계가 있습니다. 

[Sunjoo Park]

아참..말씀하신대로 gerrit에서는 push전에 검증하는 차원이 아니라.

 refs/for/[branch name] 으로 push를 보내서 review 용 브랜치에 내용을 push한 후 해당 브랜치에서 내용 검증이 끝나면 [branch name]에 머지하는 것이 맞습니다. 

그런데 svn에 익숙한 분들에게 이렇게 설명하면 svn 의 branch와 혼동하시는 분들이 많아서, 전 주로 'target branch 에 push 하기 전, 사전 검증을 한다'라는 식으로 

설명하고 있습니다. ^^