Team Foundation Server 2010 도입과 안정화 (1)

 2012년 초, 어플리케이션 개발 소스 버전 관리에 있어 MS Visual SourceSafe(이하 VSS)와 백업 폴더에 복사해두기 등의 개인적인 꼼수가 전국시대처럼 뒤얽힌 상황을 정리하기로 했다.^[각주:1] 실은 2010년도에 검토하던 MS Team Foundation Server (이하 TFS) 2010을 2011년에 도입하여 특정 프로젝트에서만 썼다가, Java와 같이 TFS가 기본적으로 지원하지 못하는 체제를 제외한 모든 프로젝트를 2012년에 들어서야 TFS에 옮기기로 한 것이다. (Java 쪽은 SVN으로 하되 서버를 통일하고 제대로 된 백업 수행)

 본사와 세 공장의 기존 어플리케이션을 TFS로 옮기는 과정은 그야말로 막노동의 극치였다.^[각주:2] 일단 VSS를 쓰던 곳은 그 흔적이 남지 않게 지워낸 후 TFS에 올려야 하는데 이런 저런 오류가 발생하면 패치를 찾거나 비주얼 스투디오의 버전을 올리는 등 일일이 방법을 찾아 해결해야 했다. MSSCCI Provider가 나와서 그나마 다행이긴 했지만^[각주:3] 마냥 편하지는 않아서 약간의 반발도 나왔다.

 본사는 밀어 붙여서 비교적 단기간에 끝낸 반면, 원격지의 공장 쪽은 쉽지 않았다. 사람이 문제이고 먼저이며 희망이었던 여러 가지 상황이 있었다.^[각주:4] 게다가 다들 이 일에만 매달려서는 안 되니^[각주:5] TFS에 올려야 할 것을 모두 올리는 데에 무려 1년 가까이 걸리고 말았다. TFS 재구성과 기존 개발 소스 migration을 NAM과 WON에게 온전히 맡기지 않았다면 내가 지레 포기하고 TFS가 없었던 것마냥 넘겨 버렸을지도 모른다. 버전 관리 정도 표준화 하는 데에 이렇게 시간이 오래 걸릴 줄은, 시작할 때에는 전혀 몰랐다.

 이제는 형상관리로 발전해 나갈 차례다. 요구사항과 산출물 관리를 유기적으로 통합하는 수준까지 올라야 한다. 그 중간에는 MS SQL Server의 Reporting Service를 활성화 하여 리포트 체제를 구현할 생각이다. 버전관리 체제 통합이 이루어진지 두 달 정도 되었는데 각 어플리케이션 담당자들 모두가 순순히 쓸 거라는 생각은 버려야지 싶다. 리포트를 만들어 Help desk^[각주:6]의 진척사항들과 TFS에서의 check in/out 활동이 의미 있게 연결 되는지 보고 싶다. 그런 보고를 할 수 있는 체제로 다져 나가서 개인과 IS팀 성과의 증거(근거 ^^)로서 활용하고 싶기도 하다.

***

 자바 쪽은 SVN으로 하는 데에 고민이 많았다. 일단 개발자 편의를 좀 더 생각하여 SVN 체제를 보존하되, MS Active Directory 계정을 쓰게 하고 백업체제를 강화^[각주:7]하는 것만으로 낙착을 봤었다. 그런데 2013년 3월 MS가 돌연 TFS의 Team Explorer Everywhere 2010을 무료화 했다. 더 고민하지 않고 TFS로 통일할까 한다.^[각주:8] SM하는 IS팀에서 형상관리 체제 두 가지를 병행 운용하기는 버겁다고 판단한다. 단, NAM과 WON이 당장은 너무 바쁘니 일정을 넉넉히 잡아 봐야겠다.^[각주:9]

 

1. 숙원사업 중에서 중위권 정도이긴 했는데 WON을 투입 받는 등 타이밍이 좋았다. [본문으로]
2. 전임자가 하지 않은 데에는 이유가 있다. [본문으로]
3. 없었으면 VB 6.0 류는 SVN에 넣었을 것이다. [본문으로]
4. 내가 실무자가 아니어서 다는 모른다. [본문으로]
5. 중간에 법인 통합 (ERP 통합) 같은 굵직한 프로젝트 외에도 자자분한 프로젝트들이 많았다. [본문으로]
6. TFS와는 별개인 기존 시스템 [본문으로]
7. 가산의 데이터 센터와 대덕의 재해복구 센터가 동시에 폭격을 당하지 않는 한 개발 소스는 안전하다. TFS도 마찬가지. [본문으로]
8. SVN 체제 구축은 WON이 정말 애썼는데 아쉽기는 하겠다. [본문으로]
9. 때문에 Team Foundation Server 2010 도입과 안정화 (2)는 언제 쓸지 모르겠다. [본문으로]