시나리오2에서 여러 릴리즈 브랜치를 한 번에 운영환경에 배포

안녕하세요 ~

질문 주신 내용이 제가 강의를 만들면서 많은 고민을 했던 부분입니다.
원래는 질문 주신 부분에 대한 내용을 강의로 만드려고 계획했으나, 많은 부연 설명과 복잡성 때문에
간략히 변경했습니다.

그래서 언젠가 질문이 오지 않을까 생각했던 내용인데, 이렇게 물어봐주셔서 신기하네요 ㅎㅎ

말씀하신 대로, 시나리오2는 추가되는 기능의 횟수만큼 운영환경에 배포되는 방식입니다.
시나리오2에 국한해서 답변드리기가 조금 어려워서 좀 더 내용을 확장한 상태여야
더 의미 있는 답변을 드릴 것 같습니다.

예시로 설명드리는 게 이해하시기에 더 나을 것 같아 아래와 같은 예시로 설명드리겠습니다.

예를 들어, dev branch는 개발 환경, master branch는 운영 환경으로 구성되어 있고
처음 운영 환경에 배포된 버전이 v1.0.0이라고 가정하겠습니다.
이제 여기서, 적용해야 하는 기능 A, B 두 개를 적용해서 v2.0.0으로 운영 환경에 배포하려고 계획합니다.

이 경우, A와 B 기능을 각각 개별적으로 배포하는 것이 아니라 두 기능을 모두 포함한

v2.0.0을 한 번에 배포하는 구조를 사용해보려합니다.

보통은 이러한 과정에서, QA, Staging, Pre-production 등 다양한 환경에 A와 B 기능을
배포한 다음 검증을 통해 운영 환경에 배포하게 됩니다.

이제 이러한 내용을 GitHub branch와 Tag, 그리고 dev, QA, production의 개념을 조합해서
단계별로 설명드리겠습니다.

dev branch에서 Feature/A 브랜치를 만들고 A 기능을 추가하고 dev branch로 PR 머지합니다.
PR 머지되면 개발 환경에 A 기능이 배포됩니다 (이 시점의 커밋을 abcd라고 가정).
배포가 완료되면 QA 환경으로 보내기 위해 release/v2.0.0-rc.1로 태깅합니다
(v2.0.0-rc.1 태그는 abcd 커밋을 가집니다).
abcd 까지의 커밋을 가진 코드가 QA 환경에 반영되어 배포됩니다.
이 때 v2.0.0-rc.1 태그와 동일한 커밋을 가지는 release/v2.0.0 브랜치를 최초 생성합니다.
dev branch에서 Feature/B 브랜치를 만들고 B 기능을 추가하고 dev branch로 PR 머지합니다.
PR 머지되면 개발 환경에 B 기능이 배포됩니다 (이 시점의 커밋을 efgh라고 가정).
배포가 완료되면 QA 환경으로 보내기 위해 release/v2.0.0-rc.2로 태깅합니다
(v2.0.0-rc.2 태그는 efgh 커밋을 가집니다).
efgh 까지의 커밋을 가진 코드가 QA 환경에 반영되어 배포됩니다.
release/v2.0.0 브랜치에 v2.0.0-rc.2 커밋을 추가합니다.
(그러면 abcd와 efgh 커밋이 이 release/v2.0.0 브랜치에 있는 상태가됩니다)
QA 환경에서 배포 및 검증이 끝나면 release/v2.0.0 브랜치에서 master branch로 PR 머지합니다.
master branch에 release/v2.0.0 브랜치의 커밋인 A와 B 기능이 반영되어 v2.0.0 의 기능이 배포됩니다.

이 구조는 하나의 예시로 생각해주시면 됩니다.
또한, 위와 같은 방법 외에도 다양한 배포 전략을 고려할 수 있습니다.

예를 들어, 여러 기능을 모아 한 번에 배포하려는 경우 기능 플래그(Feature Flag)를 사용하여 각 기능을
개별적으로 활성화하거나 비활성화할 수 있는 방법도 있습니다.
이렇게 하면, 기능을 개별적으로 개발하고 병합하더라도 운영환경에서는 필요한 기능만 선택적으로 활성화할 수 있게 됩니다.(Feature Flag 부분은 깃헙 액션으로만 하기 불가능합니다)

이 부분에 대해 강의로 담기가 쉽지 않아서, 간단한 시나리오로 변경했는데요 .

내용을 쓰고 읽어보니 조금 난해할 수도 있겠다라는 생각이 들기도 합니다 ^^;;

추가 질문이나 더 자세한 설명이 필요하시면 언제든지 말씀해 주세요. 감사합니다!

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