들어가며

이번 글에서는 NHN Cloud Notification 개발을 담당하는 메시징플랫폼개발팀의 브랜칭 전략인 Release Flow에 대해 소개합니다. 메시징플랫폼개발팀은 사실 최근까지 Release Flow에 대해 전혀 모르고 있었습니다.

몇 개월 전, 팀 내부에서 일어난 한 장애로 이 브랜칭 전략을 알게 되었습니다. GitHub Pull Request(PR)에서 베이스 브랜치를 실수로 잘못 설정하여 장애가 발생했고, 이를 분석하는 과정에서 저희의 브랜칭 전략에 개선의 여지가 있음을 발견했습니다. 과연 저희의 브랜칭 전략이 이미 정의된 브랜칭 전략 중 하나일지 궁금해졌고, 그러던 중 Release Flow를 발견하게 되었습니다.

브랜칭 전략은 조직과 프로젝트의 특성에 맞게 조정되어야 합니다. 저희의 브랜칭 전략이 Release Flow를 완벽하게 따르고 있다고 말할 수는 없습니다만, 이 글에서는 저희 팀만의 브랜칭 전략을 소개하고, 일반적인 Release Flow와 어떻게 다른지 비교해 보겠습니다. 안정적으로 클라우드 서비스를 제공하고 효율적으로 개발하기 위한 사소한 고민과 노력을 이 글을 통해 공유하고자 합니다.

Release Flow

Release Flow라는 브랜칭 전략이 낯선 분들도 있을 텐데요. Release Flow는 Microsoft에서 사용하고 있는 브랜칭 전략으로 알려져 있는데요. 이 브랜칭 전략은 안정적이고 효율적인 소프트웨어 개발과 관리를 위해 만들어졌습니다.

Release Flow에 대한 자세한 설명을 여기서 모두 다루기는 어렵습니다. 아래 링크를 통해 자세한 내용을 확인하실 수 있습니다.

• Microsoft의 Release Flow에 대한 글
  • How Microsoft develops with DevOps - Release Flow
  • Release Flow: How We Do Branching on the VSTS Team
• Release Flow가 잘 설명되어 있는 웹사이트

위 링크들은 메시징플랫폼개발팀의 브랜칭 전략과 Release Flow를 비교하고 이해하는 데 있어 도움이 될 것입니다.

Release Flow의 핵심 요소

위 링크들을 읽어보면 용어나 설명에서 서로 약간의 차이가 존재하는 것을 발견할 수 있습니다. 그러나, 공통적으로 강조하는 핵심 요소는 같습니다. 그중 제가 생각하는 Release Flow의 핵심요소는 두 가지입니다.

• 단순함: Release Flow는 Git Flow, GitHub Flow보다 단순한 구조를 가지고 있습니다. 특히 Git Flow는 다양한 종류의 브랜치를 사용해 구조가 더 복잡합니다. Release Flow에서는 대부분의 기능 개발이 메인라인(mainline) 브랜치를 기준으로 이루어집니다. 이는 개발자들이 브랜칭 전략을 쉽게 이해하고 적응할 수 있게 하며, 실수를 줄여줍니다. 개발자는 복잡한 브랜치 구조를 신경 쓰지 않아도 됩니다.

• 주기적인 출시: Release Flow는 주기적인 출시 일정을 가진 엔터프라이즈 환경이나 대규모 프로젝트에 적합합니다. 릴리스 브랜치는 정해진 출시를 준비하면서, 메인라인 브랜치는 동시에 다음 출시에 필요한 기능을 반영할 수 있도록 합니다. 릴리스 브랜치는 다가올 출시를 위해 추가적인 검증 과정(테스트, 버그 수정, 최적화)을 거치며 안정성이 크게 향상됩니다.

Git Flow, GitHub Flow 브랜칭 전략과의 차이점

Git Flow, GitHub Flow, Release Flow는 서로 명확한 차이가 있습니다.

• Release Flow는 단순함과 주기적인 출시라는 두 가지 측면에서 균형을 잡고 있습니다. 이는 큰 프로젝트나 다양한 팀 구성원이 있는 환경에서 프로젝트의 효율성과 안정성을 동시에 향상시키는 데 도움이 됩니다.

• Git Flow는 다양한 유형의 브랜치와 복잡한 브랜치 관리를 필요로 하지만, 이는 크고 복잡한 시스템, 특히 여러 버전을 동시에 유지 관리해야 하는 프로젝트에 매우 적합합니다.

