Team Foundation Build 또는 TeamCity?

Team Foundation Build 또는 TeamCity?

---

우리는 주로 .NET LOB 개발을 수행하는 MS 상점입니다. CRM 앱에도 MS Dynamics를 사용합니다. 모든 개발자는 현재 VS / SQL Server 2008을 사용하고 있습니다. 우리는 또한 VSS를 사용하고 있지만 모두가 VSS를 싫어하기 때문에 빨리 빠져 나가고 있습니다.

팀 전체에서 TDD 구현을위한 이니셔티브를 시작합니다 (~ 12 명). TeamCity를 설정했고 2008 sln 빌더를 사용하고 소스 제어 분석을 수행하는 동료가 설정 한 SVN을 사용하여 첫 번째 자동화 된 빌드를 성공적으로 실행했습니다. 관리를 시연 할 때, 그들이 내 스네이크 오일을 구입하기 시작했고 TFS를 살펴 보겠다는 제안을 버렸다고 생각합니다.

이로 인해 TDD 아키텍처를 위해 제가 계획했던 일이 크게 바뀌 었습니다. 좋은 방법으로, 나는 항상 TFS가 너무 비싸고 우리 팀에게 가치가 없다고 생각했기 때문에 (그리고 내가 일한 / 알고있는 다른 상점에서 똑같은 것을 보았습니다). 나는 MS가 TDD / CI 분야에서 몇 년 뒤쳐져 있고 제 3 자 제품이 아마도 훨씬 더 낫고 더 성숙했다고 느낀다 ... 나는 여전히 많은 연구를해야하지만 나는 여기에 와서 볼 것이라고 생각했다. 누군가 실제로 두 시스템을 모두 사용한 경우.

나는 TFS가 단지 빌드 서버보다 훨씬 더 많은 것을 포함한다는 것을 알고있다. 그러나 나는 적어도 의도적으로 이것을 너무 광범위한 질문으로 만들고 싶지 않았다. TeamCity 대신 TFS / TFB를 사용하는 실질적인 장단점은 무엇입니까? 예를 들어 우리가 잃거나 얻을 수있는 이점은 무엇입니까? 여기에있는 사람이 실제로 두 시스템 (TFS for TDD / CI 및 TeamCity / SVN)을 사용했으며 실제 관점에서 말할 수 있습니까?

이 주제에 대해 몇 가지 검색을 수행했으며 여기에서 찾은 한 게시물은 TFB의 단점이 MSBuild 만 지원된다는 점을 언급했습니다. TeamCity와 함께 FinalBuilder를 사용할 계획이었습니다. TFS도 지원하는 것 같습니다.

조언 감사합니다

편집 : 누구나 TFS를 빌드 / CI 서버로 사용하고 성공 / 실패 사례를 말할 수 있습니까?

---

우리는 소규모 개발 회사이며 Team Foundation Server가 우리에게 너무 많은 오버 헤드를 전달하기로 결정했습니다. 우리는 명령 줄에서 실행할 사용자 지정 MSBuild 스크립트를 작성했지만 TeamCity를 발견 한 후 전체 빌드 프로세스를 여기로 옮겼습니다.

TeamCity는 사용 및 구성이 쉬우 며 JetBrains는 탁월한 지원과 문서를 제공합니다. 또한 Microsoft보다 릴리스 및 업데이트주기가 훨씬 빠릅니다.

SVN 소스 제어에 대한 지원은 훌륭하며 단위 테스트를 위해 MSTest와 NUnit을 모두 지원한다는 사실이 마음에 듭니다.

또한 TeamCity Professional 에디션이 무료라는 사실이 마음에 들었 기 때문에 그것이 우리에게 효과가 있는지 평가할 수있었습니다. 엔터프라이즈 에디션으로 업그레이드해야하는 프로젝트 구성의 수 (20)에 도달하지 못했습니다.

---

이 질문 에는 TeamCity에 대한 많은 좋은 답변이 있습니다. TFS와 비교되지는 않지만 TeamCity에 대한 정보를 제공 할 수 있습니다.

둘 다 사용 해봤고 둘 다 성공했지만 TeamCity가 훨씬 쉬웠습니다. TeamCity는 설치 및 구성이 매우 간편했습니다. TFS는 그렇지 않았습니다. TeamCity는 견고하고 유지 관리가 쉬우 며 단순하게 작동합니다. JetBrains의 개발자는 커뮤니티에 대한 응답을 훌륭하게 수행했습니다. 그들은 실제 가치를 추가하는 6-8 개월마다 릴리스를받습니다. TFS는 2 년 이상주기입니다.

