About Travis CI

Jesang Yoon
Dec 27, 2016 · 5 min read

GitHub를 메인 저장소로 쓰는 개발자라면 Travis CI에 대해서 한번쯤은 들어봤을것 같다. Travis CI는 GitHub와 딱 맞추어 동작하는 CI (Continuous Integration) 서비스로서 Jenkins 처럼 설치하지 않는 대신 매달 일정량의 돈을 내고 Travis CI에서 제공하는 인프라 위해서 Build나 Deployment를 할수 있다.

만일 본인의 저장소가 오픈소스이거나 GitHub이거나 iOS앱 빌드가 필요하다면 이 서비스를 활용해 보기를 적극 추천한다. 우리팀은 2016년 중순부터 적극적으로 도입을 시작했는데 매우 만족스럽게 사용중이다. 가격이 약간 세다는 점을 감안한다면 GitHub를 사용하는 사람의 입장에서 다음과 같은 요건을 가장 잘 만족하는 CI가 아닌가 싶다.

Managed Service가 주는 관리의 편리함

써본 사람은 알지만 Jenkins를 쓰면 유지보수도 하나의 업무가 된다. Jenkins 서버에 갑자기 문제가 생기는 바람에 발생하는 야근은 각오해야 한다. 그래서 우리는 On-Demand Managed Service를 사랑할수 밖에 없다. 왜냐면 서버시스템 유지보수 = 잡일에 드는 고민은 남에게 맡기고 온전히 우리 제품의 개발 및 유지보수에만 집중할수 있기 때문이다.

.travis.yml 이 제공하는 Build 설정의 투명성

Jenkins의 GUI로 Job설정을 하는 일은 편리하긴 하지만 설정이 실제로 어떻게 되어 있는지, Job끼리 설정이 얼마나 차이가 나는지 명시적으로 확인하기가 쉽지 않다. 가장 큰 문제는 Jenkins 서버가 날아갔을때 Job설정을 복구거나, 설정이 수정된 이력을 추적하는게 어렵다는 것이다. 따라서 재현가능한 설정을 스크립트 형태로 Source 저장소에 넣어두고 투명하게 공개하는 것은 매우 중요하며 Travis CI는 이게 매우 쉽다.

GitHub와의 Seamless 한 통합

Team 단위로 Software Quality 관리를 잘 할려면 Unit Test와 Style/Lint Check를 Build에 포함시키고 이를 통과한 코드만이 master에 merge 되도록 강제하는 것이 중요하다. GitHub는 이를 위해서 지정된 branch에 대해서 merge나 push를 제한하는 여러가지 기능을 제공하는데 이중에 status check를 잘 활용하는걸 추천한다. status check는 GitHub와 연동되는 CI에서 해당 commit/PR에 대한 Build Job이 실패할 경우 merge를 하지 못하도록 제한을 거는 기능이다.

이 기능에 위 사진처럼 Travis CI를 물려 놓고, 해당 저장소의 .travis.yml 안에 Style/Lint Check 또는 Unit Test를 삽입해 두면 이 저장소에 PR이나 commit을 날리는 모든 멤버의 코드에 대해서 Travis CI에서 자동으로 status check을 수행하고 그 결과를 GitHub에 보여주게 된다. 따라서 Maintainer들이나 commit/PR의 owner가 자신의 코드가 Quality를 만족하는지 아닌지를 바로 알수 있게된다.

많은 Reference

Travis CI는 2011년에 시작하여 현재 5년 이상 운영되는 서비스이고, 아래 Article을 참조했을때 현재 CodeShip과 함께 CI 분야에서 1, 2위를 다투고 있다.

우리팀의 기술 Stack 선정 조건엔 Reference가 얼마나 있으냐, 사용하는 다른 Stack과 얼마나 잘 연동 되느냐를 보는 부분이 있는데 이 면에서 Travis CI는 구글 검색으로 44만건 정도의 레퍼런스가 나오고, 우리팀이 쓰는 Atlassian JIRA On-Demand와 DVCS 연결이 매우 용이하며(Jenkins 처럼 연결하면 된다) Slack과의 연동도 쉽다. 따라서 누가 물어봐도 우리와 비슷한 Stack를 사용한다면 굳이 고민할 필요가 없다고 말해주고 싶다.


물론 Jenkins가 제공하는 다양한 Customization를 생각한다면, 기능의 수만을 비교한다면 Travis CI엔 아직 부족한 부분이 많다. 게다가 Repository 기준으로 Build가 이루어지기 때문에 기존에 Job기준의 Build에 익숙한 분들은 처음에 좀 어려울수 있다. 그렇지만 아파치 계열 소프트웨어들을 포함하여 수많은 오픈소스들이 Travis CI + GitHub위에서 오늘도 Build되어 제공되고 있다는 점을 생각해본다면 사실 Jenkins 만큼의 Customization과 복잡함이 그렇게 필요하지는 않을지도 모른다. 이미 있는 Legacy를 Jenkins에서 이곳으로 이전하는 것은 어렵겠지만 만약 새로 만드는 프로젝트이며 GitHub로 저장소를 옮기는걸 고민한다면 한번 사용을 생각해 봤으면 좋겠다.

좀더 정보가 필요하다면 아래 글을 참조해도 좋다.

HardBoiledSmith Stories

DevOps & QA 자동화 전문 스타트업 HBSmith의 Blog - https://hbsmith.io

Jesang Yoon

Written by

Co-Founder & CTO of HBSmith, Software Developer

HardBoiledSmith Stories

DevOps & QA 자동화 전문 스타트업 HBSmith의 Blog - https://hbsmith.io