[Travis CI] Travis 맛보기 (2) Travis와 Github를 연동하고 CI 환경을 구축하면 어떤 일이 일어날까?

이 글은 Travis CI 맛보기 시리즈의 2부작으로 구성되어 있습니다.

1. Travis-CI 에 가입하고 Github Repo와 연동하고 CI를 맛보자.

2. Travis와 Github를 연동하고 CI 환경을 구축하면 둘 사이에 어떤 일이 일어날까?

   서로 내용을 보완하고 있는 관계이므로 한 번 해당 포스팅으로 가서 가벼운 마음으로 읽는 것을 추천드립니다.

주의! 이 글은 전 글과 이어집니다.

---

지난 시간에 우리는 많은 것을 했다.

 

Travis CI에 가입도 하고 ,Github Repo와 연동도 하며 직접 .travis.yml을 작성해 CI를 구축을 맛보기도 했다.

 

오늘은 우리가 지난 시간과 같은 일을 수행하면 travis는 내부적으로 어떤일들이 일어나는지 확인해보자.

 

우선 Travis CI에 대해서 먼저 알아보자.

Travis CI

트래비스는 인터넷 기반의 지속 통합 서비스 CI 임.

 

Travis CI는 무료로 사용하기도 하고, 기업용 서비스는 유료로 제공하기도 함.

하지만 개인적으로 CI 도구로써 무료로 제공되는 CI도 충분히 좋다고 봄.

CI가 하는 일 빌드, 테스팅, 배포

1. 빌드를 실행하면 트래비스는 Github 저장소를 새로운 환경으로 복제
2. 테스팅 (만약 실패하면 빌드 실패)
3. 웹서버나 컨테이너에 코드를 배포.
4. 알림 설정등 여러 작업으로 추가 제공

위와 같은 일을 Travis CI 대신 수행하는데, 지난 시간에 우리는 이 과정을 통해서 어떤 일이 일어나는지 알아보았다.

이 과정을 Build Flow라고 하는데,

Build Flow

1. Push github
2. 연결된 Travis로 Github의 Trigger
3. Travis의 Github Clone
4. Build Job 수행.
5. 선택적으로 AWS나 Heroku에 배포
6. 결과를 메일이나 슬랙으로 전달.

Push github

사용자가 Travis와 Github를 상호 연결시켜주면, Travis는 Github에 있는 .travis.yml에 정의되어 있는 브랜치를 확인한다.

그리고 사용자의 Push 이벤트를 감지한다.

연결된 Travis로 Github의 Trigger

사실 이벤트를 감지한다는 것은 Github가 해당 브랜치의 형태를 감시하고 Travis로 Trigger를 보내는 것이다.

Travis의 Github Clone

Travis는 Github의 원격 저장소를 내부로 Clone한다.

Build Job 수행.

Build Job을 수행한다.

Build Job이라고 하면, .travis.yml 파일에 정의된 Travis의 워커 빌드를 수행하는 것과 같다.

아래에서 좀 더 자세히 알아볼 것이다.

선택적으로 AWS나 Heroku에 배포

선택적으로 AWS나 Heroku에 배포한다.

보통은 AWS의 CodeDeploy에 배포를 진행하는데, 자세한 사용은 AWS 카테고리의 CodeDeploy 세션을 보면 될것 같다.

대충 잠깐 보여주자면 다음과 같은 Flow로 진행된다.

1. travis가 S3에 에 업로드
2. travis가 CodeDeploy한테 명령어 스크립트를 전달해주면서 CodeDeploy가 배포 시도
3. CodeDeploy는 traivs한테 온 명령어 스크립트를 실행해서 S3로 파일을 가져온 뒤 배포 작업 시작
4. CodeDeploy는 AWS EC2랑 연동 가능한데, CodeDeploy는 S3한테 받은 파일을 해당 인스턴스에 넣고 EC2내부에 있는 배포 스크립트 실행
5. CodeDeploy가 EC2 내부에 정의된 배포 스크립트를 실행해서 EC2 내부적으로 배포 진행.
6. EC2 내부 정의된 배포 스크립트는 무중단 배포 가능하게 스크립트 작성됨.

결과를 메일이나 슬랙으로 전달.

그리고 결과를 메일이나 슬랙으로 전달할 수 있는데, 이 과정이 바로

.travis.yml에 있는

notifications: # 성공 실패 여부 알림
  email:
    recipients:
      - xxx@xxx.com

에 설정된 정보로 이 과정을 수행한다.

Pull Request Flow

이와 비슷한 맥락으로 Pull Request Flow도 존재한다.

하지만 이번에 이야기할 내용과는 조금 거리가 있기 때문에, 대충 맥락을 이야기해주자면 다음과 같다.

 

오픈 소스의 Maintainer는 Contributor가 PR을 보낸 코드를 직접 검증하지 않아도 Travis가 대신 빌드를 수행해주는 과정도 제공한다.

이는 다음에 알아보도록 하자.

---

Travis는 Build Job에 다음과 같은 워커 빌드를 수행한다.

Travis.yml에서 Travis CI 워커의 빌드 수행 과정

1. 언어 런타임 변경
2. Github 에서 클론
3. before_install 스크립트 실행
4. 클론 받은 디렉토리로 이동하고 의존성 설치 명령어 실행
5. after_install 스크립트 실행
6. before_script 스크립트 실행
7. test script 명령어 실행 (성공하면 0 리턴 아니면 모두 실패)
8. after_script 스크립트 실행(옵셔널)

이렇게 우리의 빌드가 Continuouse Integration이 수행된다.

 

하지만 지난 시간에도 말 했듯,  Travis CI는 CI 도구이지 배포와 관련된 작업을 수행하기 위해선 다른 도구가 필요하다.