TFSC로 철저한 소스관리와 프로젝트 전체의 유기적 연동을 함께

그러면 이번에는 VSTS의 소스 컨트롤 기능에 대해서 알아보도록 하자. 몇 년전만 해도 VCS(Version Control System)이라는 것 자체가 생소한 개념이었지만 지금은 많이 개선되어서 일선에서도 웬만한 큰 프로젝트는 소스 컨트롤을 반드시 해야 한다, 라는 생각들이 확산되어 있다. VS에서도 6.0버전부터 Visual Source Safe라는 VCS를 포함시켰으니까 사실 VS와 소스 컨트롤은 상당히 오랜 동반관계를 갖고 있다고 할 수 있다.

하지만 VSTS의 소스 컨트롤은 Visual Source Safe와도 다르고 CVS나 SubVersion 같은 오픈 소스 쪽의 어떤 VCS와도 같지 않다. 사실 Visual Source Safe와 같은 기능이라면 VSTS에 포함시켜 내놓을 필요가 없다. 그냥 지금 배포되고 있는 Visual Source Safe 6.0d를 쓰면 되는 것이다. 하지만 VSTS의 소스 컨트롤은 단지 소스의 버전만을 관리해주는 것이 아니라 Issue나 빌드등, 팀 프로젝트 전체와 유기적으로 연계되어 움직인다는 장점을 갖고 있다. MS에서 배포하는 문서에서는 Team Foundation Source Control(이하 TFSC)라는 이름으로 부르고 있는데 이 TFSC가 어떤 특징을 갖고 있으며 어떻게 사용할 수 있는지 이후의 원고에서 확인해보도록 하자.

솔루션의 추가

맨 처음 New Team Project를 선택해서 프로젝트를 만들면 그 안에는 문서나 가이드라인 등 프로젝트의 관리에 필요한 파일들은 있지만 솔루션은 하나도 없다. 그리고 트리형식으로 보여지는 프로젝트 내용 중에도 실제 개발에 사용되는 소스는 포함되어 있지 않다. 다만 가장 밑의 ‘Version Control'이라고 쓰여진 아이콘을 더블클릭하면 Source Control Explorer라는 창이 떠서 이 프로젝트에 사용되는 소스트리를 조회할 수 있게 해준다. 또는 View-Other Windows-Source Control Explorer를 선택해도 된다. 방금 만든 프로젝트는 하얀 백지처럼 아무런 소스도 포함되지 않은 상태이니 여기서 솔루션을 추가해보자.

1) 새 Team Project가 만들어져서 Team Explorer에 보이는 상태에서, File-New-Project에서 새 프로젝트를 시작한다. MFC든 C#이든, 어떤 프로젝트라도 좋다.

2) 프로젝트에 대한 옵션을 설정하고 Finish버튼을 누르기 전, ‘Add to Source Control'에 체크해준다.

3) 이제 소스 컨트롤의 어떤 폴더에 이 솔루션을 추가할 것인지를 물어본다. 원하는 위치를 지정하고 OK를 눌러준다.

여기까지 하면 Adding Files ... 라는 프로그레스바가 나타나서 잠시 있다가는 사라진다. 이것은 아직 Check In되어 있지 않은 상태이므로 Source Control Explorer에 나타나지는 않는다. 말하자면 '추가가 예정되어 있는 상태‘라고 보면 되며, Source Control Explorer에서 해당 프로젝트를 오른버튼 클릭한 후 'Check In Pending Changes'를 선택하면 그때야 비로소 TFSC의 Repository에 파일들이 저장되고 Source Control Explorer에도 나타나게 된다. 어째서 바로 파일이 추가가 되지 않았는가 ... 에 대해서 의문점을 갖는 독자분들도 있을텐데 그에 대해서는 이유가 있다.

ChangeSet

