지속적 통합 분야에서 가장 유명한 서비스는 아마도 Travis CI인 것 같다. 내 경우에는 소프트웨어 시험이 아닌 이 블로그의 빌드 테스트를 위해 처음 사용하기 시작했었는데, Go 프로그래밍을 시작한 이후에는 소프트웨어 빌드 시험을 위해서도 사용하고 있다. 작년 후반에 만들었던 “현천” 프로젝트의 OAuth2 인증 서비스인 UART의 기반을 업그레이드하다가, 기반환경 및 Travis CI를 이용한 시험 과정에서 문제가 생겨서 하루를 꼬박 이 화면에서 살았다. 생각난 김에, 오늘을 기준으로 이 서비스의 화면을 기록으로 남긴다.

Travis CI

Travis CI는 간결하고 직관적인 웹 인터페이스를 제공하는 인터넷 기반의 지속적 통합(Continuous Integration) 서비스의 이름이다. 독일에 기반한 회사인데, 팀 소개 페이지에 가보면 다국적의 50여 명의 목록을 볼 수 있다. 뭐랄까… 이제 인터넷을 기반으로 한 소프트웨어 회사에게 국경은 큰 의미가 없달까?

Travis CI는 무료로 사용할 수도 있고 기업용 서비스를 제공하기도 한다. 기업서비스는 사용해보지 않았기 때문에 알지 못하지만, 무료로 사용하는 버전만으로도 기능적으로 모자람이 없는 것 같다. 단지, 모든 것이 완전 공개되기 때문에 오픈소스 프로젝트가 아니라면 조금 꺼리긴 하겠다. 내 경우, 나의 모든 프로젝트가 오픈소스이기 때문에 크게 부담되는 부분은 없다.

아! 그리고 공사장 모자를 쓴 로고가 참 인상적이다!

Travis CI 서비스 소개

가장 재미있는 특징 중 하나가, 이게 Github와 “궁합이 잘 맞는다”가 아닌 “Github 없이는 못살아” 구조라는 점이다. 기업용 버전은 모르겠는데 일반 사용자가 오픈소스 빌드를 위해서 사용하는 경우, Github를 이용한 로그인과 연동만을 제공한다! 좀 어리둥절하기도 하고…

그리고 이런 Github와의 강한 결합 위에서 거의 100만 개에 육박하는 오픈소스 프로젝트가 이 CI 서비스를 쓰고 있다고 한다.

제공하는 기능은 대표적으로 아래와 같다. Github와 연동하여 Commit/Push를 기반으로 CI가 자동 동작하며, Push 외에도 Pull Request에도 반응하도록 설계되어 있다. 또한 Heroku와 연동하여 바로 배포(Deployment)를 할 수도 있고(물론, 사용자 설정을 통해 다른 후속작업도 가능하지만) Slack 등을 통해 통합/배포 결과를 알림으로 받을 수도 있다. (당근 메일도 온다)

Build Flow

가장 기본이 되는 Build Flow는 다음과 같다.

먼저, 수정한 내용을 Github에 Push하면, 미리 설정한 연결에 의해 Github는 Travis CI에게 Trigger를 준다. Travis CI는 Trigger에 의해 빌드 Job을 자동으로 시작하게 되고, 최종적으로 (그리고 선택적으로) Heroku Deploy나 Slack 알림을 주게 된다. (그리고 Github에게도 그 정보가 전달된다.)

Pull Request에 대해서도 기본적으로 동일한 동작을 하게 되는데, Trigger에 의해 빌드가 끝나면 그 정보가 Github에게 전달되게 된다.

이 PR(Pull Request) 부분을 좀 더 풀어서 보면, 가령 내가 어떤 오픈소스 프로젝트에 기여를 하고 있고, 내 작업 결과를 원래의 Upstream에 반영하기 위해 PR을 날렸다고 가정해보자. 만약 원래의 프로젝트가 Travis CI 같은 서비스를 사용하지 않는다면 프로젝트의 Maintainer 등은 PR을 받아서, 빌드 시험을 직접 해보고 이 PR이 원본의 동작에 문제를 일으키지는 않는지 검증해야만 한다. 하지만 이 길고도 번거로운 단순작업을 Travis CI가 대신 해주고, 심지어 그 결과를 Github에게 알려줘서 PR 화면에서 직접 확인을 할 수 있도록 해주기 때문에 프로젝트의 Maintainer에게는 무척 편리한 기능이 아닐 수 없다. (안 쓰면 바보)

화면 잡아두기

10년 후에 추억하기 위해서, (뭐라?) 지금의 화면을 하나씩 담아두었다.

Profile

