인프런 커뮤니티 질문&답변

안녕하세요, 팥빙수님
답변이 늦어져 죄송합니다.

상당히 어려운 질문을 주셔서, 고민을 많이 했습니다.

CI/CD를 단순히 GitHub Actions나 다른 툴로 코드화하는 것보다,
어떻게 CI/CD 프로세스를 설계할지가 훨씬 어려운 영역이라고 생각합니다.

제 답변이 명확한 정답은 아닐 수 있지만, 조금 더 풀어서 설명드리겠습니다.

참고만 부탁드리겠습니다.

저는 트렁크 베이스 방식을 하나의 main 또는 master 브랜치를 중심으로 작업하는 것으로
이해하고 있고, 이를 전제로 말씀드리겠습니다.

현재 강의를 보면 dev 브랜치와 master 브랜치를 사용하고,
tagging을 통해 QA 환경으로 배포를 트리거하는 구조를 사용하고 있습니다.

이 방식의 단점

단순한 변경 사항을 배포하기 위해 많은 프로세스가 필요하다는 점입니다.
예를 들어:

1. feature 브랜치에서 dev 브랜치로 PR을 생성하고, 머지하여 개발 환경으로 배포

2. dev 브랜치에서 QA 환경으로 배포하려면 tagging을 트리거

3. QA 확인 후 master 브랜치로 PR을 생성하고 머지하여 운영 환경으로 배포

위 과정을 거치면서 시간이 많이 소요되고, 이미지 빌드도 3번이나 진행해야 합니다.

트렁크 베이스에서의 CI/CD 간소화

반면, 트렁크 베이스 방식을 사용하여 main 브랜치를 중심으로 작업하면
프로세스가 훨씬 간단해집니다.

만약 환경별로 배포되는 애플리케이션의 환경변수만 다르고 나머지가 동일하다면,
이미지는 한 번만 빌드해도 되고, 각 환경별로 환경변수만 다르게 설정하면 됩니다.
이를 통해 변경사항을 개발 환경부터 운영 환경까지 적용하는 과정이 간소화될 수 있습니다.

트렁크 베이스 방식의 핵심은 작은 변경 사항을 짧은 주기로 main 브랜치에
머지하여 관리한다는 점인데요.

이때, 아래와 같은 고려사항 등에 대한 고민과 논의가 필요합니다.

a. Hotfix 처리 방법

• 운영 중 긴급 변경 사항 (hotfix) 발생할 때 어떻게 처리할 지

b. Main 브랜치의 환경 보장

• 여러 환경에서 정상 작동 보장하려면 강력한 CI 테스트 파이프라인 필요

c. 환경별 배포 제어

환경별로 브랜치를 관리한다면, dev branch가 개발 환경
master 브랜치가 운영 환경이므로 각 브랜치가 보장하는 환경이 있습니다.

그리고 명시적인 트리거가(dev branch, qa tag, master branch) 있기에
환경별 배포를 제어할 수 있습니다.

트렁크 베이스에서의 CI/CD 는 어떻게 구성해야할까

잘 알고 계시겠지만, 앞에서는 필요하다고 느껴지는 부분에 대해 간략히 설명드렸고

질문 주신 내용에 대한 답변은 여기서 다루게될 것 같습니다.

배포할 애플리케이션이 컨테이너화 되어있고, EKS에 배포된다라고 가정해보겠습니다.
(현재 강의가 이 구조입니다)

트렁크 베이스 기반 CI/CD에서는 환경별 배포를 어떻게 제어할 것인지에 대한 부분이

중요하다고 생각합니다.

예를 들어, 깃헙액션으로만 cicd를 처리하는 경우를 생각해보면 어느정도 한계가 있습니다.

main branch에 PR이 머지될 때, 깃헙액션이 트리거 되어 테스트를 거쳐서
이미지를 빌드하는 워크플로우를 구성했다고 해보겠습니다.

그러면 이 빌드된 이미지를 각 환경에(dev,qa,prod) 한번에 적용하고 싶을수도 있고

먼저 dev에만 반영해보고 싶을수도 있습니다.

이런 많은 케이스를 깃헙액션으로만 제어하기가 쉽지 않습니다.

그래서 깃헙액션과 추가적인 CD 도구를 결합하면, 이런 부분을 개선할 수 있습니다.

예를 들어 main branch에 PR이 머지될 때 이미지 빌드는 1번만 하고,

해당 이미지를 사용할 지 말 지는 사용자가 제어하도록 하는 방법입니다.

깃헙액션에서는 이미지 빌드까지 진행하고, 실제로 배포 여부는 CD 에 의해서

제어되도록 하는 구조입니다.

혹시라도 ArgoCD에 대해서 배경지식이 있으시다면, 아래 내용이 좀 더 수월하게 느껴지실 것 같아서 코드로 설명 이어서 드리겠습니다.

안녕하세요, 인프런 AI 인턴입니다. 팥빙수님.

트렁크 베이스 개발(Trunk Based Development, TBD)은 모든 개발자가 하나의 메인 브랜치를 중심으로 작업하는 방식으로, 효율적이고 빠른 배포를 지원하는 CI/CD 구성을 필요로 합니다. 트렁크 베이스 방식에서의 CI/CD 구성을 설명해드리겠습니다.

트렁크 베이스 개발의 CI/CD 구성

1. 자동화된 테스트: 모든 커밋에 대해 자동으로 테스트가 실행되도록 설정합니다. 이는 코드 품질을 유지하고, 즉각적인 피드백을 제공하여 빠른 오류 수정을 가능하게 합니다.

2. 병합 빈도를 높임: 작은 단위의 변경 사항을 자주 병합하여 충돌을 최소화합니다. GitHub Actions를 이용해 Pull Request(Pull Request)는 자주 처리되도록 설정합시다.

3. Feature Toggles 사용: 새로운 기능을 개발하면서 코드베이스에 병합할 때, 아직 준비되지 않은 기능을 비활성화 상태로 유지할 수 있도록 Feature Toggle을 사용합니다.

4. 자동화된 배포: 병합이 완료되면, CI/CD 파이프라인에 따라 QA 환경으로 자동 배포가 이루어지도록 설정합니다. 충분한 테스트 후 운영 환경으로의 배포도 자동화합니다.

5. 블루/그린 배포나 카나리 배포: 빠르고 안전한 배포를 위해 블루/그린 배포나 카나리 배포 전략을 고려합니다. 이는 운영 환경에서 새로운 기능을 안전하게 배포하는 데 도움이 됩니다.

유사 질문의 참고 게시물

• 도커 볼륨 vs RDS, 롤백
  
• Tag를 이용한 QA 환경 배포와 워크플로우 구성 질문
  

이 게시물들은 GitHub Actions를 이용한 배포 전략과 관련된 다양한 접근 방식을 다루고 있으며, 트렁크 베이스 개발 방식을 계획하는 데 유용한 정보를 얻으실 수 있을 것입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.