팀 파운데이션 서버(Team Foundation Server) 를 쓰지 말아야 하는 진짜 이유 #1

필자는 얼마 전에 다음과 같은 글을 썼다. TFS를 그다지 좋아하지 않는 분의 글을 검색 중에 우연히 찾게 되었고, 이에 대해 필자의 의견을 남긴 적이 있다.

개인적인 의견에 필자가 반박한 것이기도 했지만, 필자는 기능적인 면에서 반박을 한 것이라 상대방의 마음이 상할지 몰랐으나, 다시 돌이켜보면 미안한 맘이 계속 든다.

과거 필자는 MS Visual Studio ALM MVP 로서 이 제품을 써야할 이유를 말할 수 있었으나, 지금은 중간적인 입장에서 TFS를 쓰지 말아야 하는 진짜 이유도 써보고 싶었다. 최근 필자는 TFS 이외의 다양한 제품을 접하면서 TFS를 쓰지 말아야 하는 이유에 대해 더욱 확신이 들었다.

우리나라에는 전문가가 없다

우리나라에 팀 파운데이션 서버(Team Foundation Server) 전문가가 없다. 그러므로 당신에게 도움이 될 만한 전문가의 손길은 없을 것이다. 팀 파운데이션 서버(Team Foundation Server) 는 모든 것을 통합한 ALM(Application Lifecycle Management) 제품이다. ALM(Application Lifecycle Management)을 이해하려면 가장 먼저 소프트웨어 공학부터 시작하고 이해해야 한다. 그리고 사용자 측면과 관리적 측면 모두를 이해하고 솔루션 환경을 제공해야 한다.

ALM 제품을 쓰기전에 소프트웨어 공학을 설명하지 못하면 왜 팀 파운데이션 서버(Team Foundation Server)를 써야 하는지도 설명할 수 없다. 소프트웨어 공학은 50년도 되지 않는 짧은 역사를 가졌지만 공학적인 분야에서 이만큼 빠르게 변화하고 발전한 공학도 없을 것이다. 그래서 소프트웨어 공학이란 것이 정확한 기준을 섣불리 경계를 짓기도 애매한 학문이다.

그리고 소프트웨어 공학과 최근 빠르게 확산되는 애자일(agile)에도 많은 시간을 쏟아서 경험을 축척해야 한다. 소프트웨어 공학은 정량적인 측정이 가능하지만 애자일은 다르다. 팀원간의 관계와 팀이 축척한 또는 개개인의 경험이 큰 작용을 하고 애자일이란 툴적인 측면에서도 적극적이어야 한다. 필자도 소프트웨어 공학과 애자일을 공부하면서 처음 블로그에 쓴 글로부터 불과 4년 밖에 채 되지 않는다. 학문이라는 것은 알면 알수록, 배우면 배울수록 모르는 것이 점점 더 많아지는 것은 왜그럴까 ^^;

TFS 전문가는 골고루 다 알아야 한다. 이것 저것 모두 통합된 제품이므로 당연한 것이다. Team Foundation Server, Visual Studio Ultimate 외에 알아야 할 것들이 더 많다.

전문가적인 서비스를 제공하는 업체도 없다

한 마디로, 팀 파운데이션 서버(Team Foundation Server) 기술을 서비스하는 업체들은 다 망했다. 그러므로 만약 당신의 회사에서 TFS 컨설팅이나 서비스를 받고자 한다면, TFS 전문가가 올 확률은 거의 없다고 봐도 된다.

실제로 운영하다 장애가 생겨도 우리나라에서는 제대로 된 서비스를 받기 힘들다. 국내 팀 파운데이션 서버(Team Foundation Server) 전문가가 있는 업체가 한 군데도 없다. 한 곳의 전문 업체가 있었지만 TFS 사업을 접었다고 전해들었다.

필자의 과거 전 회사에서는 TFS 컨설팅을 했었고, 그런 업체가 몇 군데 더 있었지만 지금은 TFS의 수요도 없을 뿐더러 한 번 도입하면 다른 솔루션으로 갈아탈 수 없는 폐쇠성을 가지고 있어 도입의 실효성에 대해서도 논란이 있다.

image-1
이미지 링크

마이크로소프트 제품으로 발라야 한다

TFS 도입을 결정하는 순간 마이크로소프트(Microsoft)의 제품으로 완전히 발라버려야 한다.