Github 인증을 통해 Travis CI에 로그인하고 Profile 페이지에 가보면, 다음과 같은 모양의 화면을 만나게 된다. 간단한 절차 설명 등이 가운데 나오고, 왼쪽으로는 내 Token 정보와 함께 내가 소속된 (그리고 Grant한) Github의 조직명이 나열된다.

화면 중앙의 저장소 목록에는 ‘X’ 표시가 있는 스위치가 표시되는데, 이걸 켜면 그 저장소에 대해 Travis CI가 통합 작업을 할 수 있게 된다. 위의 내 개인 저장소에는 보이지 않지만, 아래의 조직 화면을 보자.

이 화면은 화면 왼쪽의 조직을 클릭했을 때 보여주는 화면인데, 기본적으로 사용자 Profile 화면과 동일하다. 단지, 조직에 대한 저장소를 표시한다는 점이 차이인데, 맨 위의 Goul처럼 Travis CI를 사용하는 저장소는 스위치 색과 마크다 다르게 보인다.

Github 조직 연동

위에는 세 개의 조직만 보이지만, 사실 내게는 더 많은 조직이 있다. (활발하게 개발을 하는 것도 아닌데, 프로젝트를 조직으로 관리하다보니 좀… 그렇다.) 여기에 세 개만 보이는 것은 내가 그렇게 허용 범위를 조정했기 때문인데, 만약 새로 추가하고 싶은 조직이 있다면 왼쪽의 조직목록 아래에 있는 “Review and add” 링크를 누르면 된다.

아래 화면은 이 링크를 클릭했을 때 만나는 화면인데, 이건 Travis CI의 화면이 아닌 Github의 화면이다.

화면 상단을 보면 Travis CI 로고와 이름이 보이고, (Github 입장에서는 Travis CI는 하나의 연동된 App, 또는 서비스이다.) 이 서비스에게 허용된 권한 목록이 표시된다. 또한, 오른쪽 상단을 보면 “Revoke Access” 라는 버튼이 있는데, 이 버튼을 누르면 두 서비스의 연결이 끊어지게 된다.

그리고 중앙의 아래 부분에는 내가 Github에서 속해있는 조직 목록이 열거되어 있는데, 조직명 옆에 녹색 체크가 있는 것은 이미 연동이 허용된 세 개의 조직이며, 빨간색 X표가 있는 것은 Travis CI가 아직 접근할 수 없는 조직이라는 의미이다. 목록 오른쪽의 Grant 부분은… 말이 필요 없지만 접근을 허용하는 버튼이고. (이건 Github가 3rd-Party와 연동하는 일반적인 내용이고 이 글의 범위는 아니긴 하다.)

Dashboard

편의를 위해 Profile 화면을 먼저 봤지만, Travis CI에 접속하고 처음 만나는 화면은 아래와 같다. 이 화면에는 내가 별표한(Github의 별표는 아니고, 여기 자체적인 별표다) 저장소와 전체 저장소가 죽 나열되고, 각각의 빌드 상태가 표시된다.

이 화면에서 “Trigger a build” 기능을 실행하면, 현재 저장소를 기준으로 (새로운 Commit이 있든 없든) 새로운 빌드를 실행하게 된다. 아래와 같이, Hooray! 신나게 시작한다!

여기서 목록에 표시된 사용자명 또는 조직명을 클릭하면 아래와 같은 조직 상태 화면으로 이동하게 되고,

해당 조직에 속한 저장소만 따로 보여주게 된다.

Repository (Project)

이 화면에서 개별 저장소를 클릭하거나 앞선 화면에서 저장소명을 클릭하게 되면 아래와 같은 저장소 (프로젝트) 페이지로 이동하게 되는데,

Current

저장소 페이지의 맨 첫 화면은 가장 최근의 빌드 결과를 보여주는 Current 화면이다.

이 화면에서는 최종 빌드 결과, 빌드에 걸린 시간, 언제 빌드했는지 등과 Git 저장소의 어떤 Branch의 어떤 Commit을 사용한 빌드인지 등을 확인할 수 있고, 각 부분을 클릭하면 Github로 바로 넘어가게 된다.

만약, 하나의 Trigger에 의해 둘 이상의 작업이 진행되었다면, 아래와 같이 로그 대신 각각의 빌드 작업 목록이 표시된다.

이렇게 둘 이상의 작업을 실행하는 것은 Travis CI의 설정에 의해 가능한데, 오늘의 글은 이 부분을 다루지는 않을 것이다. 간략하게 설명만 하자면, 위의 프로젝트는 Go 언어로 작성된 프로그램이며 Go 1.9 버전과 Go 1.10 버전 두 버전으로 동일한 소스를 빌드하고 각각의 버전에 대한 호환성을 검증하는 것에 해당한다.