• GitHub Flow는 체계적인 브랜치 관리를 통해 안정적인 개발과 유지 보수를 지원하며, 다양한 릴리스와 핫픽스를 효과적으로 관리할 수 있게 해줍니다. GitHub Flow는 간결함과 지속적인 배포에 초점을 맞춘 접근 방식으로 인해 빠른 개발 주기와 신속한 반응이 필요한 프로젝트에 매우 적합합니다. 이는 팀이 새로운 기능을 빠르게 출시하고 지속적으로 개선할 수 있도록 도와줍니다.

각 브랜칭 전략의 특성에 대한 차이를 표로 나타내면 아래와 같습니다.

특성	Release Flow	Git Flow	GitHub Flow
기본 브랜치	mainline (또는 main)	main, develop	main
개발 방식	직접 mainline에서 개발	feature 브랜치에서 개발 후 develop으로 병합	직접 main에서 개발
릴리즈 프로세스	release 브랜치를 통해 릴리스 관리	release 브랜치를 통해 릴리스 준비 후 main에 병합	main에서 바로 배포
핫픽스 관리	mainline에서 분기	hotfix 브랜치를 main와 develop에 병합	main에서 바로 수정
적합한 환경	대규모 프로젝트와 엔터프라이즈 환경(B2B, Mission Critical)	복잡한 릴리스 사이클이 있는 프로젝트(오픈 소스 라이브러리/프레임워크 등)	빠른 반복 개발이 필요한 프로젝트(B2C)

메시징플랫폼개발팀의 Release Flow

• 메시징플랫폼개발팀의 Release Flow의 예시입니다.

메시징플랫폼개발팀은 Release Flow를 기반으로 한 자체 브랜칭 전략을 사용하고 있습니다. 이 전략은 다음과 같은 주요 브랜치로 구성됩니다.

• 메인라인 브랜치 (develop): 모든 개발 활동의 중심이 되는 브랜치입니다.
• 피처 브랜치 (feature/{부모브랜치}/{개발이슈번호}): 개별 기능 개발을 위한 브랜치입니다.
• 에픽 브랜치 (epic-{상위개발이슈번호}): 큰 규모의 프로젝트 또는 여러 기능을 포함하는 개발 작업을 위한 브랜치입니다.
• 릴리스 브랜치 (release-{출시일}): 출시 준비를 위해 메인라인 브랜치에서 분기하는 브랜치입니다.
• 태그 ({서비스이름}/{출시일}/{출시계획이슈번호}): 출시 준비가 완료된 릴리스 브랜치를 태깅합니다.
• 핫픽스 브랜치 (hotfix-{핫픽스일}): 긴급한 버그 수정을 위한 브랜치입니다.

아래에서 각각의 브랜치에 대해 더 자세히 알아보겠습니다.

1. 메인라인 브랜치: develop

메시징플랫폼개발팀은 develop을 메인라인 브랜치로 사용하고 있습니다. Release Flow에서는 메인라인 브랜치가 항상 빌드와 배포 가능해야 된다고 합니다. 이는 메인라인 브랜치에서 대부분의 개발이 일어나지만 메인라인 브랜치를 항상 빌드와 배포가 가능하게 만큼 안정적인 상태로 유지하는 걸 목표로 해야 된다는 의미입니다. Release Flow는 메인라인 브랜치에서 부터 높은 수준의 안정성을 유지하는 데 중점을 둡니다.

여기에 더해 Release Flow는 출시를 위한 릴리스 브랜치가 존재합니다. 이 릴리스 브랜치는 출시 준비 기간 동안 추가 검증 과정을 거쳐 더 안전한 상태를 유지합니다.

Release Flow와의 차이점

• 메인라인 브랜치의 이름이 일반적으로 많이 사용하는 main이 아닌 develop인 것 외에 동일합니다.

2. 피처 브랜치: feature/{부모브랜치}/{개발이슈번호}

개발을 위한 피처 브랜치 입니다. 브랜치 이름에는 '부모 브랜치'와 '이슈 번호'가 포함되어야 합니다. 예를 들어, develop 브랜치에서 시작된 피처 브랜치는 feature/develop/1234와 같이 명명됩니다. 여기서 '1234'는 관련된 이슈 번호를 나타냅니다.