가장 먼저 발라야 하는 것은 윈도우 서버(Windows Server) 이다. 가장 최신의 버전인 Team Foundation Server 2012는 윈도우 서버 2008 R2 부터 설치할 수 있다. 항상 최신 버전에 잘 적응을 하는 것이 이로울 것이다.

두 번째로 발라야 하는 것은 엑티브 디렉토리(Active Directory; AD)이다. 다른 LDAP(Lightweight Directory Access Protocol; 경량 디렉터리 액세스 프로토콜)의 OpenLDAP 은 전혀 지원하지 않는다. 예를 들어, 사내에서 리눅스(Linux) 서버에 OpenLDAP을 쓴다면 당장 OpenLDAP 데이터를 Active Directory로 마이그레이션을 해야할 지도 모른다. 좀 더 똑똑한 방법으로는 Active Directory와 OpenLDAP을 동기화 하는 방법도 있지만, 결국 유지 관리의 피로도는 급격하게 늘어날 것이다. (물론, AD 없이 쓸 수도 있지만, 없이 쓸 생각을 하면 앞이 캄캄하다)

세 번째로 발라야 하는 것은 Microsoft SQL Server 데이터베이스 제품이다. 왜 MySQL을 지원하지 않는지 기술적으로 이해하기가 힘들다. 물론 이 제품에서 분석 서비스(Analysis Services)와 리포팅 서비스(Reporting Services)를 제공하는데, 이거 안쓰고 싶어도 써야 한다. 이거 안쓰면 TFS가 매우 초라해 지기 때문이다.

네 번째로 발라야 하는 것은 IIS(Internet Information Services; 인터넷 정보 서비스)이다. 너무도 당연한 이야기지만…

다섯 번째로, 옵션으로 쉐어포인트(SharePoint)를 바를 수 있다. 이것을 바르려고 하는 순간 전용 서버를 고려해야 할 것이다.

예측할 수 없는 잦은 장애, MS 제품에 잔지식이 많아야 한다

모든 것이 통합된 TFS 구동하는 환경은 또 매우 복잡하고 오류의 원인을 찾는 것이 매우 힘들 수도 있다. 그러므로 MS 제품 이것 저것을 알아야 하고 계속…….. 배워야 하는 악순환이 계속된다.

필자는 6년이 넘게 거의 논스톱으로 직접 운영하는 TFS 서버가 있다. 서버도 직접 구매했었고, 소음 때문에 코로케이션으로 쓰다가 서버는 팔고, 결국 규모를 데스크탑 두 대로 줄여서 집에서 돌린다. 자동 업데이트가 설정이 되었는지 원인은 모르겠으나 서버 재부팅 후에 TFS 서비스들이 먹통이 되는 경우가 많았다.

실무에서도 많이 겪는 문제 중 하나가 윈도우 업데이트(Windows Update) 서비스이다. 필자가 몸담았던 회사 중에 운영 조직에서 윈도우 서버 전문가들이 직접 관리했지만, 가끔은 윈도우 업데이트 후에 정상적인 서버 작동이 되지 않아 윈도우 업데이트를 롤백(rollback) 하는 경우가 다반사였다.

대충이라도 모르면 어디서 튀어나온 트러블인지도 예측할 수 없다. 권한 구성만 해도 엑티브 디렉토리, IIS, MSSQL, 쉐어포인트 다 따로 해줘야 하는데 이 제품들이 서로 자기 오류가 아니라는 듯한 메시지만 보여준다.

제대로 된 기능이 하나도 없다

얼마 전에 필자가 쓴 글이다. 글의 요지는 ‘모든 것을 만족할 수 있지만, 어느 것도 만족할 수 없다.’ 이다.

[ALM] 13. 불완전한 통합, 팀 파운데이션 서버(Team Foundation Server)

크로스 플랫폼(Cross Platform)을 지원하는 Atlassian 의 제품 몇 개와 비교해 보자.

  • TFS 이슈관리 vs JIRA (atlassian)  
    음.. 이건 알만한 사람이면 다 안다. TFS를 JIRA와 비교하는 것이 실례이다. redmine과 같은 오픈된 제품에 비해서도 TFS는 장점보다는 단점이 더 많다. TFS 이슈관리가 MS OFFICE 플러그인을 제공하긴 하지만, MS OFFICE에서 플러그인으로 다루는 것이 더 불편하다. 플러그인을 너무 대충 만들어놓고 OFFICE 통합이라고 하는 것은 좀 무리수다.

  • TFS 코드뷰어 vs STASH (atlassian)
    이것도 TFS는 STASH에 비교하는 것이 실례이다. STASH의 특성이 조금 다르긴 하지만, github 의 인트라넷 버전이라고 봐도 무방할 것이다. 그만큼 TFS 코드뷰어에 비해 잘 만들어 졌다.

  • TFS 팀 빌드 vs BAMBOO (atlassian)
    TFS 팀 빌드는 할 수 있는 것이 거의 없다. BAMBOOJenkins에 비교 자체가 실례이므로 넘어간다. 이미 BAMBOO는 Amazon EC2 같은 클라우드와 통합이 되었다. 이에 비해 TFS는 이제 베타 버전으로 인터넷을 통해 서비스를 테스트 중이다. 특히 BAMBOO는 다양한 소스 제어를 지원하는 것도 장점이다.

