[조대협 대용량 아키텍처] 소스 코드 관리(with git)

소스 코드 관리

소프트웨어 개발시에 중요한 소스코드 관리

 

소스코드 관리란 협업을 위해서 소스코드를 저장하고 버전과 변경을 관리하는 것을 말하며, 소스코드 관리시스템을 이용하여 소스코드를 관리한다. 소스코드 관리시스템을 VCS(Version Control System) 혹은 SCM(Source Code Management)라고 한다.

 

소스코드 관리 시스템의 기능은 다음과 같다.

• 협업을 위한 코드 공유
• 접근 제한
• 다양한 버전(형상) 관리
• 특정 시점 추적
• 변경 추적

 

브랜치

소스 코드 관리에서 브랜치의 개념 이해가 먼저 필요하다. 보통 소프트웨어 개발시에 하나의 저장소에 소스코드를 저장하여 개발하고, 개발자 간의 공유를 통해 협업을 진행한다.

개발 진행시에 특정 목적 혹은 별도의 작업에 의해서 기존 개발 소스의 복사본을 만들어 사용하게 되는 경우가 있는데, 이 때 만들어진 복사본을 브랜치라고 하고 기존의 소프트웨어를 개발 하던 소스코스 저장소를 메인 브랜치라고 한다.

 

원래 브랜치(Branch)는 나무줄기라는 뜻인데, 기존 개발 저장소를 기반으로 여러 복사본(브랜치)들이 생성되어 마치 나무와 같은 구조에서 나무줄기와 같다고하여 붙여진 용어이다.

또한, 전체적인 모양을 보면 마치 나무와 같다고 하여 소스 코드 트리(Soure Code Tree) 혹은 브랜치 트리(Branch Tree)라고 부른다.

 

체크 아웃, 커밋, 병합

체크아웃은 소스코드 저장소에서 코드를 내려받는 행위를 말하며, 작성된 코드를 저장소에 올리는 행위는 커밋이라고 한다.

(git 에서는 pull이라고 표현)

 

하지만 협업을 진행하기에 소스코드 저장소에서 각자 하나의 파일을 내려받아 각각 편집을 진행하고 커밋을 시도할 경우 충돌(Conflict)이 발생하게 된다. 

 

이렇게 충돌이 발생했을시에, 한 버전에서 다르게 수정된 코드를 저장소에 반영하기 위해서는 병합(Merge)과정이 필요하다.

따라서 먼저 반영된 소스 코드를 기반으로 다음 반영될 개발자는 수정된 버전을 기반으로 차이를 확인하여 수동으로 병합하여야 한다.

 

태깅

태깅은 코드 개발중 특정 시점의 이미지를 표시한 것을 의미한다. 

예를 들어, 매일 소스 코드에 대해 태그를 달게되면 개발 중 문제가 발생했을 경우 특정 날짜의 코드로 다시 돌아갈 수 있다.

보통 태깅은 빌드 시마다 하며(빌드 태그), 빌드 시에 에러가 날 경우 이전 버전으로 소스 코드를 다시 돌려 놓은 방식으로 개발을 한다.

 

릴리즈 브랜치

릴리즈 브랜치의 예로, 서비스를 출시한 상태에서 현재 메인 브랜치를 릴리즈를 하여 5.x 버전을 배포하였다. 또한 추가적으로 서비스 업데이트를 위해 6.x 버전을 메인 브랜치로 개발을 진행하고 있다. 이 때 고객에게 5.x 버전의 버그 수정 요청이 들어왔을 경우, 현재 메인 브랜치는 6.x 버전을 개발 중이기에 6.x 버전의 코드는 이미 바뀌어 찾을 수가 없게 되었고, 6.x 버전의 개발도 완료되지 않았다.

 

이 경우와 같을 때를 대비하여 개발시에 각 릴리즈마다 릴리즈 브랜치를 발급하여 릴리즈 버전별로 코드를 관리하는 것이 좋다.

 

QA 브랜치

QA 브랜치는 상품화를 위해 개발된 제품을 QA팀에 테스트를 의뢰할 경우, QA 팀에서 지속적인 버그 요청이 들어와 많은 양의 코드 수정을 메인 브랜치에서 진행하게 되면 병합도 많이 발생하며 번거로움이 발생하기에 따로 브랜치를 만들어 QA팀에게 테스팅을 의뢰할 때 사용된다.

 

QA가 끝나게 된다면, 해당 QA 브랜치에 있는 내용을 다시 메인 브랜치로 병합하여 반영한다.

 

브랜치 관리 전략

브렌치는 메인 코드의 복사본이다. 브랜치는 용도에 따라 얼마든 복사 되고 병합 될 수 있다. 그러나 개발하는 소프트웨어에 형상에 따라 알맞은 브랜치 전략을 결정해야 최적의 소스 코드 관리를 할 수 있다.

 

VCS의 제품에 따라 브랜치 구조에 대한 레퍼런스를 제공하며, 각 형상에 맞는 브랜치 모델이 많이 존재한다.

 

1. 오픈소스 코드 브랜치 관리 전략

다음은 대표적인 VCS 솔루션인 Git을 이용한 브랜치 전략이다.

출처 : https://nvie.com/posts/a-successful-git-branching-model/

 

이 구조는 git-flow라는 이름으로, 이미 널리 알려진 브랜치 모델이며 오픈소스와 같은 대규모 분산 조직에서 개발을 하기에 적합한 구조이다.

 

개념을 살펴보면 메인 브랜치에서는 개발을 하지 않고, 별도의 개발 브렌치에서 개발을 진행하여 기능 개발 완료시에 병합을 하여 마스터에 반영한다. 특이한 점은 코드 리뷰(Code Review)이다. 개발자가 코드를 수정했을 경우, 젠킨스와 같은 빌드 시스템에 통합되어 빌드되어 테스트를 진행하는데, 이때 개발 브랜치에 저장을 하고 테스트가 끝난 코드에 리뷰를 한후 승인이 되면 마스터 브랜치에 반영이 된다.

 

일반적인 소프트웨어 브랜치 관리 전략

일반적인 브랜치 관리전략은 trunk(or head), tags, branches 세가지의 구조로 브랜치를 관리한다.

trunk에서는 현재 진행중인 코드를 저장하고, 개발 진행중 빌드 혹은 특정 날짜를 기준으로 태깅을하여 tags 브랜치에 작성을 한다.

tag명에는 날짜를 작성하거나 빌드 시스템의 빌드 번호를 사용하기도 한다.

branches는 릴리즈 브랜치의 역할을 한다. 릴리즈 시마다 그때의 코드 형상을 저장하는 구조이다.

 

분산 형상 관리 시스템

이전에서도 언급한 Git은 기본적으로는 분산 소스 코드 관리 시스템으로 사용을 한다.

분산 소스 코드 관리 시스템을 이해하기 위헤서는 분산 저장소의 개념을 알아야 한다.

 

분산형 저장소

분산형 저장소는 소스 코드가 하나의 중앙서버거 아닌 여러개의 서버 혹은 여러 PC에 저장될 수 있으며, 각각이 저장소가 된다.

때문에 시스템 자체에는 마스터 버전의 개념이 없으며 각 저장소에서 모듈을 독립적으로 개발을 하며 개발자들은 각 서버로 커밋을 한 뒤에 모듈 개발이 끝나면 각 서버의 코드를 병합하여 개발 내용을 합친다.

 

 

이러한 분산형 저장소의 장점은 소스코드가 여러 서버와 PC에 분산되어 저장되기 떄문에 서버 장애로 저장소가 손실되어도, 중앙 서버 방식에 비해 복구가 상대적으로 쉽다.