스프링 9장 | 코드가 푸시되면 자동으로 배포해보자 - Travis CI 배포 자동화

미루미·2022년 8월 14일
0

springbootStudy

목록 보기
5/5

책을 읽으면서 공부한 내용입니다.
책 제목: 스프링 부트와 AWS로 혼자 구현하는 웹 서비스

9장에서 배운 내용 (책 368쪽)

9-1. CI / CD에 대한 소개
9-2. 깃허브의 무료 CI 서비스인 Travis CI에 대한 소개와 프로젝트 연동 방법
9-3. AWS의 CD 서비스인 CodeDeploy에 대한 소개와 프로젝트 연동 방법
9-4. 수동 배포 방식에서 자동화 방식으로의 개선
9-5. CodeDeploy에서 오류 로그를 보는 방법

8장까지의 내용으로는 개발자가 스크립트를 직접 실행해야 했다. Test & Build가 수동으로 진행되면 본인의 코드가 다른 개발자의 코드에 영향을 주진 않는지 직접 확인해야만 알 수 있다는 문제가 있다.

그래서 9장에서는 깃허브에 푸시를 하면 자동으로 Test & Build & Deploy가 진행되는 환경을 만들어 본다.

9-1. CI / CD에 대한 소개

보통 하나의 프로젝트를 여러 개발자가 함께 개발을 하기 때문에 코드를 합치는 일은 중요할 수밖에 없다. 코드 통합의 생산성을 높이기 위해 등장한 것이 바로 코드가 통합되는 환경(CI)이다.

CI(Continuous Integration)란 지속적인 통합으로, VCS 시스템에 PUSH가 되면 자동으로 테스트와 빌드가 수행되어 안정적인 배포 파일을 만드는 과정을 의미한다.

CD(Continuous Deployment)란 지속적인 배포로, 빌드 결과를 자동으로 운영 서버에 무중단 배포까지 진행되는 과정을 의미한다.

일반적으로는 CI와 CD가 함께 구축되어 있다.

깃허브와 같은 원격 저장소를 사용하면 푸시와 동시에 코드 병합이 이루어지고 테스트 코드와 빌드를 수행하게 되어 수동으로 코드를 통합하지 않아도 된다. 그러나 CI 도구를 도입했다고 CI를 하고 있는 것은 아니다.

[마틴 파울러의 블로그]에 의하면 CI에는 다음과 같은 4가지 규칙이 있다.(https://www.martinfowler.com/articles/originalContinuousIntegration.html)

  • 모든 소스 코드가 살아 있고(현재 실행되고) 누구든 현재의 소스를 접근할 수 있는 단일 지점을 유지할 것

  • 빌드 프로세스를 자동화해서 누구든 소스로부터 시스템을 빌드하는 단일 명령어를 사용할 수 있게 할 것

  • 테스팅을 자동화해서 단일 명령어로 언제든지 시스템에 대한 건전한 테스트 수트를 실행할 수 있게 할 것

  • 누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것

이때 중요한 것은 테스팅 자동화로, 지속적인 통합을 위해서는 이 프로젝트가 완전한 상태임을 보장해야 하고, 결국 테스트 코드가 구현되어 있어야만 한다.

9-2. 깃허브의 무료 CI 서비스인 Travis CI에 대한 소개와 프로젝트 연동 방법

  1. Travis CI 연동
    Travis CI는 깃허브에서 제공하는 무료 CI 서비스이다. Travis CI에 깃허브 계정으로 로그인하고 저장소를 활성화한다.

Travic CI의 상세한 설정은 프로젝트의 .travis.yml 파일에서 진행한다. 파일 확장자 YAML(야믈)은 JSON에서 괄호를 제거한 것으로 이해할 수 있다.

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:
      - 내 이메일 주소

master 브랜치에 커밋, 푸시를 하고 Travis CI 저장소 페이지를 확인한다. 빌드가 성공되었다면 이메일함으로도 빌드 성공을 확인한다.

2.Travis CI와 AWS S3 연동

S3란, AWS에서 제공하는 일종의 파일 서버로, 이미지 파일을 비롯한 정적 파일들을 관리하거나 배포 파일들을 관리하는 등의 기능을 지원한다.

2-1. Travis CI와 S3 연동
실제 배포는 AWS CodeDeploy 서비스를 이용하여 진행한다. 그러나 Jar 파일 전달을 위해 AWS S3와의 연동이 선행되어야 한다. CodeDeploy는 저장 기능이 없기 때문에 Travis CI가 빌드한 결과물을 받아서 CodeDeploy가 가져갈 수 있도록 보관하는 공간으로 AWS S3을 활용한다.

일반적으로 AWS 서비스에는 외부 서비스가 접근할 수 없기 때문에 접근 가능한 권한을 가진 Key를 생성해서 활용한다. 이러한 인증 관련 서비스로 IAM(Identity and Access Management)이 있다. 이 서비스를 통해 Travis CI가 AWS S3와 CodeDeploy에 접근할 수 있도록 한다.

9-3. AWS의 CD 서비스인 CodeDeploy에 대한 소개와 프로젝트 연동 방법

책에서는 CodeDeploy를 AWS의 배포 삼형제 중 하나라고 소개한다. Code Commit, Code Build, CodeDeploy가 배포 삼형제에 해당한다.

  1. Code Commit: 깃허브와 같은 코드 저장소의 역할을 한다.
  • 프리이빗 기능을 지원하지만, 깃허브에서는 무료로 프라이빗 지원을 하고 있기 때문에 거의 사용되지 않는다.
  1. Code Build: Travis CI와 같은 빌드용 서비스이다.
  • 멀티 모듈을 배포해야 하는 경우 사용하기도 하지만, 규모가 있는 서비스에서는 대부분 젠킨스나 팀시티를 이용하는 편이다.
  1. CodeDeploy: AWS의 배포 서비스이다.
  • 앞선 두 서비스와 달리 대체재가 없다.
  • 오토 스케일링 그룹 배포, 블루 그린 배포, 롤링 배포, EC2 단독 배포 등 많은 기능을 지원한다.
profile
미루미루지마

0개의 댓글