VSS와 가장 큰 차이점중의 하나가 이것으로, VSS는 개별파일들의 버전을 각각 관리하지만 TFSC에서는 한번에 Check In되는 파일들을 ChangeSet이라는 형태로 묶어서 관리하고 있다. 이것은 SubVersion에서의 그것과 같은 개념으로 CVS가 VSS와 유사한 방식으로 파일을 관리한다면 TFSC는 SubVersion과 비슷하다고 할 수 있다.

하지만 ChangeSet의 가장 큰 장점은 어떠한 제기된 안-버그리포트, 개선안, 의견(이것들을 총칭해서 Work Item이라 한다. 다른 도구들에서는 Issue라는 용어를 많이 사용한다) 등과 변경을 연계시킬 수 있다는 점이다. 말하자면 ’이번 ChangeSet은 제기된 Work Item #10에 의해서 작업한 것입니다‘라고 명시할 수 있다는 것이다. 이러한 기능은 추후에 소스의 History를 트랙킹할 때 대단히 많은 도움을 줄 수 있다.

그러므로 TFSC를 사용해 작업을 할 때는 VSS를 쓸 때처럼 하나하나의 파일을 수정한 후 Check In하지는 않게 된다. 하나의 파일을 수정한 것만으로는 Check In하지 않으며, 작업변경이 모여서 어떤 유의미한 단위가 되었을 때 비로소 로컬에서 수정한 파일들을 하나의 ChangeSet으로 하여 Check In한다고 생각하면 될 것이다. 그렇기 때문에 TFSC에서의 Check In은 대단히 엄격하게 이루어지고, 필요한 경우는 Check In Policy를 설정하여 원하는 조건을 충족하지 못하면 Check In이 아예 이루어지지 않도록 할 수도 있다.

Check In Policy

앞서 언급한대로 Check In은 ‘이 ChangeSet이 무결한 것입니다’라고 말할 수 있을 정도의 완성도를 가져야 할 수 있는 것인데, 그렇기 때문에 TFSC에서는 Check In시 몇가지 강제조항을 만들어서 함부로 Check In하지 못하게 하고 있다. TFSC에서 지정할 수 있는 Check In 옵션은 다음과 같다.

Clean Build : 프로젝트는 Check In전에 어떤 오류도 없이 빌드되어야 한다.

Static Analysis : Check In전에 반드시 Static Analysis 테스트를 거쳐야 한다. 당연히 fail나면 Check In은 되지 않는다.

Testing Policy : Unit Test와 같은 테스트가 반드시 Check In전에 수행되어야 한다.

Work Items : 하나 이상의 Work Item이 반드시 Check In과 연계되어야 한다.

보는 바와 같이 이런 테스트에서 걸리지 않고 한번 Check In하기도 쉽지는 않은 일이다. 그래서 TFSC에는 이를 보완해주는 장치가 있는데 그것이 바로 Shelving이다.

Shelving?

Shelve를 우리말로 하자면 ‘선반’이다. 이것은 작업자가 사용하는 개인적인 작업대에 비유할 수 있다. 소스를 Shelve하게 되면 이 파일들은 서버의 개별적인 개인적 공간에 저장된다. 마치 Check In한 것처럼 가져오고 Revert할 수 있다. 하지만 다른 사람들은 원칙적으로 이 변경된 소스를 가져올 수 없으며 이 상태에서 Check In해야 비로소 팀이 수정된 소스에 접근할 수 있게 된다.

그렇다면 왜 Shelving을 하는가? 바로 Check In하는 것이 더 간단하지 않은가? 생각해보면, Check In한 것처럼 소스 컨트롤을 할 필요가 있지만 Check In할 수 없는 경우가 있다는 것을 알 수 있다. 예를 들어 작업이 아직 완전히 끝나지 않아서(테스트가 불충분하다던가) 다른 팀과 공유하기 좀 뭣한 소스가 있을 수 있다. 하지만 그렇다고 해서 로컬시스템에만 소스를 남겨둔다면 다른 곳으로 이동해서 작업할 수가 없고 시스템에 문제가 생긴 경우 대단한 손실을 감수해야 한다. 또는 빌드가 아직 되지 않은(즉 빌드에 fail이 생긴 경우) 상태라면 Check In하기는 곤란해진다. 앞서 얘기했던 대로 TFSC의 Check In은 대단히 엄격하게 이루어지기 때문에 매일 Check In이 가능할 정도의 완성도를 갖는 소스를 뽑아내기는 쉽지 않은 일이다.

