형상관리

새로운 개발 방법론과 지원 도구 from 독재자
친한 후배의 글을 보고 몇자를 더 적어 보고자 한다. (아직 블로그에서 다른 글에 덧글 다는 방법은 알아도 링크 거는 방법은 이거밖에 모른다. --;)

위의 원 글에서 Team Project 부분에 대해 조금 자세히 적어보고자 한다. 비록 회사에서 CVS를 수년간 사용하고 있지만(음.. 회사라기 보다는 팀이 정확할듯 --;) 최근에 CVS에 관련된 글을 처음으로 보고 기타 부가지식들을 듣고 나서는 지금 까지 CVS의 맛배기만 보고 있었지 않았나라는 생각을 하고 있다. Team Proejct? 아니 정확하게는 형상관리에 대해서 썰을 풀어보고자 한다.

NetBSD의 릴리즈 그래프
중간의 "Overview of NetBSD release branches"부분을 참조하시라!

저정도는 되어야 CVS로 형상관리를 한다고 할 수 있다라는 생각이 무릇 무릇 들면서 반대로 CVS를 단순히 소스코드의 백업정도로 생각하고(소스코드의 접근성 및 동시작업성이 목표중에 하나이긴 하다) 버그(or 이슈) 트랙킹이나 프로젝트 일정관리(마일스톤, 일정 계획 등등)를 제외한 채 생각을 한다면 Visual Source Safe와 CVS는 더이상 차이가 없어지게 된다.

CVS: Tag 와 Branch
CVS가 지원하는 강력한 기능은 바로 Tag와 Branch이다. 이는 단순히 꼬리표 붙이거나 동시작업시 코드가 엉키는 것을 방지하기 위한 1차적인 목표만을 위해 존재하는 것은 아니다. 제품 개발에 있어서 중요한 활동인 개발과정, 릴리징과 제품 전달, 그리고 버그 패치 과정을 지원하기 위해서 존재하며 CVS뿐만이 아니라 Bug or Issue Management와 Project Management가 서로 연결되어야 하는 이유기도 하다.

Branch: 개발과 릴리징
브랜치를 쓰는 경우는 크게 두가지가 있다. 개발과정과 릴리징이다. 개발과정에서 쓰는 이유는 개발자가 큰 작업을 시작할 때 Trunk(브랜치가 일어나지 않은 중심 개발 축)에 주는 영향을 최소화 하고싶을 때 사용한다. 로컬 저장소에서 개발자가 작업을 하겠지만 나름대로의 히스토리를 둔다거나 소규모 사람들이 작업을 해야 하는 상황에 사용한다. 마지막에는 Trunk에 Merge 되거나 시도가 실패하는 경우 그대로 파기될 것이다. 다른 사용처인 릴리징의 경우 중심 개발축에서 일어나는 변화를 받지 않기 위해 혹은 릴리징 기간동안 아무도 개발을 할 수 없는 것을 방지하기 위함이 주 목적이며 또한 릴리징팀, 테스팅팀, 고객에서 들어오는 버그는 모두 릴리즈가 명시되어서 오기 때문인 이유도 있다. 이렇게 들어온 버그는 해당 릴리즈 브랜치에서 수정되어야 한다. 왜냐면 중심 개발축은 이미 호기심 많은 개발자들에 의해 난도질을 당했기 때문이다. (새로운 기능 추가=버그!)

Tag: 버그 수정, 릴리징 그리고 Milstone
Tag는 버그 수정과 릴리징 그리고 프로젝트의 Milestone에 사용될 수 있다. 소스코드를 수정하면서 여러 변화 중에 특정 버그가 수정되었는지나 어떤 버전 혹은 릴리즈에서 수정되었는지 추적하기는 그냥은 힘들다. 일반적으로 버그가 보고되면 담당 개발자에게 보고가 되고 개발자가 수정한 후 고쳤다고 보고하게 된다. 이경우 해당 소스가 릴리징팀에 전달되어 릴리즈에 반영이 되었는지나 실제로 고객에게 전달되었는지 확인해야 한다. 이 과정에서 소스코드에는 Tagging을 사용하고 Issue Management System(IMS)에서 그 과정을 컨트롤 한다. IMS에 최초로 보고된 Issue(Bug나 기능개선, UI 맘에 안든다, 기분이 나쁘다 등등등)는 고유 인식 ID를 부여받게 된다. 이후 Source Code의 어느 브랜치나 Trunk에 반영이 될 것이다. IMS에서는 이에 대해 Source Code에서 수정이 되었음을 기록할 것이고 이후 릴리징 과정을 통해 정확히 언제 만들어진 릴리즈에서 그 문제가 해결되었는지를 기록하고는 종료한다. (반대로 릴리즈가 되지 않으면 해당 문제는 종료되지 않는다. 왜 강조하는지.. 당해본 사람은 안다. 중복 이슈중 한 유형이 바로 이런거다.)

프로젝트 일정 관리와는 무슨 상관인가? 일정 관리를 하는데 중요한 포인트는 바로 Milestone이다. 일정을 설정할때 반드시 진척률의 척도를 측정할 수 있는 Milestone의 설정이 중요하며 이를 MS Project를 쓰던가 기타 툴을 사용할 것이다. Milestone들은 조건을 가지게 되는데 A모듈에 무슨 기능이 완성되고 B는 뭐, C는 뭐 식이나 고객에게 어느정도 수준의(베타든 RC든.. 이것도 조건이 정해지지만) 제품을 전달하는 것들이 된다. 즉 이런것들이 모두 Issue가 된다. 이제 IMS으로 역할이 넘어가게 된다. 베타에서 RC1이 되기 위해 정한 기능들이 있을 것이고 이것들이 Trunk에서 구현이 되었을때 릴리즈에 실제 반영되었는가를 누가 관리할 것인가? IMS과 CVS의 Tag를 이용해서 관리할 수 있다.

그외
마지막으로 커뮤니케이션 이야기가 있는데 이것에 대해서는 MSN만한 것을 보지 못했다. 회사 옮길때 마다 친구목록이 좀 난잡해 지는 경향이 있긴 하지만(그래서 본인은 두개의 아이디를 쓴다.), 그리고 보안상 매우 취약하지만 메일보다 손쉽게 비동기적 회의(Asynchronous Meeting)을 할 수 있는 매우 훌륭한 도구라고 본다.

More!
위에서 언급한 이야기들을 보면서 몇몇 사람들은 Testing이라던가 개발팀과 릴리징팀의 분리, QA, CCB 등의 이야기가 바로 옆동네 이야기라는 것을 느낄 수 있을 것이다. 사실 그런 것 모두가 포함되어야 진정한 형상관리가 될 수 있을것이다.(더 무엇인가 필요한지도 모르겠지만..) 또하나의 이야기는 Open Source가 이야기하는 코드의 안정성이 Anonymous CVS에 의해 구현되는데 즉 몇명의 개발자가 작성해 나가는 Trunk에 대해 아무나 와서 볼 수 있기에 버그가 줄어든다고 주장하고 있다. 뭐 일반 어플리케이션보다 유리하다는 주장에 대해서는 반대 견해도 있고 그렇지만 아무튼 이런 식의 코드변화 추적은 나름대로의 안정성 확보에 도움이 될 지 모른다.