Atlassian의 통합성은 TFS의 복잡한 구성보다 더 간단하다. Atlassian 제품은 각 제품간에 긴밀하게 통합이 되어있으며, 다른 3rd party 제품까지 다양하게 통합할 수 있다. Atlassian 은 제품마다 REST 형태의 API 를 제공하는데, 제품간에 응용 프로그램 수준의 인증이나 Oauth 인증 등 다양하게 각 제품을 연결할 수 있다.

필자는 Atlassian 제품은 모든 제품을 라이센스를 직접 구매하여 집에서 호스팅을 하면서 공부하는데, 서로 간에 긴밀하게 잘 통합되어 있으며, 상당히 많은 Addon이 제공되어 매우 쉽게 기능을 확장할 수 있다.

#1의 결론

이번 #1에서 이야기한 ‘팀 파운데이션 서버(Team Foundation Server) 를 쓰지 말아야 하는 진짜 이유 #1’은 주로 TFS의 외적인 부분에서 언급하였다. 앞으로 TFS 제품을 Atlassian과 다른 오픈된 ALM 솔루션과 기능적인 면으로도 비교해 볼 예정이다.

이슈 관리/ 소스제어/ 빌드/ 테스팅/ 릴리즈, 그 외에 다양한 면에서 비교해 보면서 진짜 이유를 조금씩 파헤쳐 볼 것이다.

image-2
이미지 링크, 이런 것도 통합인가?

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 지나가는사람 2019.08.28 15:25 Address Modify/Delete Reply

    이미 오래전 글이긴 하지만 본 김에 첨언하자면...

    TFS는 Windows VS를 사용하는 환경이라면 엄청나게 강력한 툴이며, 기능또한 강력하다 생각합니다.

    물론 언급한 것 처럼 마소의 제품군을 사용해야 그 위력이 재대로 발휘되는 만큼 어느정도의 마소 제품군의 강제성은 있습니다만 이 이유로 사용하지 말아야 한다는 것은 논리적 비약이라 볼 수 있겠네요.

    차나리 제목이 TFS 구축 시 유념해야 할 사항 혹은 TFS 기능을 100%로 끌어올릴 수 있는 방법 이정도가 제목이였으면 더 좋지 않았을까 싶네요..

  2. 지나가는사람 2019.08.28 15:31 Address Modify/Delete Reply

    덧붙여 MS제품에 잔지식이 많아야한다 즉, 어렵다는 것이 TFS가 좋지 않다라고 말하는 것도 논리적 비약이라 보여지네요.

    SQL Lite가 Oracle 혹은 Sql Server에 비해 가볍고 사용하기 편하다는 이유로 Oralce DB는 SQL Lite보다 좋지 않다. 라고 말하는 것이 억지라고 생각되거든요.

    물론 좋은 제품이라하면 기능의 접근성이 좋고 직관적으로 이해하기 편해야 하는 것은 맞지만 역으로 기능이 많고(복잡하고) 익히기에 어렵다는 이유로 그것이 좋지 않다라고 말하는 것은 아니라는 것이죠.

$tf 폴더

팀 파운데이션 서버(Team Foundation Server) 2012 버전부터 로컬 워크스페이스(local workspace) 에 매핑된 폴더 중 $tf 파일이 생긴 것을 알 수 있다. 이 폴더는 숨김(hidden) 속성이 적용되어 있어 안보인다면 숨김 폴더도 보이도록 윈도우 익스플로어(Windows Explorer) 에서 설정을 변경하면 된다.