TeamCity는 빌드 방법과 사용하는 소스 제어에 대해 더 많은 선택권을 제공합니다. 올인원은 아니지만 때로는 좋은 일입니다. 좋은 확장 포인트 세트도 있습니다. 우리는 또한 그것이 가진 에이전트 모델에 정말 만족했습니다.

저는 TeamCity에서 3 가지 고통스러운 업그레이드를 거쳤습니다. 한 번의 TFS 업그레이드로 빌드 및 소스 제어가 3 일 동안 중단되었습니다. 저는 우리 프로젝트에서 TeamCity의 관리자이며 한 달에 두 시간 정도 걸립니다. TFS는 일주일에 이틀이 걸렸습니다.

TeamCity + SVN + VisualSVN은 제가 지금까지 작업 한 것 중 가장 원활한 환경이었습니다. TFS는 일반적으로 매일 매끄럽게 진행되었지만 누군가가 계속 실행하는 경우에만 가능했습니다.

도움이되는 희망

---

TFS의 이점은 Microsoft에서 지원하는 하나의 통합 환경입니다. 저는 개인적으로 소스 제어용 TFS를 좋아하지 않으며 여러 문제가 있습니다. 투박하지만 VS 통합의 이점이 있습니다 (VisualSVN에서도 사용할 수 있지만 강력하지는 않습니다).

개인적으로 SVN / TeamCity를 사용하는 것이 훨씬 낫다고 생각합니다. 작업하기가 더 쉽고 예상대로 더 많이 작동합니다. 대부분의 오픈 소스 소프트웨어와 마찬가지로 둘 다 지속적으로 발전하고 있으며 항상 Microsoft 이전의 가장 뛰어난 최신 기능을 갖게 될 것입니다. 2 사이의 통합은 정말 좋으며 시스템에서 치명적인 결함을 발견하지 못했습니다. 나는 그것이 훨씬 더 나은 작업 흐름이라고 믿기 때문에 현재 회사 (우리는 TFS를 사용) 에서이 경로를 계속 사용하도록 노력합니다. 추가 혜택으로 TFS 경로를 이용하는 것보다 훨씬 저렴합니다.

또한 FinalBuilder를 TFS와 함께 사용했습니다. 제 질문에 NANT / MSBuild로 할 수없는 FinalBuilder로 실제로 무엇을 구매하고 있습니까? 내 가게의 대답은 불행히도 IMO가 거의 없습니다.

---

먼저이 게시물을 참조하십시오.

SVN 대 Team Foundation Server

어떤 환경이 TDD 등을 더 잘 조성하는지에 대한 질문에 대해, 제 2 센트는 빌드 관리 시스템이 빌드 파일 자체에있는 것보다 훨씬 덜 중요하다는 것입니다. Ant 또는 MSBuild 파일에는 테스트를 수행하는 대상이 있어야합니다. MSBuild 또는 Ant를 사용하면 MS의 테스트 스위트를 사용할 필요가 없습니다. nUnit 또는 원하는 다른 것을 계속 사용할 수 있습니다. 즉, TFS가 MSBuild 파일을 호출하는지, CruiseControl이 호출되는지, TeamCity가 호출되는지는 중요하지 않습니다. 스마트 한 기능은 모두 빌드 파일과 여기에 통합하는 도구에 있습니다.

저의 개인적인 선택은 TFS의 작업 방식에 얽매이지 않는 것입니다. 왜냐하면 외부에있는 풍부한 오픈 소스 테스트 도구를 사용하면 훨씬 적은 비용으로 훨씬 더 많은 자유를 누릴 수 있기 때문입니다. TFS도 주요 업그레이드를받을 예정입니다. TFS를 사용하려면 최소한 2010 년이 출시 될 때까지 기다려야합니다. 지금 가능한 한 좋은 MSBuild 파일을 만드는 데 집중하십시오.

즉, TFS가 가장 멋진 빌드 시스템 중 하나를 가지고 있음을 인정해야합니다 (2005 년은 끔찍했고 2008 년은 좋았습니다). .NET 코드 내에서 알림과 릴리스 프로세스를 쉽게 사용자 지정할 수 있다는 점은 매우 멋졌습니다 .CruiseControl.NET에서보다 빌드 및 릴리스 정책을 훨씬 더 중앙에서 제어 할 수있었습니다.