Branches

만약, 하나의 프로젝트에서 여러 Branch에 대한 빌드가 일어난다면 아래와 같이 각각의 Branch에 대해 별도의 결과를 보여준다. 아래는 깨끗하지만, 활발한 개발이 이루어지는 프로젝트라면, 그리고 개발 Branch의 완결성을 보장하지 않는 경우라면, 개발 Branch의 경우에는 빨간색 박스가 많이 보일 수 있다. (아! 녹색의 체크가 무슨 뜻인지는 뭐… 설명을 안 해도…)

Build History

그 옆으로는 Build History라는 메뉴가 있는데, 이건 조금 더 자세하게, 위에서는 각각의 빌드가 박스 하나로 표시되었지만, 조금 더 자세히 각각의 빌드에 대한 정보를 보여주게 된다. 내용은 Dashboard에서 이미 봤던 것과 유사한데, Branch명, Commit 로그 등을 추가로 보여준다.

이러한 정보와 함께, 빌드가 성공했는지 성공했는지, 취소되었는지 지금도 돌고 있는지 등도 함께 확인이 가능하며, 각 항목을 클릭하고 들어가면 각각의 빌드에 대하여 Current에서 봤던 것과 동일한 모양의 상세 정보를 볼 수 있다.

Pull Request

눈으로 보이는 마지막 탭 메뉴는 Pull Requests 이다.

만약, 참여자가 많고 PR이 많이 일어난다면 여기도 꽤 많은 줄이 있겠지만, 이 경우, 개인 프로젝트이고 PR을 단지 기능적으로 사용하다 보니 줄 수가 많이 않다.

Settings

메뉴 탭의 오른쪽을 보면 More options 라는 버튼이 보인다. 자주 쓰지 않는 기능을 모아둔 곳으로, 그 곳에 숨겨진 메뉴 중 하나가 Settings이다.

위와 같은 화면에서 언제 빌드를 할 것인지, 특정 상황에서 어떻게 반응할 것인지를 포함하여 빌드 시 사용할 환경변수 등을 설정하거나 주기적인 빌드를 구성할 수 있는 설정화면이 제공된다.

Requests

Requests 역시 흔하게 쓰지 않으므로 숨겨진 메뉴인데, 가끔은 Trigger가 정상적으로 동작했는지 확인하고 싶을 수 있다. 이 화면에서는, 언제 어떤 작업이 시작되고 진행되었는지 확인이 가능하다.

좀 다른 부분은, 앞서 살펴본 작업 화면에서는 빨간색이 많았는데 여기는 온통 녹색 뿐이다. 이 화면은 작업의 성공여부와 무관하게 작업 자체가 잘 만들어졌는지에 집중하는 화면이기 때문에 그런 것인데, 일종의 Travis CI 자체에 대한 상황판인 샘이다.

Builds

마지막으로, 개별 작업에 대한 정보를 확인하는 화면을 보면 아래와 같다. 아래의 예는 정상적으로 빌드가 완료된 작업을 보여주는데, 앞서 본 것과 같이 두 개의 작업이 하나로 엮여서 보여지고 있다. (하나의 Trigger에 의한 두 개의 작업이라는 의미)

만약 아직 종료되지 않은 작업이라면, 아래와 같이 약간 다른 모습으로 보인다.

특히, 상태 상자 오른쪽에 “Cancel job” 버튼이 위치해 있는데, 이 버튼을 누르면 진행 중인 작업을 중단할 수 있다. (뭐랄까, 잘못된 작업임을 알면 멈춰주는 것이… 공짜 리소스를 쓰는 사용자의 기본이랄까…) 완료된 작업의 경우, 이 위체에 “Restart build” 버튼이 놓이는데, 이 버튼의 경우, 이 버튼을 누르면 최신의 Commit이 아닌 이 작업에서 사용한 Commit에 대해 작업을 반복해서 진행하게 된다.

작업 로그

성공한 경우에는 크게 사용할 일이 없을 수 있지만, 만약 작업이 실패한 경우라면 이 작업 로그가 큰 도움이 된다. 이 작업 로그에는, 내 프로그램의 빌드 로그 뿐만 아니라, Travis CI가 제공하는, 작업에 사용했던 환경에 대한 정보가 함게 담겨있기 때문에 빌드 환경의 파악, 문제점의 파악 등을 위해 활용할 수 있다.