이 폴더는 여러분이 주로 작업하는 작업 영역(Workspace)일 경우 생각하는 것 보다 훨씬 많은 용량을 차지하고 있다. 이 폴더는 특성상 늘어나면 늘어나지 절대 줄어들 일이 없다. 대부분의 시간이 지날수록 코드의 라인은 늘어나고 변경이 일어나는 부분도 많아진다.

이 폴더가 내심 꺼림직해서 지워도 또 다시 생긴다. 이 폴더는 Team Foundation Server 2012 버전을 쓰고 + 로컬 작업 영역(Local Workspace)로 매핑된 폴더에 생긴다. 이게 의외로 골치 이프기도 하고 문제가 되기도 한다.

$tf 폴더, 왜 생기나…

이 폴더은 네트워크가 오프라인(offline) 상태로 중앙 서버에 연결할 수 없는 경우 스텐바이(standby)하고 있다. 물론 오직 오프라인(offline)을 위한 폴더는 아니다.

팀 파운데이션 서버(Team Foundation Server) 2012 + 로컬 작업 영역(local workspace) 조합이면 백퍼 생기는 폴더다. 일종의 소스 코드의 스냅샷(snapshot) 과 메타데이터(Metadata) 정보를 가지고 있다. [1]

image-1
[이미지 참조 링크]

이 폴더가 생기는 주된 이유 중 하나가 네트워크가 오프라인(offline)이 될 때 서버로 연결할 수 없으므로 이 로컬 작업 영역을 참조하게 된다. 팀 파운데이션 서버(Team Foundation Server)는 변경집합(change set) 단위로 데이터베이스(MSSQL)에 저장하는데, $tf 안에 변경집합(change set) 정보를 데이터베이스 처럼 활용하여 저장하게 된다.

image-2
[이미지] $tf 폴더 내부 구조, 각 파일은 zip 압축이 되어있다.

정체성을 잃은 TFS 소스 제어

이런 오프라인 기능을 지원하는 건 반갑다만 팀 파운데이션 서버(Team Foundation Server) 는 처음부터 오프라인을 고려하고 만들어지지 않았다. 전략적으로 비주얼 스튜디오(Visual Studio) 를 사용하는 기업이나 단체를 대상하기 때문에 오프라인(Offline) 가능성이 매우 낮은 환경을 대상으로 하는 솔루션이다.

필자의 경우 예전부터 작업하던 모든 $tf 폴더의 용량이 1GB를 훨씬 넘었고, 이런 빈번하게 작업하는 폴더를 여럿 가지고 있다. (최근 용량이 많이 차지해서 과감하게 $tf 를 지워버렸다.)

SVN 또한 .svn 이라는 숨김 폴더가 있는데 이를 ‘Administrative Directory’ 라고 부른다. 이 관리 디렉토리는 SVN을 사용하면서 변경되는 파일의 정보를 저장한다. SVN도 마찬가지로 .svn 폴더의 용량이 증가하게 되는데, 이런 경우 작업 중인 디렉토리를 복사할 때 .svn 디렉토리도 함께 복사가 된다. 최근 SVN은 이 폴더가 최상위 루트에 하나만 생기도록 변경되어 작업 디렉토리마다 .svn 폴다를 신경써야 할 필요가 사라졌다.

git 으로 잘 알려진 대표적인 분산 제어 방식의 소스제어(Distributed Version Control) 또한 로컬의 스테이징 저장소(Staging Area)를 이용한다.

사실 팀 파운데이션 서버(Team Foundation Server) 는 애시당초 오프라인에 대한 대안이 없었다. 네트워크가 오프라인이 되고 파일을 체크아웃을 하면 로컬 작업 파일이 읽기 전용(Read Only) 파일 속성이 해제되고 서버와 연결이 끊겨도 수정이 가능하다. 다시 네트워크가 사용이 가능할 때 ’온라인 상태’로 변경할 수 있는데, 이 때 체크이웃된 사실을 서버에 통보하게 되고 서버는 이 때 체크이웃 상태로 변경한다. 오프라인 상태일 때의 변경 집합은 온라인 상태에서 병합하게 되는 시나리오를 가지게 되는데, 로컬에 저장했던 변경 기록은 병합할 때 충돌(conflict)를 줄일 수가 있다.

하지만 좋은 오프라인 정책이 있더라도 경험적으로 알 수 있은 것은 오프라인(서밋이 일어나지 않는)이 오래될 수록 충돌(conflict)은 피할 수 없다. 비교적 간단하게 병합(merge)할 수 있는 어느 정도의 단계를 넘어서면 병합 도구는 변경이 일어난 부분과 일어나지 않은 부분을 제대로 분간하지 못하는 상황까지 온다.

