위 내용에서 확인할 수 있듯이, 기존 웨어하우스 데이터베이스를 삭제하면 자동으로 다시 만들어준다고 합니다. 하지만 위와 같은 오류가 나면 삭제도 안됩니다. 다른 데이터베이스 이름을 사용하기도 싫군요^^; 선뜻 데이터베이스를 삭제하기도 그렇고, 백업 오류도 발생하여 Hyper-V 의 스냅샷을 찍어두고 데이터베이스를 삭제하고 다시 만들어 보았습니다.
1. SQL Analysis 데이터베이스를 정지합니다.
2. 아래의 폴더로 이동한 후, Tfs_Analysis.0.db 폴더의 이름을 변경합니다. %ProgramFiles%\Microsoft SQL Server\MSAS10.MSSQL2008\OLAP\Data
3. 다시 MSSQL Analysis 서비스를 시작합니다.
4. Tfs_Analysis 데이터베이스에서 마우스 오른쪽 버튼을 클릭한 후, 삭제를 선택합니다.
5. 개체 삭제에서 확인을 클릭합니다.
6. Team Foundation Administration Console 의 Application Tier-Reporting 메뉴로 이동한 후, Edit 를 클릭합니다.
7. 각 탭 메뉴에서 Test Connection 을 클릭하면, '기존의 데이터베이스가 없는 경우 새로 생성된다는' 메시지와 함께 테스트가 성공합니다.
8. 모든 구성을 완료하였으면, OK 버튼을 클릭합니다. 그럼, 새로운 Analysis Database 가 생성이 되는 작업을 진행합니다.
9. MSSQL Analysis 서버에 Tfs_Analysis 데이터베이스가 새로 생성된 것을 확인할 수 있습니다.
10. Team Foundation Administration Console 의 Reporting 메뉴에서 Start Job 과 Start Rebuild 메뉴를 차례로 클릭해 줍니다.
11. 모든 웨어하우스와 관련된 서비스가 정상적으로 동작하는 것을 확인하고 작업을 완료합니다.
다시팀장이 VS TFS는설치할때고생하던데? 특히계정이잘못되면설치하고도못쓴다는데? 괜찮겠게어?
답은계정설정은필요없습니다.
그냥설치하면 ~ 끝이라는것입니다.
이제정말설치전할일에대하여말해보겠습니다. 하드웨어는준비되어있다고하면, 이제
당근 Windows를설치합니다. Windows Server 2003 SP2 / Windows Server 2003 R2 SP2
Windows Server 2008 / Windows Server 2008 R2
이렇게지원합니다.
Windows Server 2003 에서는 Service pack 2을설치해야하는중요포인트(?)입니다.
이제 Windows Server 2003을사용하는곳도있고 Windows Server 2008 을사용하는곳도있을겁니다.
요즘은 Windows Server 2008 R2 가나오기때문에 R2를기준으로하겠습니다.
설치전에기본적으로해주여야하는것이있습니다. 다른것은아닙니다.
.NET Framework 3.5 설치와 IIS(웹서버)만설치하시면됩니다.
Windows Server 2008이상이라면 .NET Framework 3.5 이상이이미있기때문에별도설치는하지않고 Windows에서추가기능설치만하시면됩니다. IIS 웹서버도마찬가지입니다. 최신서버인 Windows Server 2008 R2는 64bit를지원하는데이번설치편은 Windows Server 2008 R2 에서진행합니다.
Team Foundation Server 2010 은 많은 부분 획기적인 변화를 가져왔습니다. 기능적인 부분은 더할 나위 없거니와 관리적인 부분은 이전 버전을 운용해 보신 분이라면 과히 편해졌다고 할 수 있습니다. AT(Application Tier) 와 DT(Database Tier) 전반적인 부분에 걸쳐 한 자리에서 관리적인 부분을 모두 커버할 수 있기 때문입니다.
하지만, Team Foundation Server 2010 의 새로운 기능 중의 Test & Lab 부분이 상당히 강력해졌지만, 새로운 플랫폼과의 결합과 새로운 개념 등으로 환경 구축이 쉽지만은 않습니다. 필자도 이러한 부분에서 많은 부분 시행 착오를 겪으며 정리한 내용을 공유하고자 합니다.
Team Foundation 의 운용을 어렵게만 느끼지 마시고, 문제가 발생하면 바로 아래의 링크를 통해서 확인해 보는 것도 좋은 방법일 것 같습니다.^^
Visual Studio 2010을활용한 ALM(Application Lifecycle Management)
ALM 이란무엇인가?
효율적인프로젝트를위한애자일한프로세스–프로세스강요
명확한작업의관리와지속적인통합–추적성
과거와현재를알면미래가보인다–가시성
ALM 과가상화의만남– Test and Lab Management
엄준일 : 닷넷엑스퍼트(.NETXPERT) 에선임컨설턴트로재직중이며, Microsoft Team System MVP 로활동하고있다. 많은대기업프로젝트와컨설팅경험을바탕으로좀더좋은소프트웨어를만들기위한기반을만들며, .NET 은우리의미래동반자임을확신하고꾸준히새로운기술을전파하고있다. (http://blog.powerumc.kr)
작성자: 엄준일선임/ Microsoft MVP
감수자:안재우수석/Microsoft MVP
ALM(Application Lifecycle Management) 의 개요
최근 몇 해 사이에 ALM(Application Lifecycle Management)라는 용어를 자주 듣게 되었고, ALM에 대해 논의를 하게 되고, ALM 을 해야 한다라는 말을 자주 듣게 됩니다. 최근 들어, 실제로 많은 기업이나 조직에서 ALM 도입을 검토하고 있고, 왜 ALM에 대해 열광하는지에 대해서도 궁금한 부분이 아닐 수 없습니다. 그렇다면 우리는 이제 ALM이 무엇이고, 왜 등장하였으며, ALM에 대한 오해와 진실에 대해서 충분히 이야기를 나눌 가치가 있다고 생각합니다.
ALM 이란?
ALM(Application Lifecycle Management, 이하 ALM)을 한글로 번역하면 "응용프로그램 수명주기 관리" 라고 합니다. 현대 사회는 문화, 언어, 가치관, 기술 등이 빠르게 발전하고 있습니다. 문명의 발전이 없다면 죽은 문명이고, 마찬가지로 소프트웨어가 변화하고 발전하지 않으면 죽은 소프트웨어나 마찬가지 입니다. ALM 을 쉽게 말하면 바로 이런 소프트웨어가 생산되고 릴리즈, 유지, 관리하기 위한 기술을 총칭합니다.
ALM 등장배경
예전부터 소프트웨어를 개발하는 방법이 꾸준히 연구되었으며, 그 중 가장 대표적인 방식이 SDLC(Software Development Lifecycle) 입니다.
SDLC 의 대표적인 개발 방법론 중에 폭포수 모델(Waterfall Model)이 있는데, 로이스(Royce) 라는 사람에 의해 정의된 폭포수 모델은 요구사항, 디자인, 구현, 통합, 테스트, 릴리즈, 유지보수라는 단계로 구분이 되며, 각 단계는 순차적으로 진행되게 됩니다. 요구 사항이 없으면, 디자인을 할 수 없고, 디자인을 하지 않으면 구현을 할 수 없는 형태의 개발 방법으로 현 단계에 문제나 오류가 발생하게 반드시 위험 요소를 제거한 후에 다음 단계로 이동하게 됩니다. 이러한 개발 방법은 각 단계별로 상하 연관성이 없고 명확하게 구분되어 있으며, 최근에도 이러한 개발 방법으로 많은 프로젝트가 진행됩니다.
그림 1 일반적인 폭포수(Waterfall) 모델
하지만 최근 이러한 Top-Down 방식의 수직적인 개발 방식에 많은 비판을 받고 있습니다. 초기 계획이 완벽하지 않으면 전체 일정 또는 계획이 완벽하지 않다는 의미이기 때문입니다. 고객도 자신의 정확한 요구 사항을 알지 못합니다. 이런 과정에서 프로토타입(Prototype) 을 고객에게 시연하고 고객의 정확한 요구 사항을 도출해야 합니다. 하지만 고객의 요구 사항은 언제나 변할 수 있습니다. 즉, 완벽한 요구 사항을 정의한 후에, 다음 단계로 넘어간 이후에도 고객의 요구 사항은 변할 수 있고, 그렇다면 어찌되었건 초기 계획이 잘못될 수 밖에 없습니다. 이미 구현과 테스트로 검증이 끝난 기능에도 기능적인 기능의 추가 및 변경, 디자인 요소의 변경 등을 이유로 고객의 요구 사항은 변할 수 있고, 그렇다면 다시 원점으로 돌아가 이전의 계획은 수정이 되어야 하며, 이미 이러한 경우는 최초 계획이 잘못되었다고 생각할 수 밖에 없습니다.
그 이외에도 초기 계획을 얼마나 정확하게 수립할 것인지는 굉장히 민감한 문제이기도 합니다. 초기 계획 단계를 지나치게 명확하게 강조할 경우 그만큼의 비용이나 시간이 추가되는데, 전체 프로젝트의 일정과 대비하여 그것이 지나칠 경우 실제로 구현이나 테스트를 해야 할 시간은 촉박해 질 수 밖에 없습니다. 프로젝트의 기간은 6개월인데 정확한 프로젝트의 계획 수립을 위해 3개월의 시간을 소비한다면 분명 구현이나 테스트를 여유 있게 할 수 없을 것입니다. 고객을 이해시킬 수 있는 신뢰된 계획안을 보여줄 수 있겠지만, 오히려 불필요한 문서의 양산할 수 있을 가능성이 충분합니다. 이런 경우 프로젝트의 단계별로 거꾸로 기간을 산정하는 역산법 등을 이용하기도 합니다.
폭포수 모델(Waterfall Model)은 여러 가지의 문제 제기를 통해 다양하게 변형된 모델로 발전해 왔습니다. 여기에서는 설명하지 않을 예정이지만, 소프트웨어 개발 방법론은 여러 가지 변형된 형태로 발전해왔음을 알 수 있습니다.
그렇다면, ALM 의 등장 배경을 얘기 하기 위해 왜 이렇게 긴 SDLC(Software Development Lifecycle) 이야기를 했을까요? 위의 이야기에서 볼 때 SDLC 는 바로 소프트웨어를 개발하기 위한 방법론이라는 것입니다. SDLC 는 소프트웨어 공학에서 정의하는 용어로써, 소프트웨어를 효과적으로 개발하기 위한 다양한 방법을 이야기 한다는 것입니다. 즉, SDLC 은 소프트웨어를 개발하는 기술적인 관점을 이야기 합니다.
ALM 은 바로 소프트웨어를 개발하기 위한 기술적인 관점과 더불어 비즈니스적인 가치를 융합하도록 합니다. 소프트웨어의 개발은 기술적이거나 방법적인 문제와 더불어, 실제로 조직 간의 이해 관계, 그리고 비즈니즈 관계의 영역까지 확대됩니다. 소프트웨어를 개발하기 위해 프로젝트의 비전이나 목표 그리고 이것을 이행하기 위한 여러 방법론적인 단계는 통합되고 유기적인 관계입니다. 단지 기술적인 관점에서 바라보는 것이 아닌, 비즈니스 관점에서의 이해 관계나 조직의 측면도 ALM 에서 포괄하고 있습니다.
그렇다면 ALM 은 전혀 새로운 기술이 아님을 알 수 있습니다. ALM 은 이미 오래 전부터 조직적으로 알게 모르게 수행하였고, ALM 을 수행하기 위해서는 어떠한 프로세스적인 요소를 강제하고 있었습니다. 마치 군대에서 기상->아침 구보->보고(점호)->아침 식사-> … -> 저녁 식사->청소->보고(점호)->취침 과 같이 매일 반복되는 프로세스와도 유사할 수 있습니다. 그리고 이런 프로세스가 잘 진행되는지의 여부를 알기 위해 상사에게 "보고" 하는데 소프트웨어 개발 측면에서는 각종 산출물이나 보고서가 필요합니다. 그리고 병사들이 야간 근무를 교대하고 활동을 추적하기 위해 교대 시간마다 기록을 하게 됩니다.
프로세스 강요(Process Enactment)
일관된 프로세스를 강요해야 함
가시화(Visibility)
모든 전반적인 활동에 대한 진행 상황을 볼 수 있어야 함
추적성(Traceability)
모든 활동이나 산출물 등 연관 관계를 추적할 수 있어야 함
표 1 ALM 의 3대 구성 요소
하지만, 이러한 일련의 통일되고 융합된 활동을 한다는 것은 쉽지 않습니다. 문서화나 정형화된 프로세스조차 없는 팀이나 조직이 있는 경우도 있고, 암묵적인 프로세스가 존재하지만 어쨌든 이런 프로세스를 강요한다는 것은 쉽지 않습니다. 또한 팀의 매니저 또는 PM(Project Manager) 나 그 위의 상부 조직은 일이 잘 진행되는지 궁금해 하기 때문에, 이러한 이유로 개발자는 팀장 또는 상사에게 일일 보고서나 주간 보고서를 작성하고, 이것을 다시 취합하여 최종 보고서로 작성합니다. 프로젝트의 단계가 진행될수록 보고서의 양은 늘어나고, 그 종류도 다양해질 것입니다. 어찌 보면, 프로젝트를 위한 프로젝트가 아닌, 보고서를 위한 프로젝트가 되어버리는 셈입니다.
이젠 활동이나 작업을 추적하는 것도 어려울 것입니다. 수십 수백의 여러 가지 종류의 보고서는 이제 버전 관리 하기 조차 버거워질 수 있습니다. 또한 각 역할 담당자들은 결과물, 인도적 차원, 유지보수 차원에서 다양한 산출물을 양산해 냅니다. 필요에 의해 과거의 산출물을 찾는 것도 어렵고, 산출물 자체를 유지 보수 하는 것도 어려워 집니다. 그 외에도 변화하는 모든 활동들은 어떻게 변화했는지조차 알 길이 없습니다. 다양한 산출물과 활동, 그리고 변화에 대한 추적이 불가능 하다면 이미 양산된 문서를 관리하는 것은 결국 의미 없는 활동일 수 있습니다. 실제로 컨설팅 의뢰로 기업을 방문하여 문제를 진단하기 위해 몇 가지 산출물을 요청하여 받은 적이 있으나, 아키텍처가 실제 시스템과 너무 달랐고, 언제, 어떻게 달라졌는지 아는 사람은 아무도 없었던 적도 다반사이기도 합니다.
ALM 의 3대 구성 요소를 조직 전반적으로 융합하기 위해서는 ALM 솔루션이 필요합니다. 관리가 어렵고 정확성을 요구하는 ALM 을 좀 더 쉽게 실현할 수 있는 도구가 필요하다는 것입니다. 초기의 ALM 은 마케팅적인 용어로 사용되면서 초기 ALM 솔루션도 매우 난해했습니다. 단순히 이슈 추적 기능과 소스 제어 기능을 합하여 ALM 이라고 하였으며, 어떤 ALM 솔루션은 테스팅 도구만을 통합하여 ALM 솔루션이라고 하기도 하였습니다.
그림 2 ALM 의 전체적인 컨셉
최근에 ALM 이 정착하는 단계에 들어서면서, 현재의 ALM 과 미래의 ALM 을 분류하기도 합니다. 그리고 아직 이러한 분류 단계는 미성숙한 단계이므로 여러 방면으로 각기 해석을 하고 있습니다. 내용을 정리해 보면 아래와 같이 요약할 수 있습니다.
ALM 0.5 (미성숙 단계)
단순히 여러 가지 소프트웨어 개발 도구를 통합한 제품
ALM 1.0
개발 프로세스의 일관성과 소프트웨어 개발 도구를 통합하고, ALM 실현이 가능한 제품
ALM 2.0
다양한 플러그인의 조합 가능하고 크로스 플랫폼 간의 표준적인 방안을 제시.
조직 내부 뿐만 아니라 시장에서의 각종 요구 사항 또는 변화에 대응
표 2 ALM 의 단계별 정의
위의 내용으로 볼 때, 앞으로 알아볼 Visual Studio 2010 과 Team Foundation Server 2010 은 이미 ALM 2.0 에 매우 근접해 있습니다. 기본적인 ALM 1.0 요소를 충분히 충족하고 있으며, 각 제품은 확장성이 뛰어나고 다양한 클라이언트를 지원하기 위한 크로스 플랫폼을 실현하였습니다.
ALM 의 오해와 진실
ALM 은 아직까지도 많은 오해와 진실 속에 자주 언급되는 용어입니다. 사실 ALM 을 알고 보면 SDLC(Software Development Lifecycle) 처럼 정형화된 어떤 유형의, 또는 무형의 지식으로 갑자기 나타난 기술이 아닙니다. 그리고 무언가를 해결하기 위한 완벽한 솔루션도 아닙니다. 아직도 마치 ALM 에 대해 뜬 구름 잡는 듯한 느낌이 든다면 아래의 몇 가지 질문 답변 형식으로 좀 더 ALM 에 대해 오해와 진실을 이야기 해보도록 하겠습니다.
Q: 그럼 도대체 ALM 은 무엇인가요?
A: 마치 Web 1.0 과 Web 2.0 을 비교하는 것과 같습니다. 기존 Web 1.0 은 기업이나 서비스 제공자에 의해 제공되고 그 주체가 바로 기업이나 서비스 제공자였습니다. 하지만 Web 2.0 의 컨셉은 개방, 협력, 참여, 공유라는 요소를 중심으로 차츰 주체가 사용자에게로 이동하는 트랜드화된 용어이기도 합니다. Web 2.0 의 대표적인 것이 바로 UCC 나 위키피디아(Wikipedia) 와 같은 것들이 있습니다.
ALM 도 이런 트랜드에 크게 벗어나지 않는 용어입니다 ALM 은 궁극적으로 3대 구성 요소를 쉽게 실현할 수 있도록 하였지만, 이것을 실현하기 위해 설계, 개발, 테스트, 유지 보수 등 개발 조직, 운영 조직, 비즈니스 조직 등 여러 조직간에 의사 소통이나 각 단계별로 독립적인 활동을 유기적으로 통합하고 신뢰할 수 있는 데이터를 제공할 수 있도록 ALM 솔루션은 여러 가지 도구와 연동하거나 통합하고 자동화하였습니다.
최종 소프트웨어를 사용할 고객은 품질 좋은 소프트웨어를 사용하길 기대합니다. 요구 사항, 아키텍처, 개발, 테스트, 릴리즈, 유지 및 관리, 추적 등 모든 과정을 ALM 솔루션 안에서 이루어 집니다. 이후에 설명한 Visual Studio 2010 과 Team Foundation Server 2010 을 이용하여 개발 프로세스가 어떻게 개선되고 편리해지며, 어떻게 ALM 을 실현하는지에 대해 천천히 짚고 넘어갈 예정입니다.
Q: 그럼 ALM 을 실현하려면 ALM 솔루션이 필요한가요?
A: 아닙니다. ALM 을 실현하기 위해서 반드시 ALM 솔루션이 필요하지 않습니다. 위에서 군대를 예로 든 ALM 의 3대 구성 요소를 설명한 바 있습니다.
실제로 여러 프로젝트를 경험하면서 ALM 과 유사한 경험을 많이 해 보았을 것입니다. UML 도구를 사용하고 엑셀로 요구 사항이나 개발 진행 관리, 그리고 엑셀의 함수나 스크립트를 이용하여 보고서를 만들고, 테스트와 테스트 문서 및 코드 리뷰 과정을 수동적으로 한 바 있습니다. 사실 관리적인 부분만 본다면 엑셀만큼 뛰어난 도구도 없을 것입니다.
하지만 실제로 수동적인 ALM 실현은 많은 어려움이 따릅니다. 가장 먼저 문서를 매번 업데이트해야 하는 시간적인 문제와 문서의 버저닝(Versioning), 변화에 따른 계획의 수정 및 문서 수정, 테스트를 위한 테스트 케이스 관리 및 테스트 결과 문서화, 그리고 수동적인 코드 리뷰는 사실상 있으나 마나 한 단계이기도 합니다. 특히 반복적인 짧은 릴리즈는 밤을 새게 하는 주요 원인 중의 하나이기도 합니다. 릴리즈 계획도 문제였지만, 버그의 발생은 곧바로 버그의 상황을 문서로 만들어져야 하는 산출물이 되기도 하기 때문입니다.
분명 ALM 솔루션은 여러 가지 어려웠던 요소들을 통합하고 자동화하였습니다. 결과적으로 ALM 은 도구가 없이도 가능하지만, 실현하기 위해서 훨씬 많은 노력이 필요하다는 것입니다.
Q: 우리 팀은 형상 관리(소스 제어) 만으로도 프로젝트가 잘 됩니다. 과연 ALM 솔루션이 필요한가요?
A: 맞습니다. 현재 자신의 팀이나 조직에서 정형화된 프로세스나 암묵적인 프로세스가 존재하고, 개별적인 문서 관리와 소스 제어만으로 ALM 을 실현할 수 있습니다. 그렇다면 현재 자신의 조직이나 팀은 ALM 레벨은 ALM 0.5 세대에 있다고 보시면 됩니다.
소프트웨어의 품질을 높이기 위해서는 많은 노력이 필요합니다. 소스 코드나 문서의 버전 관리, 테스트, 보고서, 빌드, 이슈나 작업의 추적은 한 두 명의 개인이 수행하기는 매우 힘듭니다. 그렇기 때문에 보다 도구를 통합하고 자동화된 솔루션을 통해 ALM 을 수행한다면 훨씬 많은 이점이 있습니다.
Q: 그럼 ALM 을 원활하게 수행하기 위해서는 통합된 ALM 솔루션이 필요한가요?
A: 그렇지 않습니다. 현재 소프트웨어를 개발에 필요한 많은 도구들이 오픈 소스 또는 무료로 제공이 되고 있습니다.
표 3 Team Foundation Server 와 오픈 소스 기반의 도구를 통한 ALM 도구 비교
하지만 오픈 소스를 사용하는 것은 저렴하게 ALM 환경을 갖출 수 있지만, 이음매 없는 매끈한 끈과도 같습니다. 도구들 간에 서로 연관성이 없거나 업그레이드가 되지 않는 것들도 상당히 존재하기 때문입니다. 통합되지 않은 각 도구들은 누가 관리를 할 것이며, 연관성이 없는 각 도구들 간의 프로세스를 어떻게 강요할 것인가도 고민해 보아야 할 부분입니다.
Team Foundation Server 2010 을 설치하는 중 TF255040 오류가 발생하였습니다. 아래의 그림과 같이 SQL Server 의 Reporting Services 와 관련된 컴포넌트가 설치 되지 않았다는 오류입니다. 훔...
SQL Server Analysis Services 인스턴스를 찾지 못한다는 오류 메시지가 나타납니다.
TFS 설치 오류 로그를 자세히 보면 아래와 같이 문제 지점의 예외 메시지를 찾을 수 없습니다.
[Error @12:07:34.650] Microsoft.TeamFoundation.Admin.TfsAdminException: TF255040: Install SQL Server Reporting Services or at a minimum SQL Client Connectivity Tools on the application tier to ensure Analysis Services object model is present for warehouse processing. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.AnalysisServices, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. 지정된 파일을 찾을 수 없습니다.
왜냐하면 SQL Express 버전을설치하면되지만, 결국 SQL Server 인스턴스를만들어야하기때문에왠지 TFS 전용서버의순결함을잃는듯하군요.. 사용하지도않을 SQLEXPRESS 라는반갑지않은인스턴스와말이죠. 두번째 SQL Server 2008 Feature Pack 은 SQL Server 의구성요소일부만설치할수있습니다. 제가필요로하는 Analysis Service 관련어셈블리만설치되도록설치패키지를제공해주고있습니다.
그럼 Microsoft SQL 2008 관련구성요소를설치해주어야하는데, 아래의주소에서기본적인클라이언트가설치되도록합니다. 근데 Management Studio Express 를설치하게되면 SQLEXPRESS 라고하는인스턴스가설치가되는데 Team Foundation Server Application Tier 에 SQLEXPRESS 인스턴스가그다지필요해보이지도않고, 설치시간도오래걸리고요.
Team Foundation Server 2010 은 기존의 2008 버전에 비해 굉장히 설치가 간단해 졌습니다.
사실 설치과 구성 패키지 자체는 TFS 2008 이 간단하긴 했지만, 구성이 올바르게 완료되어야만 설치가 가능했었습니다. 이런 문제로 인해서 초기 설정이 유효하지 않을 경우 설치를 완료한들 다시 제거를 하고 재설정을 했던 경우가 많았습니다. 그리고 TFS 2008 에서는 설정 정보가 IIS 의 TFS Web Service 의 web.config 와 데이터베이스의 특정 필드를 직정 수정해야 하는 관리상의 불편함이 많았습니다.
하지만 이번 Team Foundation Server 2010 는 이런 면에서 초기 설치 단계에서 구성하는 단계까지 많이 편리해졌습니다. 설치와 구성을 따로 따로 하도록 말이죠.
아래는 Team Foundation Server 2010 을 설치하고, Team Foundation Server Administration Console 을 이용하여 TFS 환경을 구성하는 방법입니다.
아래의 설치 과정은 3-tier 로 구성된 서버에 TFS 2010 을 설치하는 단계입니다.
서버 1 : Active Directory, DNS 서버
서버 2 : MSSQL 2008
서버 3 : Team Foundation Server 2010
Team Foundation Server Administrator Console 을 실행하여 Configure Installed Features 를 클릭합니다.
다중 Tier 환경으로 설치할 예정이므로, Advanced 를 선택하고 Start Wizard 를 클릭합니다.
Wizard 안내 페이지입니다. 그냥 다음으로 넘어 갑니다.
SQL Server 의 인스턴스를 입력하고 Test 를 클릭합니다. 인스턴스가 유효하면 푸른색 V 표시가 나타나고, 다음으로 넘어 갑니다.
Service Account 계정을 입력하고 Test 를 클릭해보고, 계정이 유효하면 다음으로 넘어갑니다.
Team Foundation Server 2010 의 웹 서비스의 설정을 합니다. 그냥 기본 구성 그대로 다음으로 넘어갑니다.
보고서를 구성하는 페이지의 안내입니다. 필자는 보고서를 구성할 것이므로, Configure Reporting for use with Team Foundation Server 항목 체크 박스를 체크 한 후에 다음으로 넘어갑니다.
Reporting Service 인스턴스를 입력하고 Populate URLs 를 클릭하면 유효한 보고서 서비스를 찾아줍니다. 그리고 다음으로 넘어갑니다.
TFS Report 서비스의 실행 계정을 지정해 줍니다. 필자는 기본 계정인 NETWORK SERVICE 계정을 사용합니다.
아래는 Sharepoint 를 설치를 안내하는 페이지 입니다. 다음으로 넘어갑니다.
Sharepoint 서버의 계정을 입력하고 Test 를 클릭하여 유효성을 검사합니다. 그리고 다음으로 넘어갑니다.
기본적으로 Team Project Collection 이 체크되어 있습니다. 그대로 다음으로 넘어갑니다.
모든 설정이 완료 되었습니다. Verify 를 클릭하여 최종 점검을 진행합니다.
Verify 결과가 양호할 경우 설치를 진행하도록 합니다. Configure 를 클릭하여 설치를 진행합니다.
아래는 Team Foundation Server 2010 이 설치가 완료되었습니다.
이제 설치가 완료되었고, Team Foundation Server 관리를 위하여 관리 권한을 지정합니다.
Application Tier 의 Administer Group Membership 을 클릭합니다.
Team Foundation Administrators 그룹을 더블 클릭(또는 Properties 클릭) 하고, 관리자 계정을 지정해 줍니다.
이제 모든 설치와 구성을 마쳤습니다. 아래의 그림은 Visual Studio 2010 으로 Team Foundation Server 2010 에 연결된 모습입니다.
Configure Team Foundation Build Service 에서 Start Wizard 를 클릭합니다.
아래는 Build Service 설치 안내 페이지 입니다. 다음을 클릭합니다.
Team Build 를 수행한 Team Project Collection 을 지정해야 합니다. Browser 를 클릭하여 Team Project Collection 을 선택합니다. 만약 Team Foundation Server 와 연결되지 않은 상태일 경우 Team Foundation Server 와 연결해야 합니다.
기본 설정대로 Recommended 를 선택하고 다음을 클릭합니다.
Team Build 를 수행할 계정과 포트를 입력합니다. 필자는 TFSBUILD 계정으로 사용하였고, 환경에 따라 NETWORK SERVICE 등으로 사용하셔도 됩니다.
모든 설정이 완료 되었고, Verify 를 클릭하여 Team Build 환경을 점검합니다.
댓글을 달아 주세요