이를 위해 준비된 것이 Shelving으로, 이는 Check In과 아주 비슷하나 그 팀의 공용의 것이 아닌, 서버의 어딘가에 위치한 개인공간에 저장한다는 점만이 다른 것이다. 사용자는 ChangeSet과 마찬가지로 원하는 만큼 ShelveSet을 만들 수 있고, 선반에 소스를 올려놓는 것을 ‘Shelve'라고 하며, 선반으로부터 소스를 가져오는 것을 ’Unshelve'라고 한다(실제 메뉴명이 이렇다). 즉 사용자는 Unshelve로 자신이 작업하던 소스들을 가져올 수 있으며, 작업 후에는 다시 Shelve로 선반에 올려놓을 수 있다. 그러다가 이제 공유할 만큼 완성도가 높아졌다고 생각하면 Check In하여 팀의 작업공간에 추가시키는 것이다.

앞서 언급한대로 ShelveSet은 원하는 숫자만큼 만들 수 있는데 이는 여러 개의 선반을 갖고 있는 것에 비유할 수 있다. 사용자는 여러 개의 선반에다가 각각 다른 소스를 올려놓고 자신이 지금 필요한 소스를 Unshelve로 받아서 작업하게 되는 것이다. ShelveSet은 언제든 자신이 원할 때 삭제할 수 있으므로 사용자는 엄격한 규약을 지켜야 하는 Check In과 달리 좀더 자유롭게 소스를 수정하고 테스트해볼 수 있다. Shelving의 가치는 여기에 있다고 말할 수 있을 것이다.

마치며

이렇게 해서 VSTS의 소스 컨트롤인 TFSC에 대해서 간략하게 알아보았다. 설명한 바와 같이 TFSC는 단순히 소스를 관리해주는 것뿐만 아니라 VSTS의 다른 요소들과 연계해서 작동되는 것이 가장 큰 장점이라고 할 수 있다. 앞서 설명했던 것들이 TFSC의 가장 중요한 특징들이지만 그 외에도 Branch & Merge 등 VSS에서는 지원하지 않는 기능들을 다수 채용하고 있으므로 적절히 활용하면 소스를 체계적으로 관리하는데 큰 도움이 될 수 있다.

다만 아쉬운 것은 기능이 복잡해지면서 쓰기 위해 알아야 하는 선수지식의 양이 대폭 늘었다는 것이다. 사실 필드에 나가보면 Check In/Check Out의 개념이 어려워서 VSS를 사용하지 않는다는 사람들도 있을 정도인데 TFSC는 VSS보다 훨씬 복잡한 기능을 갖고 있고 소스 컨트롤 외에 Work Item 등과의 연계도 생각하고 있어야 하므로 이런 부문에 대한 지식이 없는 사람들이 금방 배워서 쓰기는 쉽지 않을 것 같다. 만약 TFSC가 너무 어렵게 느껴진다면 TFS를 설치하지 않고 기존에 쓰던 VSS로 소스 컨트롤을 하는 것도 나쁜 선택은 아니다. VSTS의 메뉴중에 소스 컨트롤의 종류를 선택하는 옵션이 있으므로 TFSC와 VSS를 선택해가면서 쓸 수도 있는 것이다.

어쨌거나 TFSC는 프로젝트 관리에 있어서 기본중의 기본이라고 할 수 있는 소스를 관리하는 부분이므로 향후 VSTS를 제대로 사용하고 싶다고 생각하는 독자는 개념만이라도 확실하게 익혀놓으면 득이 되리라 본다.

필자 노규남님은 게임개발에 주력하고 있으며, 오랫동안 각종 플랫폼에서 사용되는 개발도구를 사용한 경험이 풍부하다.