$tf 폴더는 생기는데, 이를 제한할 수 있는 방법이 없어…

어떤 이유던 간에 $tf의 용량은 점점 커진다. 그러나 이 폴더의 용량을 제한할 수 있는 설정은 존재하지 않는다. 그리고 git 을 함께 사용하는 개발자는 소스 코드가 보관된 폴더에서 .gitignore 에 $tf 를 제외할 수 있도록 설정을 하기 바란다.

다만, $tf 폴더가 가지는 몇 가지 장점이 있다. 그러나 오프라인(offline) 일 때 굳이 파일의 버전을 비교할 예외적인 상황도 없었고, 오프라인 일 때 파일 이름을 변경한 경우도 있으나 다시 온라인일 때 무리 없이 파일의 상태가 반영이 되었다. 그러므로 필자는 수 년을 사용하면서 이 장점을 얻기 위한 예외적인 상황을 거의 몇 번밖에 만나보지 못했다.

MSDN 에서 $tf 폴더에 대해 자세하게 기술이 되어 있지 않으나 참고가 필요한 분은 이 링크[2]를 통해 확인하기 바란다.


  1. References - Team Foundation Server - Trying to understand Server versus Local Workspaces
    http://blogs.msdn.com/b/willy-peter_schaub/archive/2011/11/30/team-foundation-server-trying-to-understand-server-versus-local-workspaces.aspx  ↩

  2. References - Team Explorer Everywhere의 새로운 기능
    http://msdn.microsoft.com/ko-kr/library/jj155781.aspx%23local  ↩


Posted by 땡초 POWERUMC

댓글을 달아 주세요

들어가기 앞서

팀 파운데이션 서버(Team Foundation Server) 는 구성과 운영이 매우 까다로운 ALM(Application Lifecycle Management) 솔루션 중의 하나다. 그간 오류에 대해 정리하는 의미로 팀 파운데이션 서버(Team Foundation Server) 를 운영하면서 겪을 수 있는 여러 가지 경우의 오류를 리스트업 해본다.

앞서, 마이크로소프트(Microsoft)의 제품이 가지는 여러 통합 제품은 공통적인 단점을 가지는데 그것은 통합되는 요소들이 모두 자사 제품임에도 불구하고 환경적인 요소에 매우 민감하다는 점이다.

image–1

통합된 만큼 오류 유형도 광범위

팀 파운데이션 서버(Team Foundation Server)는 윈도우 서버, SQL 서버, 웹 응용 프로그램 서버(IIS, Inernet Information Services), 그리고 쉐어포인트(SharePoint) 등과 통합이 되는데 심각한 경우 매우 작은 요소들로 인해 일부 서비스의 작동 자체가 멈춰버린다.

예를 들어 엑티브 디렉토리(Active Directory)나 데이터베이스 서버가 변경되거나 백업(Backup), 복원(Restore) 계획, 그리고 서버간의 인증이나 그룹, 맴버, 역할 그리고 시스템의 환경적인 변수 등 큰 범위부터 작은 범위까지 다양하게 나타난다.

때문에 매우 구체적으로 자원을 운용할 수 있는 장점과 함께 운영 규모가 커질수록 통합된 각 제품에 대해 매우 깊은 솔루션 지식이 요구된다. 대부분 상세한 오류 메시지를 제공하지 않고 추상적인 메시지를 제공하기 때문에 통합된 제품의 상호 관계를 확실히 이해하고 ‘감(Feeling)’으로 잘 때려 맞춰야 하는 경우도 생기게 된다.

단, 필자가 나열한 것 보다 더 많은 오류 발생과 해결이 있었으나 사소하거나 기억할 필요가 없다고 생각한 것들은 블로그에 올리지 못한 것도 다수 있다.

팀 파운데이션 서버(Team Foundation Server) 오류 해결

팀 파운데이션 서버(Team Foundation Server) 운영 정보


Posted by 땡초 POWERUMC

댓글을 달아 주세요

불완전한 통합, 모든 것을 만족할 수 있지만, 어느 것도 만족시킬 수 없다.

팀 파운데이션 서버(Team Foundation Server)는 모든 것을 통합한 마이크로소프트(Microsoft)의 ALM(Application Lifecycle Management) 솔루션이다.

