SVN 을 이용한 형상관리 PART.2 - SVN 브랜치 전략 세우기

SVN 브랜치 전략 세우기

 

📌 SVN으로 어떻게 버전 관리를 하는 것이 좋을까?

SVN을 이용한 버전 관리 시스템의 두 번째 포스팅입니다.

이번 포스트에서는 SVN 을 활용한 브랜치 전략에 초점을 맞춰보도록 하겠습니다.

 

📌 Git Flow?

버전 관리 시스템에 대해서 공부하다 보면 (특히 git) git-flow 에 대해서 한 번쯤은 보게 됩니다.

이걸 처음 봤을 때는 이보다 완벽한 버전 관리 방법은 없을 것 같다고 생각했습니다.

 

대략적으로 이러한 흐름을 가지고 있어요

SVN 을 버전 관리 시스템으로서 보다 안전하게 사용하기 위해서

엄격한 git-flow 방식을 차용하는 것은 어떨까 고민하고 있었습니다.

 

곧바로 같이 일하는 개발자분에게 피드백을 요청하니 저에게 이렇게 반문하셨습니다.

 

만약 특정 기능을 특정 형상에 반영해달라고 하는 요청에 대해서는 어떻게 다룰 수 있을까요?

 

저는 답변을 제대로 할 수 없었고 git-flow 는 현재 우리 프로젝트의 성격과

잘 맞지 않아 다른 방법을 찾아야 한다는 것을 알게 되었습니다.

 

📌 우리가 Git Flow를 사용하지 않은 이유

현재 제가 회사에서 진행하고 있는 프로젝트는 빠른 주기로 새로운 기능들이 추가되고

검증과정을 거쳐 운영 베타(실제 운영 바로 직전의 버전)에 배포되고 있습니다.

도식화하면 다음과 같은 흐름으로 앱이 배포되고 있는 것입니다.

개발 -> 검증 -> 운영베타 -> 운영

개발 에서 요구사항을 구현하고,

검증 에서 QA 분들과 함께 검수를 진행하며

운영 에 올리기 전 운영 베타 에서 최종 확인을 진행하는 형태입니다.

 

이 과정에서 사업적인 요건, 또는 기타 여러 가지 문제로

가끔씩은 특정 기능의 반영을 먼저 해달라는 요청이 들어오거나

이번 배포에서는 제외해달라는 부탁을 받을 때가 있습니다 😅.

 

만약 여기서 정석적인 Git-Flow 를 사용하게 되면

이전에 dev 브랜치에서 파생되어 코드 반영이 끝난 feature 브랜치의 내용이

그대로 검증 환경으로 넘어가는 문제가 생길 수 있는 것입니다.

기능 단위로 제어하기를 원하는 저희 프로젝트 성격에는 맞지 않았습니다.

 

📌 더 효율적인 방법은 무엇일까?

브랜치 전략으로 해결하고 싶은 문제들

따라서 저희는 다음과 같은 조건들을 만족하는 브랜치 전략에 대해서 고민했습니다.

• 서로의 개발 영역의 영향도를 최소화할 수 있어야 한다.
• 긴급 반영이나 특정 기능에 대한 수정 및 반영 건도 처리할 수 있어야 한다.
• 다수의 개발자가 사용하기 때문에 직관적이며 복잡하지 않은 전략이어야 한다.

 

그래서 다음과 같이 나누었습니다

따라서 저희는 다음과 같이 브랜치를 나누어 형상을 관리하기로 결정했습니다.

app, feature, develop, stage, beta, trunk

각각의 브랜치에 대한 용도는 다음과 같습니다.

 

app 브랜치

app 브랜치는 외주 개발자가 주로 작업하는 영역입니다.

프로젝트 상황 상 모든 외주 개발자 분들에게 새로운 브랜치 전략을 설명하고 이를 적용 시는 비용이 크다고 판단했습니다.

또한 배포에 대한 권한은 모두 내부 개발자들에게 있어서, 코드 merge 시 수정이 필요한 부분은 파악이 가능한 구조였습니다.

