[배포자동화구축] 0. 배포전략 세우기

 

 

기존에는 완성된 Spring boot앱을 AWS에 올려놓기만 했었는데 이번 프로젝트에서는 배포 브랜치에 푸시되면 자동으로 서버에 배포되는 자동화 라인을 구축해보고자 한다.

 

먼저 어떤 식으로 구성할지 배포 전략을 세워야 하는데, 배포 전략에 앞서 CI/CD 개념을 복기해 보자.

 

 

CI (Continuous Integration - 지속적 통합):

• 코드 변경으로 인한 문제를 조기에 발견하고 해결하여 품질을 향상할 수 있도록 코드 변경사항을 지속적으로 통합시킨다는 개념이다
• 개발자가 코드를 작성하고 변경사항을 버전 관리 시스템에 푸시하면, CI 서버가 이를 감지하고 자동으로 빌드 및 테스트를 수행한다

 

CD (Continuous Deployment - 지속적 배포):

• 코드 변경 사항이 테스트를 통과하면 자동으로 프로덕션 환경으로 배포되도록 한다

 

코드를 통합하기 전에 빌드/테스트를 수행해서 안전하게 통합될 수 있도록 하는 게 CI 개념이고, 이 과정이 성공적이면 자동으로 운영환경에 배포되도록 하는 것이 CD 개념이다. CI/CD를 통합해서 구축할 수도 있고 별개의 서버로 분리해서 구축할 수도 있다. 

 

 

1. 서비스 선택 

CI/CD를 구축하는 서비스들이 다양한데 우리는 Github Actions + Jenkins 조합으로 구성했다. 

• 구성이 간단하면서 무료인 서비스 
• Github, AWS와 연동이 유연한 서비스 
• Java/Gradle 환경을 지원하는 서비스 

 

세 가지를 고려하여 CI를 Github Actions로 구성하기로 결정했다. 

Github 설정에서 yml 파일만 작성하면 쉽게 구성할 수 있다는 점과 github과의 연동성이 좋다는 점에서 선택했다.

레파지토리 화면에서 바로 로그와 수행결과를 확인할 수 있고, PR에 이벤트를 걸어놓으면 PR화면에서도 수행결과가 바로 보인다는 점도 좋았다. 

CD는 Jenkins로 결정했는데 이전에 사용했던 경험이 있고 검색 시 관련 자료가 많다는 점에서 선택했다. 

 

2. 배포 전략 수립

먼저 우리 프로젝트의 git branch 전략은 main과 develop을 구분한다.

develop은 머지용 브랜치고 main은 배포용 브랜치다. 단계는 다음과 같다 

 

각 feature 브랜치들이 develop으로 머지하기 위해 PR을 올려 승인을 받는다

-> 승인을 받은 코드들만 develop에 머지되도록 한다

-> 현재 스프린트 단위에 해당하는 작업들이 계속해서 develop에 머지된다

-> 스프린트 단위가 끝나면 develop에서 main으로 푸시한다

-> main에는 프로덕션 환경에 반영되는 코드들이 유지될 수 있도록 한다

 

 

CI가 이뤄져야 하는 시점이 develop에 머지되거나 PR을 요청할 경우이고, CD가 이뤄지는 시점은 main 브랜치에 푸시되는 시점이다.

따라서 전략을 아래와 같이 정리하였다. 

 

 

✔️ CI

1. 코드 통합 브랜치인 develop 브랜치로 PR이 올라오거나 푸시되는 이벤트가 발생하면 Github Actions로 빌드(테스트)를 수행한다

2. Jacoco를 활용해 올린 코드의 테스트 커버리지를 확인한다 

 

 

✔️ CD

1. 배포용 브랜치인 main브랜치에 push 이벤트가 발생하면 github에서 webhook을 통해 jenkins가 설치된 서버로 요청을 보낸다

2. jenkins에서 web hook 요청을 수신하고 설정한 해당 repository로부터 clone을 받아온다

3. 내려받은 소스로 빌드를 수행한다

4. 생성된 jar파일을 운영서버(배포서버)에 publish over SSH 통신으로 전송한다

5. 운영서버에 있는 jar파일을 실행하는 배치 스크립트를 jenkins에서 백그라운드로 실행한다. 

 

 

3. CI/CD pipeline Diagram

 

위의 전략을 기반으로 작성한 다이어그램이다.

 

우리는 배포서버로 프리티어로 제공되는 용량만큼의 AWS EC2를 활용할 것이기 때문에, jenkins와 App서버를 나눠서 구성했다.

jenkins가 무거운 편이기 때문에 같이 구성하면 cpu가 과도하게 사용되어 부하가 일어날 수 있다고 생각했다.

 

JACOCO는 Java 언어용 테스트 커버리지 도구로 특정 메서드, 클래스 단위들이 얼마나 테스트되었는지 확인할 수 있는 도구다.

Github Actions를 구성할 때 간단하게 스텝으로 추가할 수 있어서 함께 구성하였다. 

 

이제 해당 다이어그램을 기반으로 서비스 배포를 완료해 보자. 😀