통합… 모든 것을 만족할 수 있지만, 어느 것도 만족시킬 수 없다.이 통합이라는 것은 이 시대엔 단점으로 작용될 수도 있다는 생각이 든다. 지난 2005년부터 2010년까지 ‘통합’ 이라는 것이 장점이라고 생각했었다. 모든 것을 올인원(All in One) 해 놓았다는 것만으로 주목을 끌 수 있었지만, 2013년 최근에는 이제 더 이상 ‘통합’이 장점이 될 수 없다는 결론을 내렸다.


[이미지] 통합... 현실적인 통합과 이상적인 통합


(현실적인 통합?)
출처 : 이미지 링크

(이상적인 통합?)
출처 : 이미지 링크


필자는 비주얼 스튜디오 팀 시스템(Visual Studio Team System) 2005 버전부터 팀 파운데이션 서버(Team Foundation Server)를 사용해왔다. 필드에서는 이와 관련된 다수의 기업 컨설팅과 강의를 진행하였고, 그 외 레거시 개발 환경과 소스 컨트롤(Source Control)을 커스터마이징한 소프트웨어를 납품하는 등 대략 8년을 넘게 비주얼 스튜디오(Visual Studio)와 팀 파운데이션 서버(Team Foundation Server)와 동거동락하며 지냈다. 물론, 8년을 넘게 사용하면서 좋은 점도 많지만 그렇지 않은 점도 확실히 있다.

그 동안 한 가지 ALM 솔루션만 사용할 때는 미처 몰랐던 것들이 많았지만, 여러 가지 ALM 제품을 접하면서 ALM 솔루션 간에 장/단점을 필자의 기준에 좀 더 객관적으로 판단할 수 있는 계기가 되었다.

과거 ALM은 오픈 소스 진영을 중심으로 조금씩 발전해 왔다. SVN 소스 제어 컨트롤을 중심으로 각각 독립적인 유닛(Unit)으로 배포가 되고 플러그인 등을 활용하여 조금씩 연동을 할 수 있었다. 그런 와중에 마이크로소프트(Microsoft)는 개발툴과 ALM을 통합한 ‘팀 시스템(Team System)’ 발표하였고, 그 당시 여러 오픈 소스가 가진 것들을 한 곳에 통합하여 사용할 수 있었다. 이 때까지는 ‘통합’ 이라는 것 자체가 장점이던 시대이다.

하지만, 최근 ALM은 조직의 성숙도에 맞는 전문적인 ALM 툴을 사용하는 추세이다.

아쉽게도 팀 파운데이션 서버(Team Foundation Server)는 각각의 모든 기능들이 전문성을 갖추기에는 매우 부족한 것도 사실이다. ‘이슈 관리, 빌드, 소스 제어’, 아마도 딱 떠오르는 대표적인 벤더 및 오픈 소스들이 있을 것이다. 이슈 관리(Issue Managements), 빌드(Builds), 소스 제어(Source Control) 등, 타 벤더의 전문적인 툴과 비교하면 각각의 기능은 타 벤더에 비해 열악하다.

대표적인 ALM 벤더들과 차이가 나는 것은 마이크로소프트(Microsoft)의 팀 파운데이션 서버(Team Foundation Server)는 범용성을 추구하고, 전문적인 것들은 SDK(Software Development Kit)를 사용하여 커스터마이징을 하거나, 3rd party 벤더의 몫으로 남긴다. 대인배적인 모습이긴 하지만, 현재까지도 여전히 팀 파운데이션 서버(Team Foundation Server)를 중심으로 한 생태계가 형성되지 않았다는 것 또한 단점으로 작용한다.

필자는 최근 아틀라시안(Atlassian)의 ALM 제품에 매력을 느끼고 있다. 각각의 기능들이 매우 뛰어나고, 필요하다면 언제든지 필요한 기능의 소프트웨어와 통합이 가능하다. 설치부터 통합까지 매우 간단하다. 그리고 어떤 운영체제에서도 설치와 운영이 가능한 ‘크로스 플랫폼(Cross-Platform)’ 이라는 점은 팀이나 조직에서 선택의 폭이 넓고, 또 하나, 데이터베이스, 웹 서버 등 선택의 폭도 넓다. (반면, 팀 파운데이션 서버(Team Foundation Server)는 설치는 쉽지만 구성(Configuration)이 복잡하고 운영(Operation)에 더 많은 리소스가 필요하다)

그리하여 앞으로 필자는 여러 ALM 솔루션을 벤치 마킹하면서 ALM 솔루션들 간에 장단점 등을 비교/분석하여 함께 공유할 예정이다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요