VSS 마이그레이션 전략

Visual Source Safe 마이그레이션 이전에

많은 분들이 예전에 Visual Source Safe(이하 VSS) 를 사용하시면서, 현재는 이 VSS가 많은 골치거리라고 느끼시는 분들이 많이 계실 겁니다. 사실 소스 제어를 떠나서 VSS는 안정성 면에서 굉장히 불리하죠. 가장 흔하게 겪는 안전성의 문제는 파일 시스템 기반의 소스 제어 데이터베이스가 꼬이는 겁니다. 왜 꼬이는지는 알고 싶지 않지만, 오래 쓰면 쓸수록 꼬입니다.

제가 겪었던 꼬이는 대표적인 문제가 체크인 상태가 다른 사람에겐 체크인 상태가 아니라는 것이죠. 아무리 다른 사람이 최신 버전을 가져와도 그 소스 코드는 예전에 체크인 되었던 소스 코드이고, 불가피하게 강제로 다시 체크인해야 하기도 합니다. 뭐, 여기까지는 정말 가벼운 일상적인 문제이죠? 더 심한 경우는 복구 불능..!

최근 들어서, VSS의 이런 문제 때문에 많이 고생하시는 분들이 다른 소스 제어 제품으로 갈아타려는 준비를 많이 하십니다.

   

왜 VSS에서 이런 문제가 발생하나…?

사실 어쩔 수 없습니다. 지금에야 VSS가 실컷 얻어터질 수 밖에 없지만, 사실 예전에도 뚜렷한 대안이 있었던 것도 아닙니다.

VSS아니면 CVS(Concurrent Versions System) 인데, 이 CVS도 그 기능 자체의 구현이 충실하지 않아 문제점을 얘기하자면 VSS나 크게 별반 다를 것이 없었습니다. 참고로 Wikipedia 의 과거 소스 제어 제품을 보면 다음과 같지요. 즉, 당시에 VSS 보다 더 뛰어난 제품도 찾기 힘들었고, 현대의 이슈인 안정성과 성능, 보안의 요소는 어디를 뒤져봐도 없었습니다. 즉, 당시에는 어떤 제품을 선택하든 똑같은 문제를 겪었을 테니까요.

   

다만, VSS 제품은 VSS 2005 버전까지 오면서 많은 부분에서 보완이 되었지만, 사용자의 요구사항에 매우 소극적으로 대응했던 점에서 아쉬움이 남습니다.

아래는 조만간 나오게 될 백서의 내용 중의 일부이니 참고하세요.

일반적으로 '형상관리'라는 의미의 소스 제어는 소스 제어(Source Control), 버전 컨트롤(Version Control), 소프트웨어 환경 관리(Software Configuration Management)라고 불립니다. 향후 소스제어는 서버/클라이언트 아키텍처로 변경되면서 개발 조직에서 소스를 공동으로 개발하고 공유할 수 있게 되었습니다. 초기 Microsoft 에서는 소스 제어를 위한 소프트웨어로 Visual SourceSafe(비주얼 소스세이프) 를 내놓게 되었습니다. Visual SourceSafe는 처음 One Tree Software 라고 불리는 회사에서 여러 운영체제를 지원하는 소스 제어 솔루션을 만들었는데, Microsoft 는 이를 1994년에 인수하여 즉시 Visual SourceSafe 3.1 버전을 내놓았습니다. 그 이후로, Visual SourceSafe 4.0, 5.0, 6.0, 2005 버전까지 지속적으로 지원을 하다가, Visual SourceSafe 2005버전을 마지막으로 이 제품의 업데이트는 이루어 지지 않고 있습니다. Microsoft는 그 이후에 내부적으로 소스 제어 뿐만 아니라 버그 추적/품질 관리/제품 계획에 사용되는 솔루션을 만들었고, 그 이름은 "Product Studio" 라는 제품입니다. 이 제품은 Microsoft 내부적으로 사용하기 위한 제품이었고, 이 제품을 통해 노하우를 발전시켜 비즈니스 프로세스, 개발 등 전반적인 모든 개발 활동을 아우를 수 있는 "Visual Studio Team System, Team Foundation Server" 를 시장에 내놓게 되었습니다.

   

VSS to TFS2010 마이그레이션 전략

일단 아쉽지만 VSS와 같은 제품 군은 TFS(Team Foundation Server)에 100% 마이그레이션이 힘들 수 있습니다. 왜냐하면 VSS는 파일 시스템의 파일 단위 체크인 방식인데, TFS제품은 변경 집합(ChangeSet) 기반의 소스 제어 구조를 가집니다. 변경 집합은 변경이 일어난 묶음의 세트를 얘기하며, 이 변경 집합 덕분에 분기(Branch)/병합(Merge)/이력/관리가 매우 용이합니다. 덕분이 3-ways 방식의 병합이 매우 안정적으로 동작할 수 있고요.

VSS to TFS로 마이그레이션이 100% 보장할 수 없는 예를 들자면, 고객의 데이터베이스 스키마에 "주소"가 없는데, "주소" 컬럼이 생겼다고 주소를 가짜 데이터로 입력할 수 는 없는 노릇입니다. 게임을 예로 들면, 게임 시스템에 새로운 스킬이 생겼다고 종족/레벨/서버를 막론하고 모두가 이 스킬을 습득할 수 없는 것과 마찬가지입니다.

기존의 VSS는 레이블(Labeling) 방식의 이력 관리를 하였기 때문에, 이것을 변경 집합(ChangeSet) 기반으로 바꿀 수는 없습니다. 그래서 100% 마이그레이션이 힘든 한 가지 원인이기도 합니다. 그렇게 때문에 VSS to TFS로 마이그레이션을 결심하였다면, "퀑 대신 닭", "짜장면 대신 짬뽕","아이폰 대신 블랙베리" 라는 심정으로 100%를 기대하시면 오히려 독이 될 수 있답니다.^^

아래는 VSS to TFS 마이그레이션 전략을 메트릭스로 표현해 보았습니다. 물론, 이것 보다 더 많은 고려 사항이 있습니다만, 대략 아래의 정보에 답할 수 있다면 마이그레이션은 가능하다고 말씀 드리고 싶네요.

   

   

Team Foundation Server 및 .NET 플랫폼 기술 문의

언제든지 저희 Visual Studio Korea 공식 팀 블로그에 문의를 주시기 바랍니다. 저희가 모든 것을 가이드해 드릴 수는 없지만, 저희 팀의 다양한 분야의 기술 전문가들이 성의껏 여러분들을 도와드리고 있습니다. 저희 팀은 언제나 새로운 기술에 목말라있고, 먼저 고민하고 뼈저리고 값진 노하우를 경험한 컨설팅/개발/교육 및 강사 출신의 분들과 Microsoft MVP 활동을 하고 계신 많은 분들이 계십니다.

더불어, Microsoft 의 Social Forums 인 http://social.msdn.microsoft.com/Forums/ko-kr/categories/ 에 오시면 많은 전문가들의 생생한 고급 답변을 들을 수 있습니다.