이러한 피처 브랜치 명명 규칙은 브랜치의 관련 이슈와 부모 브랜치를 명확히 하여, 개발 프로세스의 효율성을 높일 수 있습니다. 분기된 피처 브랜치는 개발이 완료되면 항상 해당 부모 브랜치로 머지 됩니다. 과거에 잘못된 브랜치로 머지 되어 장애가 발생한 적이 있었는데, 이러한 사례를 바탕으로 피처 브랜치의 이름을 더 분명히 하는 방식을 도입하였습니다. 이를 통해 PR 리뷰 시에도 쉽게 피처 브랜치의 부모를 파악할 수 있습니다.

또한, 이슈 번호를 피처 브랜치 이름에 포함시키는 것은 코드와 관련된 이슈를 연결하는 데 중요한 역할을 합니다. 이는 PR 리뷰 과정이나 추후 코드의 변경 이력을 추적할 때 매우 유용합니다.

Release Flow와의 차이점

• 피처 브랜치에 부모 브랜치를 표기합니다. 그 외 동일합니다.

3. 에픽 브랜치: epic-{상위개발이슈번호}

규모가 크고 여러 개로 나누어 진행해야 될 개발 이슈를 위한 브랜치 입니다. 메인라인 브랜치에서 에픽 브랜치를 생성합니다. 일반 피처 브랜치와 에픽 브랜치의 기준이 딱히 정해져 있지는 않지만 피처 브랜치가 짧게 리뷰되고 머지 할 수 없는 크기인 경우, 하나의 상위 개발 이슈에 여러 개의 하위 개발 이슈가 생성된 경우, 여러 명의 개발자가 하나의 큰 기능을 만들 때 에픽 브랜치를 사용합니다.

에픽 피처 브랜치는 에픽 브랜치에서 생성합니다. 에픽 피처 브랜치 이름은 피처 브랜치 이름과 동일한 규칙을 가집니다. (예: feature/epic-32/629)

에픽 브랜치에 여러 개의 에픽 피처 브랜치가 머지되고 개발이 완료되면 메인라인 브랜치로 리베이스(Rebase)를 사용하여 병합합니다.

에픽 브랜치 개발이 완료되면 에픽 브랜치를 메인라인 브랜치로 리베이스하고 머지합니다. 리베이스를 통해 메인라인 브랜치에 에픽 브랜치의 커밋들을 그대로 반영하기 위함입니다.

Release Flow와 차이점

• Release Flow와 동일합니다.

4. 릴리스 브랜치: release-{출시일}

출시를 위한 릴리스 브랜치입니다. 출시 전 정해진 코드 프리즈(Code Freeze) 일자에 메인라인 브랜치에서 릴리스 브랜치를 생성합니다. 여기서 중요한 점은 꼭 원격 저장소(GitHub)에서 릴리스 브랜치를 생성해야 합니다. 왜냐하면 로컬 저장소에서 릴리스 브랜치를 생성하면 최신이 아닌 메인라인 브랜치에서 생성될 수 있기 때문입니다.

이렇게 생성된 릴리스 브랜치는 검증 과정(테스트, 버그 수정, 최적화)을 거치며 안정성이 더욱 개선됩니다.

메시징플랫폼개발팀의 릴리스 브랜치의 이름은 출시일을 포함해야 합니다. 원래 릴리스 브랜치에 출시일을 표시하지 않았습니다. 이로 인해 잘못된 브랜치로 코드를 머지 해 장애가 발생한 뒤로 릴리스 브랜치엔 출시일을 반드시 포함시키는 규칙을 추가했습니다.

릴리스 브랜치에 출시일을 표시하는 것은 잘못된 머지를 예방하기 위함입니다. 그리고 NHN Cloud는 출시일 기준으로 모든 개발 및 검증 일정이 정해지기 때문에 릴리스 브랜치에 출시일을 표시하는 것은 출시 기반 환경의 일정 관리에 도움이 됩니다.

출시 완료 후 릴리스 브랜치는 메인라인 브랜치로 머지합니다. 중요한 점은 릴리스 브랜치를 메인라인 브랜치로 머지하는 경우, 에픽 브랜치와 동일하게 리베이스 후 머지하는 것 입니다. 리베이스 후 머지를 하여 출시 준비 기간 동안의 수정 사항들을 메인라인 브랜치에도 그대로 반영합니다.

Release Flow와 차이점

• Release Flow에서는 일반적으로 릴리스 브랜치의 이름 뒤에 버전 번호나 스프린트/마일스톤 번호를 붙입니다. 반면, 메시징플랫폼개발팀은 출시일을 브랜치 이름에 포함시키는데요. 이는 일정 관리 및 추적에 도움이 되기 때문입니다.

