Chapter 09. 코드가 푸시되면 자동으로 배포해 보자 - Travis CI 배포 자동화 (1)

9.1 CI & CD 소개

8장에서 스프링 부트 프로젝트를 간단하게 EC2에 배포해 보았다. 스크립트를 개발자가 직접 실행함으로써 발생하는 불편을 경험했다. 그래서 CI, CD환경을 구축하여 이 과정을 개선하려고 한다.

근데 CI, CD 이랑 무엇일까? 코드 버전 관리를 하는 VCS 시스템(Git, SVN 등)에 PUSH가 되면 자동으로 테스트와 빌드가 수행되어 안정적인 배포 파일을 만드는 과정을 CI(Continuous Integration - 지속적 통합)라고 하며, 이 빌드 결과를 자동으로 운영 서버에 무중단 배포까지 진행되는 과정을 CD(Continuous Deployment - 지속적인 배포)라고 한다.

 

일반적으로 CI만 구축되어 있지는 않고, CD도 함께 구축된 경우가 대부분이다. 왜 이렇게 CI/CD란 개념이 나왔을까?

 현대 웹 서비스에서는 하나의 프로젝트를 여러 개발자가 함께 개발을 진행한다. 그러다 보니 각자가 개발한 코드가 합쳐야 할 때마다 큰 일이었다. 그래서 매주 병합일(코드 Merge만 하는 날)을 정하여 이날은 각자가 개발한 코드를 합치는 일만 진행했다. 이런 수작업 때문에 생산성이 좋을 수가 없었으며 개발자들은 지속해서 코드가 통합되는 환경 (CI)을 구축하게 되었다. 개발자가 각자가 원격 저장소(깃허브나 깃랩 등)로 푸시가 될 때마다 코드를 병합하고, 테스트 코드와 빌드를 수행하면서 자동으로 코드가 통합되어 더는 수동으로 코드를 통합할 필요가 없어지면서 자연스레 개발자들 역시 개발에만 집중할 수 있게 되었다.

 

CD 역시 마찬가지이다. 한두 대의 서버에 개발자가 수동으로 배포를 할 수 있지만, 수십 대 수백 대의 서버에 배포를 해야 하거나 긴박하게 당장 배포를 해야 하는 상황이 오면 더는 수동으로 배포할 수가 없습니다. 그래서 이 역시 자동화하게 되었고, 개발자들이 개발에만 집중할 수 있게 되었다.

 

여기서 주의할 점은 단순히 CI 도구를 도입했다고 해서 CI를 하고 있는 것은 아니다. 마틴 파울러의 블로그를 참고해 보면 CI에 대해 다음과 같은 4가지 규칙을 이야기한다.

• 모든 소스 코드가 살아 있고(현재 실행되고) 누구든 현재의 소스에 접근할 수 있는 단일 지점을 유지할 것
• 빌드 프로세스를 자동화해서 누구든 소스로부터 시스템을 빌드하는 단일 명령어를 사용할 수 있게 할 것
• 테스팅을 자동화해서 단일 명령어로 언제든지 시스템에 대한 건전한 테스트 수트를 실행할 수 있게 할 것
• 누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 파일을 얻었다는 확신을 하게 할 것

여기서 특히나 중요한 것은 테스팅 자동화이다. 지속적으로 통합하기 위해서는 무엇보다 이 프로젝트가 완전한 상태임을 보장하기 위해 테스트 코드가 구현되어 있어야만 한다.

 

CI와 CD가 툴을 하나씩 적용해보자

 

9.2 Travis CI 연동하기

Travis CI는 깃허브에서 제공하는 무료 CI서비스이다. 젠킨스와 같은 CI도구도 있지만, 젠킨스는 설치형이기 때문에 이를 위한 EC2 인스턴스가 하나 더 필요하다.

 이제 시작하는 서비스에서 배포를 위한 EC2 인스턴스는 부담스럽기 때문에 오픈소스 웹 서비스인 Travis CI를 사용하겠다.

 

Travis CI 웹 서비스 설정

https://travis-ci.org/에서 깃허브 계정으로 로그인 한 뒤, 오른쪽 위에 [계정명 -> setting]를 클릭한다.

 

설정 페이지 아래쪽을 보면 깃허브 저장소 검색창이 있다. 여기서 저장소 이름을 입력해서 찾은 다음, 오른쪽의 상태바를 활성화시킨다.

 

활성화한 저장소를 클릭하면 저장소 빌드 히스토리 페이지로 이동한다.

Travis CI 웹사이트에서 설정은 이게 끝이다. 상세한 설정은 프로젝트의 yml파일로 진행해야 하니, 프로젝트로 돌아가겠다.

 

프로젝트 설정

Travis CI의 상세한 설정은 프로젝트에 존재하는 .travis.yml 파일로 할 수 있다. 여기서 잠깐 처음 보는 파일 확장자 .yml가 있다. .yml파일 확장자를 YAML(야믈)이라고 한다.

아마 웹 개발을 했으면 JSON에 친숙할 텐데, YAML은 쉽게 말해서 JSON에서 괄호를 제거한 것이다. YAML 이념이 "기계에서 파싱하기 쉽게, 사람이 다루기 쉽게"이다 보니 익숙하지 않은 사람도 읽고 쓰기 쉽다. 그러다 보니 현재 많은 프로젝트와 서비스들이 이 YAML을 적극적으로 사용 중이다. Travis CI 역시 설정을 이 YAML을 통해서 하고 있다.

그럼 Travis CI설정을 진행해 보겠다. 프로젝트의 build.gradle과 같은 위치에서 .travis.yml을 생성한 후 다음의 코드를 추가한다.

language: java
jdk: 
  - openjdk8
    
branches:
  only:
    - master
      
# Travis CI 서버의 Home
cache:
  directories:
    - '$HOME/.m2/repository'
    - '$HOME/.gradle'
      
script: "./gradlew clean build"

#CI 실행 완료 시 메일로 알람
notifications:
  email:
    recipients: 
      - 본인 메일 주소

① branches
 - Travis CI를 어느 브랜치가 푸시될 때 수행할지 지정한다.
 - 현재 옵션은 오직 master 브랜치에 push될 때만 수행한다.

② cache
 - 그레이들을 통해 의존성을 받게 되면 이를 해당 디렉토리에 캐시 하여, 같은 의존성은 다음 배포 때부터 다시 받지 않도록 설정한다.

③ script
 - master 브랜치에 푸시되었을 때 수행하는 명령어이다.
 - 여기서는 프로젝트 내부에 둔 gradlew을 통해 clean & build를 수행한다.

④ notifications
 - Travis CI 실행 완료 시 자동으로 알람이 가도록 설정한다.

 

여기 까지 마친 후, master 브랜치에 커밋과 푸시를 하고, 좀 전의 Travis CI 저장소 페이지를 확인한다.

 

빌드가 성공한 것이 확인되면 .travis.yml에 등록한 이메일을 확인한다. -> 메일로도 전달받는다.

 

 

출처 : 스프링 부트와 AWS로 혼자 구현하는 웹 서비스 [이동욱 지음]