Team Foundation Server2006. 9. 26. 22:58
 

현재 참여중인 프로젝트에서는 소스 제어 툴로 Team Foundation ServerSource Control사용하고 있다. 하지만, 아직 Beta 상태인 제품이라 부족한 면이 많은싶다. (아니면 원래 스펙에 빠져있는 건지도? -_-;;)


암튼, 문제가 되었던 것은..


개발자 A(편의상..)개인적인 사정으로 프로젝트에서 나가게 되었다. 그런데.. 그만 편집하고 있던 파일을.. 체크인 하지 않고 체크아웃을 버린 채로..나간 것이다.


이럴경우, Visual SourceSafe 이라면 간단하다. Admin Tool접속해서, 강제로 체크인해버리면 끝이니까.


그런데, TFS에는 별도의 Source Control대한 Admin Tool 은 없는 것이다.... -_-;;;


하지만, 방법이 없는 것은 아니다. TF.exe 명령어 Command사용해서 이런 일들을 수가 있다.


TF UNDO filespec /WORKSPACE:workspace;checkout_user

TF LOCK filespec /LOCK:NONE /WORKSPACE:workspace;lock_user


방법을 사용해서 개발자 A체크아웃을 해서 잠궈버린 파일을 다시 돌려 놓을 수가 있다. 위의 두 가지 구문은 사실은 좀 다르지만, 실제 효과는 같다고 보면 된다.


아래는 샘플.. (위의 구문과는 좀 다르지만 /Server 스위치를 사용해서 반드시 TFS서버를 지정하도록 한다.)

TF UNDO $/Project/SomeFile /WORKSPACE:WorkspaceOfA;UserA /Server:TFSServerName

Posted by kkongchi
Team Foundation Server2006. 8. 31. 11:11

지금 제가 참여하고 있는 프로젝트에서는 Microsoft Team Foundation Server를 사용하고 있다. 그래서 소스 제어도 TFS의 기능을 사용한다. 처음 쓸 때는 그 전에 많이 사용했던 Visual SourceSafe와 큰 차이가 없어 보였는데, 쓰면 쓸수록 이제 좀 차이들이 보이고 있다.


그리고 얼마 전에 아주 큰 차이를 하나 알게 되었다. 그리고 아주 당황...-_-;; 이 차이 때문에, 소스 제어를 사용하는 습관을 일부 바꿔야 하기 때문이다..


내용은 다음과 같다. 기존 VSS에서는 소스를 편집하기 위해서는 Check-out이란 것을 해야 한다. Check-out은 그 소스를 내가 편집하고 있다라고 마킹을 하면서, 다른 개발자들이 사용하지 못하게 Lock을 거는 것을 말한다. 이 점은 TFS도 다르지 않지만, 그 후에 결정적인 차이가 있다. VSS에서는 Check-out을 하게 되면, VSS 서버에 있는 최신 버전을 자동적으로 로컬로 다운로드 받게 된다. 당연히 다른 개발자가 뭔가 추가를 했거나 수정을 했을 수도 있기 때문에, VSS 서버에 있는 버전을 받아야 최신 상태의 소스를 가지고 편집을 할 수가 있다. 그런데, TFS의 소스 제어에서는 Check-out을 할 때에 서버 버전을 받지 않는다. 기존에 로컬 PC에 있던 버전이 그대로 있을 뿐이다.. 즉, 최근에 최신 버전을 받은 시점으로부터 Check-out을 하기 전 사이에 다른 개발자가 그 소스를 수정했다면, 그 수정 사항이 반영되지 않은 소스를 그대로 가지고 있게 된다는 것.


사실 혼자서 작성하고 수정하는 소스라면 전혀 상관은 없다. 혼자서만 작업하기 때문에, 굳이 서버에서 최신 버전을 받지 않아도 된다. 하지만, 두 사람 이상이 같이 작업하는 소스라면, 좀 불편한 상황이 발생한다. Check-out을 하기 전에 항상 최신 버전을 받아야만, 다른 사람이 작업한 부분을 로컬로 받을 수가 있는 거다. 그래서, VSS를 사용할 때와 달리 항상 Check-out과 Get Latest Version을 같이 해 주어야 하는 수고..가 발생을 한다. VSS 때의 습관(Check-out만 하는)을 가지고 작업하다 보면, 큰 문제가 발생할 수도 있다..(개발자들끼리 사이가 나빠지게 될 수도...-_-;;;)