5. 태그: {서비스이름}/{출시일}/{출시계획이슈번호}

메시징플랫폼개발팀에서는 모든 출시 준비가 완료된 후에, 출시를 위한 릴리스 브랜치에서 태그를 생성합니다. 태그는 릴리스 브랜치 생성과 동일하게 GitHub에서 생성합니다. 이는 GitHub에서의 태그 관리가 더 직관적이고, 동시에 항상 최신 상태의 릴리스 브랜치에서 태그를 생성할 수 있기 때문입니다.

태그의 이름은 '서비스 이름', '출시일', '출시 계획 이슈 번호'를 포함합니다. 예를 들어, SMS 서비스의 2024년 2월 27일 출시에 대한 태그는 'SMS/2024-02-27/1024'가 됩니다. 이러한 명명 규칙은 배포 과정에서 실수를 줄이고, 문제가 발생했을 경우 원인을 쉽게 추적할 수 있게 도움을 줍니다.

출시가 완료된 후, 릴리스 브랜치는 메인라인 브랜치로 머지되고 삭제됩니다. 이 방법은 리포지터리를 깨끗하게 유지합니다. 또한 이력에 대한 추적과 핫픽스는 태그를 이용해 해결합니다.

Release Flow와 차이점

• Release Flow에서는 릴리스 브랜치를 출시 후에도 보관할 수 있으며, 태그 대신 버전 번호나 스프린트/마일스톤 번호를 사용합니다. 반면, 메시징플랫폼개발팀 처럼 태그를 이용하는 곳도 있습니다. 메시징플랫폼개발팀은 출시일 기반의 태그 명명 규칙을 채택함으로써 이슈 추적을 용이하게 하고, 리포지터리 관리를 더 간소화합니다.

6. 핫픽스 브랜치: hotfix-{핫픽스일}

핫픽스가 필요한 경우, 가장 최근에 배포된 태그를 기반으로 핫픽스 브랜치를 생성합니다. 이 방식은 핫픽스가 현재 운영 중인 소프트웨어 버전에 직접 적용되도록 보장합니다.

핫픽스 브랜치 이름은 릴리스 브랜치와 동일한 명명 규칙을 따르는데요. 핫픽스 브랜치 생성 후, 핫픽스 피처 브랜치(예: feature/hotfix-{핫픽스일}/{개발이슈번호})에서 실제 코드 수정 작업을 진행합니다. 이렇게 수정된 코드는 리뷰 과정을 거친 후 핫픽스 브랜치로 머지 되며, 이 브랜치는 개발 환경에 배포되어 검증 과정을 거치게 됩니다.

핫픽스가 완료되면, 핫픽스 브랜치는 메인라인 브랜치로 리베이스 후 머지됩니다. 이는 릴리스 브랜치나 에픽 브랜치를 리베이스로 머지하는 이유와 동일합니다. 만약, 현재 출시 준비 기간인 경우, 릴리스 브랜치에 핫픽스 브랜치의 변경 사항을 반영합니다.

Release Flow와의 차이점

• Release Flow에서는 핫픽스가 일반적으로 메인라인 브랜치에서 분기되어 개발되고, 다시 메인라인 브랜치로 머지됩니다. 릴리스 브랜치에서는 핫픽스 브랜치의 변경 사항을 체리픽(cherry-pick) 방식으로 가져옵니다.

나가며

이번 글을 쓰면서 느낀 점은 어떤 특정한 브랜칭 전략을 일률적으로 적용할 필요는 없다는 것이었습니다. 선택한 브랜칭 전략의 방향성은 따라가되 모두가 처한 상황과 환경은 다르기 때문에, 이에 맞게 최적화 시키는 게 중요하다는 것입니다. 이번에 소개한 메시징플랫폼개발팀의 브랜칭 전략 역시 완벽하진 않습니다.

저희도 지속적으로 부족한 부분을 발견하고, 개선해 나가야 합니다. 새로운 브랜칭 전략이 등장하거나 개선 가능한 요소를 발견한다면, 이를 적극적으로 반영하여 변화하는 환경 속에서도 효율성과 안정성을 모두 확보해야 할 것입니다.

출처

• How Microsoft develops with DevOps - Release Flow
• Release Flow: How We Do Branching on the VSTS Team
• http://releaseflow.org
• 이 글은 OpenAI의 GPT-4의 도움을 받아 작성되었습니다.