티스토리 뷰
Daylogs/Git
Git: Pull Request 가 들어오면 젠킨스로 테스트 돌리기 (Github Pull Request Builder)
ohgyun 2015. 1. 18. 00:09발생일: 2014.12.11
키워드: Travis CI, 깃헙, Git Hook, 깃훅, 깃헙 웹훅, Github Web Hook, Github Pull Request Builder, 젠킨스, Jenkins
문제:
회사에서는 깃헙 엔터프라이즈 버전을 쓰고 있고,
(당연한 이야기지만) 우리 프로젝트에서는 작업한 코드가 반영되려면 모든 테스트를 통과해야 한다.
테스트는 주요 브랜치에 커밋이 발생할 때, (예: 피처 브랜치를 디벨롭이나 마스터에 머지하는 경우)
깃헙 웹훅을 받아 빌드 서버에서 수행하고 있다.
초반에는 담당자가 개발 완료 후에 테스트를 돌려보고 확인한 후에 푸시하는 방식이었는데,
종종 테스트를 확인하지 않는 경우가 있어서 주요 브랜치에 머지가 된 후에야 테스트가 깨진 것을 확인할 때가 있었다.
어떻게 하면 개발자가 일부러 테스트 수행을 챙기지 않고,
테스트가 깨졌을 때에도 빨리 발견할 수 있을까 고민하다가,
Git Hook 으로 push 시점에 테스트를 돌리도록 만들어뒀었다.
이 방법은 꽤 효과적이었다.
푸시하려면 테스트를 꼭 통과해야 했기 때문에, 주요 브랜치에 테스트가 깨진 코드가 머지되는 일이 없었다.
테스트를 로컬에서 돌리고 푸시 시점에만 수행하는 거라, 개발 효율 측면에서도 좋았다.
그런데,..
프로젝트가 진행되어 가면서 테스트 코드도 많아졌고, 테스트 시간도 그만큼 늘어났다.
개발 리뷰 단계에서 잦은 주기로 푸시를 하거나, 핫픽스처럼 급히 반영되어야 하는 코드를 푸시하는 경우에도,
전체 테스트가 수행되는 것을 기다려야 해서 효율이 떨어지기 시작했다.
푸시 시점에 테스트 수행 시간이 너무 길다는 불만이 나왔다.
푸시 시점에 테스트를 돌리는 건 꽤 효과가 있었기 때문에 이 방식을 포기할 수는 없었고,
고민 후에 옆자리 D가 전체 테스트를 돌리는 대신 변경된 파일의 테스트만 돌리는 방식으로 개선했다.
효과가 있었다! 테스트 시간이 줄었고, 푸시할 때의 스트레스도 많이 줄었다.
몇 가지 아쉬운 점이 있긴 했다.
변경된 파일이 다른 파일의 테스트에도 잠재적인 영향을 끼칠 수 있었지만 이건 노운 이슈로 가기로 했고,
피처 브랜치의 상위 브랜치를 명확히 알기 어려워, 온전히 변경한 파일의 테스트만 돌리는 것에도 한계가 있었다.
그러다가, A가 자기가 진행하고 있는 오픈소스 프로젝트에 Travis CI를 적용해뒀고,
이 아이는 Pull Request 가 들어왔을 때 테스트를 돌려준다는 얘기를 들었다.
우리 빌드 서버는 젠킨스였다.
분명히 젠킨스에도 비슷한 게 있을 거라고 생각했고,
D가 Github Pull Request Builder 라는 플러그인을 찾아냈다.
여러 가지 환경적인 이슈가 있어서 적용하는데 꽤 걸렸는데,
주요 링크와 문제 해결에 대한 메모를 남겨둔다.
해결책:
플러그인을 적용한 건 정말 잘한 일이었다.
우리 팀은,
1. 작업할 때 피처 브랜치를 따서 작업하고,
2. 작업을 완료하면 develop 으로 Pull Request를 넣고,
3. 모든 팀원의 리뷰를 통과하면 머지하는 방식을 취하고 있다.
이 플러그인은 Pull Request 를 넣었을 때 테스트를 돌리고 테스트 결과를 페이지에 바로 보여주는데,
어차피 PR 이후에 리뷰가 완료되기까지는 꽤 시간이 필요하기 때문이 우리 프로세스에 완전히 적합했다.
플러그인을 적용한 후엔 이전의 Push Git Hook은 제거했고, 이제 엄청 빠르게 푸시할 수 있게 되었다.
심지어 푸시가 빨리 되니 어색할 정도다. ㅎㅎㅎ 좋구만!! ㅎㅎ
주요 가이드:
Github Pull Request Builder Plugin
깃헙에 Pull Request가 들어왔을 때 젠킨스에서 빌드를 수행할 수 있도록 도와주는 플러그인이다.
깃헙 웹훅 서버를 올리고, 깃헙에 웹훅을 등록하는 것까지 자동으로 해줘서 편리하다.
플러그인의 리파지터리
플러그인 페이지에 문서가 있긴 하지만, 깃헙 리파지터리에 있는 문서가 더 최신이고 설명도 자세하다.
Github Pull Request Builder 플러그인 설정 방법에 대한 가이드
리파지터리의 설명을 보고 잘 이해되지 않으면, 이 포스트의 글을 참고해보면 좋다.
스크린샷과 함께 설명하고 있어서 이해하기 쉽다.
문제해결:
- 깃헙 엔터프라이즈 버전의 웹훅 API 주소
깃헙 엔터프라이즈 버전을 쓰고 있다면, 웹훅의 API 주소가 깃헙의 것과 다르다.
아래 링크를 참고해서 API를 가져다 쓰면 된다.
- 깃헙에서 젠킨스에 떠있는 플러그인 웹훅 호출 시 요청 용량 관련 오류가 난다면
젠킨스를 구동하고 있는 서버에서 폼 요청의 사이즈를 제한하고 있을 수 있다.
젠킨스 구동 시 아래와 같이 옵션을 추가해서 폼 컨텐츠의 사이즈를 늘려줄 수 있다.
-Dorg.eclipse.jetty.server.Request.maxFormContentSize=5000000
- 댓글로 테스트 명령을 날렸을 때, `comment ignored`라는 오류가 나면서 수행되지 않을 때
봇 계정이 PR을 넣은 계정과 동일한 계정일 경우 테스트가 수행되지 않는다.
웹훅에 의해 동작하는 봇 계정을 봇 전용 계정으로 등록하면 해결할 수 있다.
- 설정은 다 잘 해두는 것 같은데, 뭔가 잘 되지 않을 때...
젠킨스를 리스타트 해보자… -_-;;
반응형
댓글
공지사항