간단한 UI 수정이나 기능에 영향을 주지 않는 작은 수정들은 내부 개발자도 별도의 feature 브랜치를 trunk 에서 생성하지 않고 app 브랜치를 통해 해결하는 것으로 결정했습니다.

 

feature 브랜치

JIRA 티켓 이슈나 소스 전반적으로 영향도가 큰 작업들은 feature 브랜치를 생성해서 작업합니다.

이때 반드시 feature 브랜치는 trunk 로부터 생성합니다.

 

develop 브랜치

개발계 서버에 배포되는 소스 버전을 위한 브랜치입니다.

 

stage 브랜치

검증계 서버에 배포되는 소스 버전을 위한 브랜치입니다.

 

beta 브랜치

운영 베타에 배포되는 소스 버전을 위한 브랜치입니다.

마켓 배포 일별로 beta 브랜치의 최종 버전은 운영계 서버로 배포가 이루어집니다.

 

trunk

실제 운영계에 배포되어있는 소스 버전입니다.

각각의 trunk 버전은 해당 버전과 같은 beta 브랜치 소스 코드와 동일한 형상을 가집니다.

 

브랜치를 사용할 때 지켜야 할 규칙들

이제 위 브랜치들로 작업을 진행할 때 꼭 지켜야 할 몇 가지 규칙들을 정했습니다.

 

1️⃣ feature는 trunk 로부터 생성한다.

운영 버전과의 싱크와 영향도를 줄이기 위해 각각의 feature 는 메인 trunk 로부터 생성합니다.

이를 통해 운영 배포의 영향도를 줄일 수 있고 필요한 기능만 검증 후 운영에 배포할 수 있습니다.

개발이 완료된 feature 는 배포되어야 할 브랜치로 각각 병합합니다.

 

2️⃣ 기능 개발 후 각각의 빌드 브랜치로 이동해서 merge 한 뒤 빌드한다.

운영되는 서버계에 따라서 반영되어야 하는 코드 형상이 달라지는 요구 조건이 발생할 수 있기 때문에

develop -> stage 혹은 stage -> beta 와 같은 단방향 merge 는 불가능합니다.

따라서 각각의 빌드는 해당 브랜치로 이동 후 필요한 기능을 merge 한 뒤 진행합니다.

 

3️⃣ 운영 배포는 가장 최신의 beta 브랜치와 싱크를 맞춘다.

사용자가 사용하게 되는 실제 운영 버전은 beta 브랜치의 형상 중 가장 최신과 동기화시킵니다.

beta 브랜치는 이미 검증이 완료된 상태이고 더 이상의 기능 추가가 발생하지 않아야 하기 때문에

해당 버전을 바로 운영 배포에 사용하도록 정의했습니다.

 

4️⃣ 빌드(개발, 검증, 운영) 버전에는 Tag를 통해서 버전 정보를 명시합니다.

각각의 빌드 버전에서 Tag 를 붙이는 작업 또한 중요합니다.

이를 통해서 빌드 버전마다 소스코드 백업본을 가질 수 있기 때문에, 만약 특정 버전에서 문제가 발행한다면

해당 버전의 소스 코드에서 문제점을 찾아 수정한 뒤 배포할 수 있습니다.

 

📌 그 외 내부적으로 정한 것들

이 외에도 효율적인 협업을 위해 내부적으로 다음과 같은 rule set 을 만들어서 사용하고 있습니다.

1. SVN 은 Git과 같이 현재 브랜치 위치가 어디인지 나타나지 않아
2. commit 시 실수를 유발할 수 있으므로 중요한 명령들은 쉘 스크립트로 강제하도록 했습니다.
3. 브랜치명은 이슈명 혹은 추가되는 기능명으로 정의했습니다. 티켓번호가 브랜치명으로 사용됩니다.
4. 만약 티켓이 아직 할당되지 않았고, 급하게 작업이 필요한 사항이라면 기능명으로 정의합니다.
5. 현재 다니고 있는 회사에서는 JIRA 를 이용해서 이슈를 티켓 형태로 관리하고 있기 때문에