Team Foundation Build czy TeamCity?

To pytanie zawiera wiele dobrych odpowiedzi na temat TeamCity. Nie porównuje się do TFS, ale może rzucić trochę światła na TeamCity dla Ciebie.

Używałem obu i odniosłem z nimi sukces, ale TeamCity było o wiele łatwiejsze. TeamCity było proste do skonfigurowania i skonfigurowania. TFS nie było. TeamCity jest solidny, łatwy w utrzymaniu i po prostu działa. Programiści z JetBrains wykonali świetną robotę, odpowiadając na społeczność. Dostają zwolnienie co 6 do 8 miesięcy to dodaje prawdziwej wartości. TFS jest w cyklu 2 lata lub więcej.

TeamCity daje większy wybór w jaki sposób budujesz i jakiej kontroli źródłowej używasz. To nie wszystko w jednym, ale to czasami dobrze. Ma też dobry zestaw punktów rozszerzeń. Byliśmy również bardzo zadowoleni z modelu agenta, który ma.

Przeszedłem 3 absolutnie bolesne ulepszenia w TeamCity. Jedyna aktualizacja TFS, którą zrobiliśmy, przerwała naszą kompilację i kontrolę źródła na 3 dni. Jestem adminem TeamCity na naszej projekt i zajmuje kilka godzin w miesiącu. TFS trwało kilka dni w tygodniu.

TeamCity + SVN + VisualSVN to najbardziej płynne środowisko, w jakim pracowałem. TFS był ogólnie gładki na co dzień, ale tylko wtedy, gdy ktoś tam był, utrzymując go w ruchu.

Hope that helps

Zalety TFS to jedno zintegrowane środowisko obsługiwane przez Microsoft. Osobiście nie lubię TFS do kontroli źródeł i miałem z tym wiele problemów. Jest niezgrabny, jednak miał tę zaletę, że miał integrację VS (która jest również dostępna w VisualSVN, ale nie jest tak solidna).

Osobiście uważam, że lepiej byłoby używać SVN/TeamCity. Jest po prostu łatwiej pracować i zachowuje się bardziej, jak można się spodziewać. Jak w przypadku większości programów open source, zarówno stale się rozwijają i zawsze będą mieć najnowszą i najlepszą funkcję przed Microsoftem. Integracja między 2 jest naprawdę dobra i nie znalazłem żadnych fatalnych wad w systemie. W mojej obecnej firmie (korzystamy z TFS) ciągle naciskam na tę drogę, ponieważ uważam, że jest to znacznie lepszy przepływ pracy. Dodatkową korzyścią jest to, że jest znacznie tańszy niż przejście trasy TFS.

Używałem również Finalbuildera z TFS - moje pytanie jest co tak naprawdę kupujesz z Finalbuilderem, który nie możesz zrobić z NANT / MSBuild? Odpowiedź w moim sklepie jest niestety bardzo mało IMO.

Po pierwsze, zobacz ten post:

SVN vs. Team Foundation Server

Jeśli chodzi o twoje pytanie, które środowisko lepiej wspiera TDD i takie tam, moje dwa centy są takie, że system zarządzania kompilacją ma znacznie mniej znaczenia niż to, co jest w samym pliku kompilacji. Twój plik Ant lub MSBuild powinien mieć cele, które wykonują twoje testy. Dzięki MSBuild lub Ant nie musisz używać pakietu testowego MS. Nadal możesz użyć nUnit lub cokolwiek innego chcesz. Oznacza to, że nie ma znaczenia, czy TFS jest wywołanie pliku MSBuild lub CruiseControl lub TeamCity. Wszystkie Smarty znajdują się w pliku kompilacji i narzędziach, które z nim integrujesz.

Mój osobisty wybór nie polega na tym, aby dać się zamknąć w sposobie działania TFS, ponieważ masz o wiele więcej swobody za dużo mniej kosztów z narzędziami do testowania bogactwa open-source, które są tam. TFS ma otrzymać również dużą aktualizację. Jeśli masz zamiar iść z TFS, moja rada jest, aby przynajmniej poczekać do 2010 roku zostanie wydany. Skoncentruj się na tworzeniu plików MSBuild tak dobrze, jak to tylko możliwe.

To powiedziawszy, muszę przyznać, że TFS ma jeden z najładniejszych systemów budowania (2005 był okropny, 2008 był miły). Możliwość łatwego dostosowywania powiadomień i procesu wydań w kodzie. NET była całkiem fajna - miałeś o wiele większą centralną kontrolę nad zasadami kompilacji i wydawania niż my w przypadku CruiseControl.NET.

Więc użyłem TFS i SVN / CCNet. Nie mogę rozmawiać z TeamCity. Ale IMO system zarządzania budową powinien być dość niezależny od tego, co jest budowane i jak jest budowane. Dla nas dodatkowa kontrola w procesie zarządzania wydaniami, którą przyniósł nam TFS, nie była dla nas wystarczającym bonusem, aby uzasadnić znacznie większy wysiłek administracyjny związany z w pełni zintegrowanym rozwiązaniem TFS. Nie wystarczyło to również, aby uzasadnić dodatkowy koszt licencji TFS, który może być znaczny.

