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

안녕하세요 메가님~

질문에 대한 답변드리겠습니다.

강의에서는 GitHub Actions 기반의 여러 CICD 시나리오를 보여드리기 위해 되도록 간단한
시나리오로 구성했습니다.

1번 질문에 대한 답변을 드리면 QA 배포 시, 수정 사항이 발생할 때마다 버전을 올려서 사용하는 방식으로도 가능합니다.

A 기능을 개발 환경에 배포한 후, v1.0.0 태깅하여 QA 환경에 배포하고
A 기능을 업데이트하여, 다시 개발 환경에 배포한 후, v1.0.1 태깅하여 QA 환경에 배포할 수 있습니다.
현재 강의 구성으로는 수정이 발생할 때마다 이렇게 버전을 업데이트해야 동작하는 구조로 되어있습니다.

그런데, 이 방식이 과연 실무에서도 적합할지에 대한 의문이 생기실 수 있습니다.
그래서, 이 질문을 바탕으로 실무에서 활용할 수 있는 좀 더 유용한 구조를 설명드리고자 합니다. 아래는 강의 내용을 조금 벗어나지만, 실무에서 자주 사용되는 방식 중 하나입니다.

시나리오의 방식처럼 구성해서 실무에서 사용하는 데에는 어려움이 있을 수 있습니다.
특히 수정 사항이 잦거나 여러 기능이 동시에 QA 환경에서 테스트되어야 할 경우, 관리가 복잡해질 수 있습니다.

실무에서는 각 회사와 팀의 배포 전략, 워크플로우 복잡도에 따라 CICD 설계 방식이 달라지기 때문에 정확한 답은 없지만, 하나의 예시를 통해 이해를 도울 수 있도록 설명드리겠습니다.

2024년 11월 30일에 특정 서비스에 여러 기능(A, B, C)을 추가하여 v5.0.0 버전을 운영 환경으로 배포하기로 일정이 정해졌다고 가정하겠습니다.

최종적으로 원하는 구조는:

• release/v5.0.0 브랜치에서 QA 환경 배포가 반복적으로 이루어지고, 최종적으로

  master 브랜치로 병합하여 운영 환경에 반영되는 것입니다.

이를 위해 릴리즈 브랜치와 RC 태그(Release Candidate 태그)를 활용합니다.

• 릴리즈 브랜치: QA 환경에서 테스트를 통과한 안정적인 상태를 유지하며, 운영 환경 배포를 준비하는 역할을 합니다.

• RC 태그: QA 환경 배포 시점마다 관리되어, 각 배포의 상태를 명확히 기록하고 문제를 추적하기 쉽게 합니다.
  

1. A 기능 개발 및 QA 환경 배포

먼저 A 기능이 개발되어 개발 환경에 배포가 완료된 상태입니다.
이를 QA 환경에 배포하기 위해 v5.0.0-rc.1 태그를 사용하여 GitHub Actions를 트리거하고,
A 기능을 QA 환경에 배포합니다.

QA 환경 배포가 성공하면 release/v5.0.0 브랜치가 생성됩니다.
이 시점에서 release/v5.0.0 브랜치는 A 기능에 대한 코드만 포함하고 있습니다.

2. QA에서 수정 사항 반영 및 재배포

QA 환경에서 A 기능 테스트 중 문제가 발견되었다면, A 기능을 수정하는 커밋을 추가하여
수정된 코드를 QA 환경에 다시 배포하기 위해 v5.0.0-rc.2 태그를 사용합니다.

이 과정에서 release/v5.0.0 브랜치에는 A 기능뿐만 아니라 수정된 코드가 추가됩니다.
QA 테스트는 A 기능이 QA 환경에서 안정적으로 동작할 때까지 이 과정을 반복하며,
최종적으로 release/v5.0.0 브랜치는 A 기능과 모든 수정 사항을 포함하게 됩니다.

3. B & C 기능 개발 및 QA 환경 배포

A 기능에 대한 QA 테스트가 완료된 후, B와 C 기능이 각각 개발되어 개발 환경에 배포됩니다.
이후 B와 C 기능을 QA 환경으로 배포하기 위해 v5.0.0-rc.3 태그를 사용하여 QA 환경에 배포합니다.

이때 B와 C 기능에 대한 커밋은 순차적으로 release/v5.0.0 브랜치에 추가됩니다.
QA 환경에서는 A, B, C 기능이 모두 포함된 상태에서 통합 테스트가 진행됩니다.

QA 테스트 중 문제가 발견될 경우, 이를 다시 수정하는 커밋을 추가한 후 새로운 rc 태깅(ex. rc-4)을 통해
QA 환경에 배포합니다.
그리고 새로운 rc 태깅의 커밋은 release/v5.0.0 브랜치에 반영되도록 구성합니다.

4. QA 테스트 완료 후 운영 환경 배포

모든 QA 테스트를 통과한 후, release/v5.0.0 브랜치는 최종적으로 안정적인 상태가 됩니다.
이제 이 브랜치를 운영 환경 배포를 위해 master 브랜치로 병합합니다.
운영 환경에서는 최종 릴리스 태그(예: v5.0.0)를 사용하여 배포가 진행됩니다.

이런 구조를 활용한다면, QA 환경에서 버전을 매번 올릴 필요가 없고 필요한 기능이 모두 포함된
버전을 운영 환경에 반영할 수 있습니다.

처음 강의를 계획할 때, 이 내용으로 강의를 구성하려 했습니다.
그런데, 생각보다 내용이 복잡합니다.
특히 말로 설명하기엔 더 어려운 부분이 있어서 강의에서는 간단한 시나리오로 구성했습니다.

추가적으로 질문 주신다면, 좀 더 쉽게 이해하실 수 있도록 설명드리겠습니다.

이어서, 2번에 대한 답변을 드리겠습니다.

질문 주신 워크플로우 파일의 관리 방식은 선택사항입니다.

잡이 추가될수록 워크플로우 파일의 복잡성이 증가하기 때문에, 필요에 따라 파일을
분리하는 것도 좋은 방법입니다.

예를 들면, PR이 open or synchronize 되는 경우에는 CI.yaml을 구성해서 테스트만 실행하고
PR이 merge 되는 경우에는 CD.yaml을 구성해서 배포만 진행할 수 있습니다.

어떤 방식이 더 적합한지는 팀의 CICD 설계와 작업 흐름에 따라 다릅니다.

일반적으로는 하나의 파일로 구성하는 경우가 많지만, 복잡성이 증가할 경우 파일을 분리하는 것이 더 효율적일 수 있습니다.

안녕하세요, 인프런 AI 인턴입니다. 메가님.

강의에서 다루고 있는 CI/CD와 태그를 통한 배포 전략에 대한 궁금증이 있으시군요.

말씀하신 시나리오처럼, 특정 커밋에 태그를 붙여서 QA 환경에 배포합니다. 이후 수정사항이 발생하게 되면, 그 수정사항을 반영한 커밋에 새로운 버전을 의미하는 v1.0.1과 같은 태그를 추가하고, 이를 통해 QA 환경에 다시 배포하는 방식이 일반적입니다. 이 방법은 버전 관리와 배포 이력을 명확히 기록하기에 용이합니다.

이와 유사한 솔루션을 다루고 있는 게시물을 추천드립니다:
- PR merge 시 test job 미실행 관련 문의

위 링크에서 PR 상태와 관련된 배포 단계 제어에 대한 유용한 정보를 얻으실 수 있을 것입니다.

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