CICD 파이프라인 구축기(1) - 브런치 전략과 GITACTION

시작하면서

이번 포스팅에서는 백엔드 서버의 CI/CD를 GitHub Actions를 사용하여 구축한 경험을 공유하고자 합니다. 저희 백엔드 서버는 Spring Boot, Gradle, Kotlin으로 개발된 API 서버이며, AWS EC2를 활용하여 운영하고 있습니다. 개발 환경은 PRD(Production)와 DEV(Development)로 나누어 구성하였습니다. 아래 포스팅에서는 전략과 개념을 설명하고, 각 스크립트는 각각의 포스팅에서 별도로 소개합니다.

브랜치 전략

효율적인 개발을 위해 저희 팀은 다음과 같은 브랜치 전략을 설정하였습니다: dev, prd, feat/??, hotfix/??.

• 기본 브랜치: dev와 prd는 각각 개발 및 운영 환경을 나타냅니다.
• 기능 브랜치: feat/??는 새로운 기능 개발을 위한 브랜치이며, hotfix/??는 긴급 수정이 필요할 때 사용됩니다. 이 브랜치들은 dev 브랜치를 기준으로 생성되며, 이슈가 발생할 때마다 생성되고 삭제됩니다.

작업이 완료된 feat/?? 및 hotfix/?? 브랜치는 dev 브랜치로 PR(Pull Request) 및 머지를 진행합니다. 이후 dev 브랜치에서 변경 사항을 테스트한 후, 문제가 없다면 PRD로 PR 및 머지를 진행합니다.

프로젝트의 규모가 작고 초기 단계인 만큼, 단순하면서도 강력한 프로세스를 필요로 했습니다. 따라서 꼭 필요한 요소만 남기고 간결하게 구성하였습니다.

GitHub Actions

1. Git Actions VS Jenkins

CI/CD 파이프라인 구축에 있어 GitHub Actions와 Jenkins사용을 고려햤습니다. Jenkins는 플러그인 기반으로 다양한 언어와 도구와 통합할 수 있는 유연성을 제공합니다. 하지만 Jenkins를 사용하기 위해서는 별도의 서버에 Jenkins를 설치해야 하고, 이를 위해 관리자 웹 사이트에 접근할 수 있도록 설정하는 과정이 필요합니다. 이 과정은 초기 설정이 복잡하고 시간이 소요될 수 있습니다.

반면, GitHub Actions는 GitHub 저장소 내에서 직접 YAML 파일로 워크플로를 정의할 수 있어 간편하게 설정할 수 있습니다. 무료로 사용할 수 있으며 GitHub과의 통합 덕분에 PR, 이슈와 관련된 작업을 자동으로 처리할 수 있는 장점도 있습니다.

결론적으로, Jenkins는 유연하지만 복잡한 설치와 설정이 필요하며, GitHub Actions는 직관적이고 통합이 용이하여 GitHub Actions를 선택하게 되었습니다.

 

2. 주요개념

• 워크플로: CI/CD 프로세스를 정의하는 YAML 파일로, 특정 이벤트가 발생했을 때 자동으로 실행됩니다. 워크플로는 여러 개의 작업(jobs)으로 구성됩니다.
• 작업 (Job): 워크플로 내에서 수행되는 일련의 단계입니다. 각 작업은 독립적으로 실행될 수 있으며, 다른 작업에 의존성을 가질 수 있습니다.
• 스텝 (Step): 작업 내에서 실행되는 개별 명령어로, 스크립트 또는 액션을 포함할 수 있습니다.
• 액션 (Action): GitHub Actions의 재사용 가능한 구성 요소로, 특정 작업을 수행하는 독립적인 코드 블록입니다. 오픈 소스 커뮤니티에서 다양한 액션을 제공하여 쉽게 활용할 수 있습니다.
• 시크릿 (Secrets): 민감한 정보를 안전하게 저장하고 사용할 수 있는 기능으로, API 키나 비밀번호와 같은 정보를 보호하는 데 사용됩니다.
• 이벤트 (Event): 워크플로를 트리거하는 GitHub에서 발생하는 활동입니다. 예를 들어, PR 생성, 푸시 이벤트 등이 있습니다.

3. Job

CICD 구축을 위해 배포단계를 3가지 job으로 나누어 구성하였습니다. 각 job의 상세한 스크립트는 다음 포스팅에서 다루겠습니다.

• Verification : 모든 테스트 코드를 통과하는지 확인하는 단계입니다. PR이 올라오면 verification 단계를 거치며, 통과할 경우에만 자동으로 머지됩니다.
• Deploy : 변경 사항이 dev 또는 prd에 머지되면, 소스를 빌드하여 JAR 파일을 생성합니다. 이를 AWS의 특정 위치에 업로드합니다.
• Run : 클라우드의 JAR 파일을 실행하는 단계입니다. 미리 aws 인스턴스에 등록해둔 배포 스크립트를 실행합니다.

활용 예시

개발자가 게시글 신고 기능을 신규로 개발한다고 가정하겠습니다.

1. 이슈 등록: 개발자는 GitHub 이슈에 개발할 내용을 정리하고, 작업자를 할당합니다.
2. 브랜치 생성: 개발자는 dev 브랜치에서 feat/report 브랜치를 생성합니다.
3. 변경 사항 푸시: 개발자는 feat/report 브랜치에서 변경 사항을 push하고 dev 브랜치로 PR을 올립니다. 
   • 3.1. GitHub Actions: verification을 수행하고 통과하면 dev에 자동으로 머지됩니다.
   • 3.2. GitHub Actions: verification -> deploy -> run이 진행되어 dev 환경으로 서비스가 배포됩니다.

 

4. 기능 테스트: 개발자가 dev 환경에서 기능을 테스트한 후 문제가 없으면 prd에 PR을 올립니다.

• 4.1. GitHub Actions: verification을 수행하고 통과하면 prd에 자동으로 머지됩니다.
• 4.2. GitHub Actions: verification -> deploy -> run이 진행되어 prd 환경으로 서비스가 배포됩니다.

4. 고려할 사항

1. 민감 정보 관리

배포 과정에서 민감 정보를 안전하게 관리하는 것이 중요합니다. 저희는 GitHub Actions의 Secrets 기능을 사용하여 AWS EC2의 접속 정보와 S3 접속 정보를 안전하게 관리하고 있습니다. 이 정보들은 .gitignore 파일에 포함되어 Git에 올라가지 않도록 하고 있습니다. 테스트와 구동을 위해 AWS 연결 정보가 필요했으므로, 설정 파일의 크기가 크지 않은 현재 프로젝트에서는 프로퍼티 파일을 통째로 Secrets의 변수로 저장합니다. 필요할 때 특정 장소에 불러와 프로퍼티 파일을 생성하는 방식으로 처리하고 있습니다.

2. 백업 파일 관리

배포 과정에서 생성된 백업 파일은 AWS 서버 내에 저장하고 있어, 문제가 발생했을 때 쉽게 복구할 수 있도록 하고 있습니다. 그러나 백업 파일이 많이 쌓이면 서버의 성능에 영향을 줄 수 있으므로, 주기적으로 불필요한 백업 파일을 삭제하는 프로세스를 고려해야 합니다.