글씨가 작아 잘 보이지는 않지만… 위를 보면, Worker information, Build system information 등으로 구분되어 다양한 작업환경 정보가 담겨있다. 가령, Worker 정보를 보면 이 작업이 실행된 서버가 gce, 즉 Google Cloud의 Compute Engine 위에서 동작했다는 것을 알 수 있으며, 이 때 사용된 Travis CI의 환경에 대한 정보도 얻을 수 있다. 또한, 빌드 환경이 Trusty 버전의 Ubuntu이며 Git 2.15.1을 사용했고, Gcc 4.8.4을 사용한다는 것도 확인할 수 있다. (너무 많은 정보가 들어있는데, 적당히 줄였다. :-)

Github와 Travis CI, 티내기

아무튼, 여차 저차 빌드가 잘 되었다면 그 ‘티’가 나야 하는데, 그게 Travis CI에 접속해서 확인해야 한다고 하면… 프로젝트를 가지고 있는 당사자는 그렇다고 치고, 그걸 사용하려는 사람에게는 무지 불편한 일이다. 아니, 프로젝트 소유자 입장에서도 그건 꽤 불편한 일이다.

3rd Party Badges

이건 어디서 많이 보던 모습 아닌가? (Github 등을 이용하는 개발자라면 매우 눈에 익은 모습이다.)

저렇게 프로젝트 설명 아래 배지가 주루룩! 붙어있다. 맨 첫번째 배지가 바로 빌드 상태를 나타내는 Travis CI의 배지이고, 그 다음은 프로그램 작성 규칙 등을 얼마나 준수하는지 등을 표시하는 Go Report Card, 그리고 산맥 모양의 아이콘이 그려진 두 개의 배지는 전반적인 Code 품질과 Test Coverage 등의 관리를 도와주는 Code Climate이며, 마지막의 것은 Test Coverage 관리도구인 Coveralls의 배지이다.

어라? 왜 배지를 줘? 정보를 바깥으로 안 주고 사이트에 와서 보게 해야 Page View도 올라가고 방문자도 올라가서 장사가 되는 거 아닌가? 그런데 반대로, 이렇게 많은 개발자들이, 자신의 정보를 쉽게 확인하고 사용자에게 쉽게 알리기 위해 자발적으로 배지를 달도록 유도함으로써, 그 많은 개발자가 Travis CI 같은 회사의 자원봉사 선전원이 되고 전도사가 되어, 보다 널리 자신을 알리는 효과가 매우 클 것이니 생각을 뒤집어보면 오히려 이런 방식이 더 효과적인 것이라고 생각한다. (사실, 나만 해도, Travis CI든 Code Climate 든 어디서 찾았겠니. Github 저장소 돌아다니다 배지 본 거지.)

Commit Status Indicator

물론, 보다 기술적인 통합도 제공한다. 아래 화면은, Github에서 Commit History를 확인하는 화면인데, 그림에서 보는 바와 같이 각 Commit의 Meta 부분에 녹색 체크, 빨간 X, 노랑 점 등의 아이콘이 표시되는 것을 볼 수 있다.

공식적인 명칭은 확인하지 않았지만, HTML Tag에 붙은 Class 명칭을 보면 Commit Status, Commit Indicator 등의 이름으로 불리는 것 같다.

이 부분이 빨간 X로 표시되는 것은, 연결된 통합 서비스 중 정상적이지 않은 내용이 포함된 경우이고(MySQL 연결과 관련된 문제로 근래의 CI 시험이 모두 실패했다.) 노랑 점은 아직 진행중인 작업이 있음을 의미한다. (아래에 아직 노란 색으로 남아있는 것은 중간에 취소했다든지… 여타의 이유로 CI 정보 수신이 정상적이지 않은 것이다.)

이렇게, Github 화면에서 각 Commit에 대한 CI 실행 결과를 한 눈에 볼 수 있다는 점은 개발자나 프로젝트 관리자에게 여간 편리한 기능이 아닐 수 없다.

문 닫기

Travis CI는 정말 멋진 서비스이긴 하다. 딱 하나만 빼면 완벽한데, 아쉬운 그 한 가지는… 넉넉한 분량의 문서화가 잘 되어있기는 한데, 문서가 이미 오래되어 현재의 서비스를 반영하지 못한 부분이 있다거나… 문서의 설명과 다른 동작을 보이는 부분이 존재한다는 점이다.

하지만, 아래와 같이, API, Web, Build Processing 등의 상세한 서비스 상태를 손쉽게 확인할 수 있도록 제공하고 있다는 점에서 “인터넷 기반 서비스가 갖춰야 할 기본요소에 대한 모범을 보이고 있다는 점을 높이 사서,… 나 이렇게 Status 페이지를 갖추지 않은 인터넷 서비스, 클라우드 서비스를 무지하기 싫어라 한다. …, 높아 사서, 문서의 오류는 눈감아주기로 했다.

긴 글, 끝.

참고 URL