이 사항은 TFS 소스 제어의 Bug가 아니라, By-Design이다. 하지만, 공식 문서에는 이 내용에 대해서 상세한 언급은 없다. MSDN의 블로그에 좀 자세한 이유를 분석한 기사가 있는데 참고할만한 내용이다. (http://blogs.msdn.com/buckh/archive/2005/08/20/454140.aspx) 이 글의 개요는 "TFS의 소스 제어에서는 각 개발자가 가지고 있는 로컬 복사본을 어떤 특정 시점의 Snapshot이라고 생각하고 있다. 그렇기 때문에 이 Snapshot의 통일성을 유지하기 위해서 이런 형태로 동작하게 만들었다" 라는 것이다. 음.. 뭐 일리가 있긴 하지만, 아무래도 여러 사람이 작업하는 경우에는 불편하지 않나 생각이 든다. 물론 거의 대부분 하나의 소스 파일은 한 명의 개발자가 작업하긴 하겠지만, 반드시 그 개발자만이 작업한다고는 볼 수가 없다. 잘 모르는 부분에 대해서 도움을 받는다던 지, 추가할 기능이 생겼다던지 등의 경우가 얼마든지 생길 수가 있다. 그럴 경우에는 연관된 개발자들이 꽤 불편하지 않을까 하는 생각이 든다.

Posted by kkongchi
Team Foundation Server2006. 3. 25. 16:59

  • 반드시 SQL 2005 가 필요하다.
  • SQL 2005를 설치할 때에, Reporting Service와 Analysis Service를 꼭 설치해야 한다.
  • SQL 2005를 설치할 때에, SQL Browser 서비스가 자동실행되도록 해야 한다. 설치한 후에 관리도구의 서비스에 가서 자동으로 설정해도 된다.
  • Sharepoint Team Service 2.0 을 설치할때, 반드시 서버팜옵션으로 설치해야 한다.
    • 기존에 Sharepoint Team Service 1.0, 혹은 2.0이 Microsoft SQL Desktop Edition과 함께 설치되어있었다면, 기존 STS와 MSDE 둘 다 삭제해야 한다.
    • STS 설치후에, 기본 웹사이트를 STS를 사용하도록 확장해야 한다. FrontPage Extension은 쓰지 않도록 설정해야 한다.
    • 기본웹사이트가  STS로 확장되었다면, 아마 SQL Reporting Service 관련 웹 디렉토리가 정상적으로 동작하지 않을 것이다. 반드시 관련디렉토리(Reports, ReportServer)를  STS  중앙관리에서 제외경로로 설정해야 한다.
Posted by kkongchi
Team Foundation Server2006. 2. 28. 00:57

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/TmFndFund.asp 문서의 요약으로, 회사 내부 세미나 용으로 작성한 것이다.


Team Foundation Server Fundamentals: A Look at the Capabilities and Architecture


What Is Team Foundation Server?


기능
Version control: 소스코드와 다른 버전 컨트롤이 필요한 산출물
Work item tracking: 버그, 요구사항, 작업, 시나리오 등의 추적이 필요한 아이템들
Project management functions: 소프트웨어 프로세스에 기반한 팀 프로젝트의 형성과 엑셀, 프로젝트를 사용한 계획/추적을 가능하게 한다.
Team build: 빌드를 위한 공통적인 프로세스를 가능하게 한다.
Data collection and reporting: 팀 파운데이션 서버에서 모아진 정보를 기반으로 해서 현재 프로젝트의 상태를 평가할 수 있게 해준다
The Team Project Portal; 셰어포인트 서비스를 이용해서 팀 커뮤니케이션의 중심을 제공한다.
Team Foundation Shared Services: 공통적인 기반구조 서비스를 제공해서 확장가능하고, 이 서비스들에 기반한 도구를 만들 수 있게 해준다.


The Shape of Team Foundation






Elements of Team Foundation Server
Project Management
 
  작업 항목 Tracking 기능을 통해서 프로젝트의 진행 상황과 위험도 등을 알 수 있다.
프로젝트 템플릿 기능을 통해서, 프로젝트 프로세스를 환경에 적합하게 맞출 수 있다.
디폴트 프로세스 템플릿 (MSF For Agile / MSF For CMMI)
이 템플릿은 확장/변형 가능해서 프로젝트나 환경에 맞게 고칠 수 있다.

Version Control
 
  SQL 서버를 사용
check-in, check-out, version management, and diff/merge
Shelving (보류) 등의 새로운 기능을 추가
체크인 정책(테스트, 코드 리뷰 등)
Work Item Tracking

버그, 요구사항, 시나리오, 작업 등의 모니터링이 필요한 항목들을 저장/관리할 수 있다. (작업 항목의 유형, 그에 따른 추가적인 필드등은 확장 가능하다)
Visual Studio IDE, 엑셀, 프로젝트 등에서 작업이 가능

Team Build

빌드를 수행하는 간단한 방식을 제공
테스트, 코드 리뷰, 작업 항목 업데이트 등의 기능을 빌드와 동시에 수행 가능
“빌드 서버” 기능을 지원
각 빌드의 로그(진행상황, 결과)등을 기록한다. 이 결과는 SQL에서 분석되어서 리포트된다.
Data Collection and Reporting
  모든 데이터는 SQL 에 저장
각 데이터는 DataWarehouse로 모여져서 분석된다.(SQL Analysis Service)
SQL Reporting Service를 통해서 리포트 형태로 출력될 수 있다.

The Project Portal

프로젝트 커뮤니케이션의 포탈로 이용할 수 있다.
문서 라이브러리 기능
프로젝트 템플릿에 따른 문서 샘플이 제공된다.

Shared Services

  모든 서비스는 확장 가능하도록 설계되었으며, Custom 툴을 만들어서 사용할 수 있다.

Architected for Extensibility


Linking service

  데이터 요소들 간의 느슨한 결합 관계를 연결시키는데 쓸 수 있다.
예를 들면, 버그와 그 버그를 해결하기 위해 수정한 소스 코드를 연결하는 데 쓸 수 있다.

Security service

팀 파운데이션 서버 보안 관련 API를 제공한다.
IT 서비스 팀이 팀 파운데이션 서버의 보안을 조정할 수 있는 툴을 만들 수도 있고, 다른 툴들에서 권한 부여용 API로도 사용할 수 있다.

Eventing service

웹 서비스 기반의 publish/subscribe 구조이다.
구독자는 특정 이벤트가 일어났을 때, 알림을 받을 수 있다. 이 구독자는  이메일 주소일 수도 있고, 웹 서비스일 수도 있다
Classification service

Linking service와 결합해서, 팀 파운데이션 서버 산출물들을 분류하는데 쓰인다.
예를 들어, 테스트는 모듈 단위로 분류되지만, 이 분류 서비스를 사용해서 팀 단위로도 분류할 수 있다.

Registration service
  새로운 도구가 추가되었을 때, 그 도구의 산출물 유형이나 이벤트 스키마 등등은 registration service 를 통해서 등록된다.

그 외 기능

VSIP (Visual Studio Industry Partner Program) 패키지를 통해서 Visual Studio IDE에 통합시키거나, 혹은 별도의 닷넷 프로그램을 만들 수도 있다.
새로운 툴과 관련된 도구들을 프로젝트 생성 마법사에 추가시킬 수도 있다.
새로운 툴과 데이터를 팀 익스플로러의 트리 노드에 추가시킬 수도 있다.
데이터 웨어하우스 스키마를 확장시켜서, 새로운 툴과 관련한 데이터만을 가져올 수도 있다.
Posted by kkongchi