그래서 TFS와 SVN / CCNet을 사용했습니다. TeamCity에 대해 많이 말할 수 없습니다. 그러나 IMO 빌드 관리 시스템은 무엇을 빌드하고 어떻게 빌드하는지에 대해 상당히 무관해야합니다. 우리에게 TFS가 가져온 릴리스 관리 프로세스의 추가 제어는 완전히 통합 된 TFS 솔루션의 관리 노력이 크게 증가하는 것을 정당화하는 데 충분하지 않았습니다. TFS의 추가 라이선스 당 비용을 정당화하는 것만으로는 충분하지 않았으며 이는 상당 할 수 있습니다.

---

이전 TFS 빌드는 XAML 기반이었고 매우 번거롭고 작업하기에 좋지 않았습니다. 즉, 새로운 TFS 2015 빌드 시스템은 도약과 한계가 더 나아졌으며 많은 웹 후크 및 타사 통합을 기반으로하는 스크립트입니다. Team City와 매우 유사합니다. 또한 TFS는 이제 Git을 지원하므로 더 이상 TFVC (Team Foundation Version Control) 사용에 국한되지 않습니다. 또한 TFS를 사용하면 자체 온 프레미스 설치를 사용하거나 visualstudio.com을 통해 호스팅 된 솔루션을 활용할 수 있습니다. TFS는 완전히 통합 된 하나의 환경 (작업 항목, 계획, 빌드, 테스트, 배포)이기 때문에 훌륭하지만 Team City는 빌드 솔루션 일뿐입니다. 이 질문이 원래 2010 년에 물렸을 때 저는 Team City를 손에 넣을 것을 권장했습니다. 하지만 이제 2는 매우 경쟁적입니다.

---

Comparing TeamCity to Visual Studio Team Services (the latest cloud-based offering from Microsoft):

• Both work great for implementing a continuous integration process

• TeamCity is more mature and everything just works.

• Visual Studio Team Services by contrast is constantly evolving to catch up with TeamCity and some things just don't work well (e.g. try triggering builds based on paths that have changes from Git - the documentation is weak and the feature itself just doesn't work (as of August 2016))

• Visual Studio Team Services makes it easy to have only cloud-based agents running your build (the downside however is that each has to do a clean pull of your repository for each build which may add a minute or more to the build). Both can also support local build agents which do not need to wipe the working directory for each fresh build.

But in either case I would highly recommend you also look at CakeBuild which moves most of the configuration information about how to do a build out of the CI system and into C# code that is in your Git repository along with all your other source code. With CakeBuild you can run the same build locally as you will run in the CI system and if you need to go back a month to build a specific version you have the source code and the build script to do it.

With CakeBuild in place you are now free to easily switch between TeamCity and Visual Studio Team Services.

The only downside to CakeBuild is that all your build steps are bundled into a single task in the CI system which makes reporting slightly less nice and may involve some extra work to get the test results out into a format that the CI reporting system can use.

---

MS is years behind in the TDD/CI area

Being one who has TDD'd for 4 years now you are correct. MS is still not even promoting it nor do they offer tools that work well with the TDD flow.

Don't get stuck dealing with Visual Studio for any kind of automation, source control, or agile workflow period (stop using TFS please!!). That stuff even though they say is "new" is monolithic and always comes with weird issues and bloat. It is always painful.

I've used Team City and it's simply amazing, things work, it's designed for usability, and it's simply designed well and compatible with most all test tools, etc. Fine use Visual Studio for code, nothing else. Look for external and open source tools to help build a better CI. The "you can do everything right in VS" sell is not selling, and it's not working. People nowdays are used to and always combining different tools from the outside to get things done. Relying on all MS toolsets is just not the way to go IMO for .NET. MS likes to sell "hey you can just do everything right here". But you end up with nothing but pain when you go that route and drink their koolade (TFS, MS Fakes, etc.).

If you plan on doing TDD, you definitely don't want to be using all MS tools. You'll either be pushed down "their way" of doing things which is often proprietary and/or bloated when you try to TDD with their tools or be totally restrictive. For TDD you need to be able to have some flexibility and choices when you decide to layer in different test frameworks, assertion libraries, etc.

Add Octopus on top of Team City, and it's stellar...you will simply fall in love with it as developer or for anyone doing DevOps.

Stop trying to rely on Microsofts continued failure at agile tool offerings

Start looking outside the box and try new things is what I keep repeating to the .NET world, me being a .NET developer in the past and who has tried new things outside the MS world.

참고URL : https://stackoverflow.com/questions/2239249/team-foundation-build-or-teamcity