Stara wersja TFS była oparta na XAML i była bardzo uciążliwa i niezbyt przyjemna w pracy. To powiedziawszy, nowy system budowania TFS 2015 jest skokowo lepszy i jest oparty na skryptach z wieloma haczykami internetowymi i integracjami stron trzecich; bardzo podobny do Team City. Ponadto TFS obsługuje teraz Git, więc nie jesteś już ograniczony do używania Team Foundation Version Control (TFVC). Ponadto dzięki TFS możesz użyć własnej instalacji lokalnej lub skorzystać z hostowanego rozwiązania poprzez visualstudio.com. TFS jest świetnie, ponieważ jest to jedno w pełni zintegrowane środowisko (elementy robocze, planowanie, Kompilacje, testy, wdrożenia), podczas gdy Team City to tylko rozwiązanie do budowania. Kiedy to pytanie zostało pierwotnie zadane w 2010 roku, poleciłbym Team City hands down. Teraz jednak, 2 są bardzo konkurencyjne. Powiedziałbym, że może sprowadzałoby się to do tego, że jeśli chcesz rozwiązania all-in-one, to idź z TFS, ale jeśli szukasz wyłącznie systemu budowania, To Team City.

[[0]}porównanie TeamCity do Visual Studio Team Services (najnowsza oferta Microsoft oparta na chmurze):

• Oba doskonale nadają się do wdrożenia procesu ciągłej integracji

• TeamCity jest bardziej dojrzałe i wszystko po prostu działa.

• Visual Studio Team Services z kolei stale się rozwija, aby dogonić TeamCity i niektóre rzeczy po prostu nie działają dobrze (np. spróbuj wyzwalać Kompilacje oparte na ścieżkach, które mają zmiany od Git-the dokumentacja jest słaba, a sama funkcja po prostu nie działa (od sierpnia 2016))

• Usługi Visual Studio Team Services ułatwiają uruchamianie kompilacji tylko agentom w chmurze (minusem jest jednak to, że każdy z nich musi wykonać czyste pobieranie repozytorium dla każdej kompilacji, co może dodać minutę lub więcej do kompilacji). Oba mogą również obsługiwać lokalnych agentów kompilacji, którzy nie muszą czyścić katalogu roboczego dla każdej nowej kompilacji.

Ale w obu przypadkach chciałbym Gorąco polecam również zajrzeć do CakeBuild, który przenosi większość informacji konfiguracyjnych o Jak zrobić kompilację z systemu CI i do kodu C#, który jest w repozytorium Git wraz z całym innym kodem źródłowym. Z CakeBuild możesz uruchomić ten sam build lokalnie, co w systemie CI i jeśli potrzebujesz cofnąć się o miesiąc, aby zbudować konkretną wersję, masz do tego kod źródłowy i skrypt build.

Z CakeBuild na miejscu jesteś teraz wolny łatwo przełączaj się między usługami TeamCity i Visual Studio Team.

Jedyną wadą CakeBuild jest to, że wszystkie kroki kompilacji są połączone w jedno zadanie w systemie CI, co sprawia, że raportowanie jest nieco mniej przyjemne i może wymagać dodatkowej pracy, aby uzyskać wyniki testów w formacie, który system raportowania CI może używać.

MS Jest lata w tyle w obszarze TDD / CI

Nie utkwiaj w pracy z Visual Studio w dowolnym rodzaju automatyzacji, kontroli źródeł lub zwinnego przepływu pracy (przestań używać TFS proszę!!). Te rzeczy, mimo że mówią, że są "nowe", są monolityczne i zawsze mają dziwne problemy i wzdęcia. To zawsze jest bolesne.

Używałem Team City i jest po prostu niesamowity, wszystko działa, jest zaprojektowany pod kątem użyteczności i jest po prostu dobrze zaprojektowany i kompatybilny z większością wszystkich narzędzi testowych itp. Dobrze użyj Visual Studio do kodu, nic więcej. Poszukaj zewnętrznych i otwartych narzędzi, które pomogą Ci zbudować lepszy CI. "Możesz zrobić wszystko dobrze w VS" sprzedaj nie sprzedaje i nie działa. Ludzie w dzisiejszych czasach są przyzwyczajeni i zawsze łączą różne narzędzia z zewnątrz, aby zrobić rzeczy. Opierając się na wszystkich MS Zestawy narzędzi nie są po prostu sposobem IMO dla. NET. MS lubi sprzedawać "hej, możesz po prostu zrobić wszystko tutaj". Ale kończy się to tylko bólem, gdy idziesz tą drogą i pijesz ich koolade (TFS, ms podróbki itp.).

Jeśli planujesz robić TDD, zdecydowanie nie chcesz używać wszystkich narzędzi MS tools. Albo zostaniesz zepchnięty w dół" ich sposób " robienia rzeczy, które są często zastrzeżone i / lub nadęte, gdy próbujesz TDD z ich narzędziami, albo będziesz całkowicie restrykcyjny. Dla TDD musisz być możliwość pewnej elastyczności i wyboru, gdy zdecydujesz się na warstwowanie w różnych frameworkach testowych, bibliotekach twierdzeń itp.

Dodaj ośmiornicę na szczycie Team City, a będzie super...po prostu zakochasz się w nim jako programista lub dla każdego, kto robi DevOps.

Przestań polegać na ciągłym niepowodzeniu Microsoftów w agile tool offerings

Zacznij szukać poza pudełkiem i próbować nowych rzeczy jest to, co ciągle powtarzam światu. net, ja będąc deweloperem. NET w przeszłości i kto próbował nowych rzeczy poza MS world.