블로그 이미지
Welcom Back Tatter. 머샤머샤

카테고리

분류 전체보기 (140)
테터 (1)
悲歌 (12)
Lost & Found (1)
IT (126)
Total
Today
Yesterday

형상관리 솔루션 실루엣을 개발하면서 브랜치와 병합에 대한 의견을 다양한 업종에 계신 개발자분들과 이야기 할 기회가 많이 있습니다.

버전관리에 있어서 브랜치기능은 필수라고 생각하시는 분도 계신 반면, 그런거 기능은 있지만 실제로 쓸일이 있나요? 라고 반문하시는 분까지 말입니다.

저의 경험을 대략적으로 정리 해 보면.

- 형상통제 환경(일반적으로 금융권 형상관리 통제상황)에 계시는 분들은 버전관리 프로세스 자체가 병렬개발을 허용하지 않는 경우가 많기 때문에 필요성에 대한 욕구가 작습니다.

- 소규모 사이트 유지보수 상황(조그마한 중소기업 전산실 환경)에 계시는 분들은 해당 업무를 자신 혼자서 담당하는 경우가 많아서 브랜치를 고려 하는 경우가 적습니다.

- Package를 개발해서 판매하는 상황(실루엣 같은 Package 솔루션을 만들어서 각 사이트 별로 커스터마이징 하는 경우)은 브랜치 및 병합에 대한 욕구가 매우 강합니다만, 일반적인 경우 파일 하나에 대한 브래치라기 보다 특정 모듈 전체에 대한 브랜치 적인 성격이 강합니다.

- 제법 규모가 있는 서비스 사이트(통신사 고객서비스 센터 같은)의 경우에는 사이트는 운영기간동안 국지성 SI사업이 빈번하기 때문에 (신규 서비스가 오픈된다든지 하는) 신규 모듈에 대한 병합과 신규 모듈에 의해서 변경되는 기존모듈의 병합에 대한 욕구가 강합니다.


실제 모듈병합에 대한 제반지식을 포함한 메뉴얼을 아래에 첨부합니다.



실루엣을 사용한 모듈병합기능을 설계하면서 좀더 한국에 있는 개발자들에게 현실적인 도움이 되는 기능이 무엇일까 항상고민합니다. :)

혹시 모듈(업무)에 대한 병합을 고민하고 계신 개발자라면 반드시 실루엣을 사용하지 않더라도, 아래에 정의된 병합의 상태에 대한 가이드가 많은 도움이 되실 것입니다.



병렬개발과 모듈 병합에 대한 프로세스 이해


병합 상태에 대한 이해. 자세한 설명은 위에 첨부된 실루엣 모듈병한 메뉴얼 참조.

Flag 3가지 유형의 값을 보여주는 것으로 0 = 없음, 1,2,3은 값이 동일 한지를 의미 합니다.

예를 들어서 1-1-2 Base Mainline이 동일하고 Branch만 다르다는 것을 의미합니다.

상태

Flag

해석

동일

1-1-1

파일이 전혀 변경되지 않은 경우이다.

완료

0-1-1

1-0-0

1-2-2-

완료는 Base에 비교해서 병합작업이 완료된 경우이다. 실제 파일이 수정된 경우이기도 하지만, 파일이 동일하게 삭제되거나 추가된 경우도 포함된다.

올림

0-0-1

1-1-2

올림은 Branch에서 변경 혹은 추가된 것으로 필요하다면 Mainline에 반영 해야 하는 대상이다

내림

0-1-0

1-2-1

내림은 Mainline에서 변경 혹은 추가된 것으로 필요하다면 Branch에 반영 해야 하는 대상이다

검토

검토는 상황에 따라서 사용자의 판단이 필요한 경우이다.

소스의 내용을 판단하고, 파일의 생성시간을 참조 해서 처리방법을 판단 해야 한다.

1-0-1

(일반적으로) Mainline에서 삭제된 파일이 Branch에 아직 남아 있는 경우일 가능성이 높다. Mainline의 삭제이력을 조사하자.

1-0-2

Mainline에서는 삭제되었는데, Branch에서는 변경된 경우이다. Branch에서 계속 사용되고 있거나 그냥 변경 되었을 수 있다. Branch의 체크인 이력을 조사해서 누가 변경 했는지 추적하자.

1-1-0

(일반적으로) Branch를 생성 할 때 제외한 파일일 가능성이 높다. 물론 Branch에서 필요에 의해서 삭제 했을 수도 있다. Branch 생성시점의 이력을 조사하자.

1-2-0

Branch에는 포함되어 있지 않은데, Mainline에서는 수정되고 있는 경우이다. Branch 생성시점의 이력을 조사하자

병합

1-2-3

양쪽 모두에서 변경된 경우이다. 3WayDiff를 사용해서 어떤 내용이 변경되었는지 조사하자

기타

?-?-?

위 경우에 해당하는 않는 Case이다. 실루엣 개발팀에게 알려주자.




모듈병합 과정 이미지
Posted by 머샤머샤
, |

 

사용자 삽입 이미지









Project Version Manager Demo




전통적인 버전관리툴들, 그것이 Lock 중심의 것들(PVCS, SourceSafe...)이던지, Update 중심의 것들(CVS...) 이던지 상관없이 파일 중심의 버전관리 도구들입니다.

즉, 하나의 파일에 대한 버전변경을 추적하는 기능을 가지고 있는 것이지요.

실제 개발팀에서는 파일 하나의 버전에 대한 추적도 중요하지만, 변경셋(Change Set)에 대한 이력을 추적하고 관리하는 것이 무엇보다도 중요합니다.

CVS를 대체하겠다고 만든 SVN은 그런 의미에서 뉴트랜드에 부합하는 버전관리도구라고 할 만합니다.

몇몇 외산 버전관리 도구들이 Snap Shot이름으로 그 변경내용을 저장하는 방법을 제공 하기는 합니다만, 자동으로 저장되는 것이 아니라 사용자가 필요시점에 Snap을 작성하는 것이라 불편한 점이 많았습니다.

사용자가 일일이 snap을 작성하는 부분은 일견 "레이블" 기능과도 닮아 있습니다만, 사용방법과 Scope가 다릅니다. (그 이야기는 나중에 기회가 있으면...)

상단에 링크된 실루엣 프로젝트 버전 관리를 유심히 살펴보면 각 변경내역을 기록하고 추적하는 다양한 기능이 구현된 것을 볼 수 있습니다.
중요 기능을 정리하면

  • Check In 시점에 자동으로 Project Revision 생성
  • Project간 Revision Compare (Branch된 다른 Project에 대해서 Compare)
  • 특정 Project 리비전에 Check In된 소스 조회 및 복원
  • 특정 Project 리비전 복원 (프로젝트 내용 전체를 복원하는 기능)

형상관리, 버전관리는 도구도 중요합니다만, 개발팀이 얼마나 의욕을 가지고 꾸준히 실천하느냐가 무엇보다 중요합니다.
그 실천의 과정에서 필요한 도구는 자연스럽게 방법이 찾아지고, 정착 될 것입니다.

Posted by 머샤머샤
, |

최근에 달린 댓글

최근에 받은 트랙백

글 보관함