Na samo wspomnienie pracy z TFS mam nieprzyjemne ciary na plecach. I jak codziennie widzę kilka/kilkanaście wpisów na Twitterze rzygających na to paskudne narzędzie gorącą nienawiścią, pokłon Bozi składam że nie muszę się z tym już użerać.
Na myśl przychodzi mi wówczas tekst z najlepszej płyty jaką kiedykolwiek wydano… bo słowa te mogłyby być taglinem dla TFSa:
When you are suffering, know that I have betrayed you
Źródło: Marilyn Manson, “Antichrist Superstar“
Święte słowa. Niestety w niektórych firmach TFS jest jedynym słusznym VCSem – i, co gorsza, decydują o tym ludzie, którzy na codzień nie pracują ani z kodem ani z VCSem. Smutne.
Czesc! W naszej firmie zastanawiamy się nad przejściem z VSS na coś nowego, ponieważ używamy .NETu i VS2010 naturalną drogą wydaje się własnie TFS. Jednak co jakiś czas napotykam się na posty krytykujące TFSa, nie wymieniające jednak konkretnych powodów dlaczego jest on zły. Przydałby się post z listą zarzutów wobec TFSa. Pozdrawiam!
a3n,
Dawno już z TFSa nie korzystałem i nawet siadałem do takiego posta, ale zrezygnowałem. Wystarczy wyguglać… http://www.google.com/search?q=why+tfs+sucks . Pewnie Gutek miałby na ten temat więcej szczegółów do dodania, może napisze posta o tym:)
To żeś Procent przytoczył argument… Dla porównania wyguglaj coś o czymkolwiek innym (GIT: http://www.google.com/search?q=why+git+sucks SVN: http://www.google.com/search?q=why+svn+sucks).
Nawet pokusiłem się o przeczytanie pierwszego artykułu napotkanego z tytułem "why tfs sucks" (http://www.nearinfinity.com/blogs/joe_ferner/why_i_dislike_tfs_-_team_found.html) i z większością rzeczy w tym artykule się nie zgadzam.
Nie mam wielkiego porównania z innymi tego typu narzędziami ale na ten moment TFS jest dla mnie niezastąpionym narzędziem pracy (mówiąc z perspektywy doświadczonego programisty i kierownika projektu).
Marcinii,
Argument żaden, dlatego też argumentów nie podawałem w samym poście. Kluczowe jednak jest to co napisałeś: "Nie mam wielkiego porównania z innymi tego typu narzędziami"… nie spotkałem osoby która MA porównanie z alternatywami a i tak chwali TFSa. Po prostu.
Nie napisałem że nie mam w ogóle doświadczenia z innymi tego typu narzędziami, zdarzyło mi się trochę pracować na SVN’ie i te narzędzie nie przemawia do mnie. Napisałem że nie mam wielkiego doświadczenia – czyli nie pracowałem więcej niż pół roku z żadnym innym niż TFS.
Jednakże rozmowa ta powinna obejmować trochę szerszą tematykę, powinniśmy raczej mówić o narzędziach pozwalających pracować w zespole / pozwalających zarządzać całym cyklem życia projektu. Ciężko jest wypowiadać się o TFSie jedynie w kontekście repozytorium kodów bo lwia część TFS’a dotyczy samego zarządzania projektem. Nie znam drugiego takiego narzędzia które miałoby to wszystko w jednym, jakieś przykłady?
I jeszcze zapomniałem dodać jednej kwestii do ogółu.
Patrząc na ludzi w zespole (a nawet w dwóch zespołach) jak pracują z TFS’em to faktycznie zdarza im się źle wyrażać o TFS’ie. Ale w wiele przypadków wnikałem głębiej i okazywało się że to programista sam coś skopał czegoś niedopilnował albo po prostu nie umie czegoś ustawić (bądź nie wie że można).
Marcin,
Akurat SVN nie jest dobrym przykładem alternatywy dla TFSa, tego narzędzia też nie trawię ( http://www.maciejaniserowicz.com/post/2010/02/08/Dlaczego-juz-nie-lubie-SVN.aspx ). Chociaż pracowało mi się z nim lepiej niż z TFSem.
Co do problemów wspomnianych programistów to narzekać można na wszystko i każde narzędzie wykorzystywane w sposób niewłaściwy będzie problematyczne.
A że "lwia część TFS’a dotyczy samego zarządzania projektem"… no tak, ale jednak całym spoiwem jest kod. Kod, który w TFSie jest po prostu niezorganizowaną kupą tekstu.
Jak zwykle wspomnę o Gicie – korzystam w połączeniu z Redmine i jest to kombo bardzo, bardzo dobre. O ile do samego Redmine mam pewne zastrzeżenia (chociaż nie korzystam z najnowszej wersji i wiem że część z nich jest już poprawionych), to Git jest po prostu ideałem. I nie trzeba pół roku żeby się o tym przekonać.
Tak czy siak wolę Git + Notepad do zarządzania projektem (jakkolwiek absurdalnie to nie zabrzmi) niż TFSa. Po co mi beznadziejne coś, co ma wszystko zintegrowane, skoro mam (i to darmowe!) alternatywy robiące każdą rzecz osobno, ale o wiele lepiej? A i te osobne narzędzia (Git i Redmine) da się ze sobą zintegrować tak, aby każdy task prowadził do odpowiednich commitów w repo.
Chciałbym się dowiedzieć dlaczego kod w TFSie nazywasz "niezorganizowaną kupą tekstu"?
Bo branch i merge są namiastką tego czym powinny być – hasła do wyszukania "tfs branching model" i "git branching model" (lub to samo dla mercurial). Albo w skrócie – najwyżej punktowana odpowiedź tutaj: http://stackoverflow.com/questions/6208930/tfs-branching-what-are-the-advantages .
A może masz ochotę opisać jak (do czego) praktycznie wykorzystujesz funkcje branch i merge.
Przyznam szczerze że rzadko korzystałem z tych funkcjonalności, do tej pory nie widziałem wielkiej potrzeby (może charakterystyka projektów ma na to wpływ?). Może mnie zainspirujesz i spróbuję zrobić to samo na TFS’ie :)
Charakterystyka projektów raczej nie ma na to wpływu. Hasło przewodnie to "branch per feature". Czyli: jeden programista pracuje nad pewną funkcjonalnością – przed rozpoczęciem pracy tworzy swoją gałąź i tam wprowadza zmiany, w których nikt mu nie przeszkadza. Drugi, trzeci, czwarty – to samo. Piąty poprawia buga – też ma swoją gałąź do tego. I tak dalej… Po zakończeniu prac gałąź jest integrowana z głównym branchem (head, master, …). W Gicie, dzięki tzw. "3-way merge", cała historia commitów jest zapamiętana w danej gałęzi i już na pierwszy rzut oka widać które commity odnoszą się do jakiego wymagania/zgłoszenia/zadania. W TFS, z tego co wiem, nie ma 3-way merge. Ale tak jak napisałem, główne hasło do wyszukania to ‘branch per feature’, polecam.
I pracujesz jako pięciu programistów na raz? :)
Tzn samo podejście jest w porządku, ale nie widzę głębokiego sensu stosowania takiego podejścia w zespole liczącym 3 programistów, testera, designera i kierownika projektu. Poprawianie błędów w oddzielnym branchu to jest ok, żeby nie wdrażać nowych funkcjonalności dla klienta przed zaplanowanym czasem.
Ale wracając do TFS’a – ten przypadek który opisałem spokojnie można zrobić na TFSie i wszystko ładnie jest widoczne. Bardziej skomplikowane przypadki branch i merge także są na TFSie realizowane (szczególnie w wersji 2010).
Jeżeli chodzi o przyglądanie się które commity odnoszą się do jakiego wymagania/zgłoszenia/zadania to na TFSie wystarczy wejść w szczegóły danego zadania i już widać wszystkie powiązane changesety z tym zadaniem.
Mam nadzieję, że to nie jest Twój jedyny słuszny argument przeciwko TFS’owi.
Nawet jako jeden programista pracuję w ten sposób, dzięki temu w każdej chwili mogę zachować zmiany w aktualnym branchu, wrócić do głównego i zająć się jakimś pilnym bugiem.
A argumentów przeciw TFSowi jest więcej:
* jest wooooolny
* jest scentralizowany
* nie można pracować offline
* blokuje pliki
* …
Tak jak pisałem, nie używałem go już od bardzo dawna i z pewnością nie zamierzam używać w przyszłości, więc nic bardzo ciekawego ci tu nie napiszę:). Przekonaj się sam próbując zaproponowaną przeze mnie alternatywę.
Przyznam szczerze, że z chęcią spróbowałbym alternatywy (żeby wyrobić sobie klarowne porównanie) z tymże brak okazji.
A jeżeli chodzi o Twoje argumenty przeciwko TFSowi to chyba faktycznie nie używałeś go już od bardzo dawna :) I to właśnie chciałem podkreślić nie wysuwaj argumentów bazując na doświadczeniach sprzed x lat, a właściwie piszesz jakbyś pracował kiedyś jeszcze nie na TFS’ie a na Source Safe :)
Najpoważniejszy i niepodważalny argument przeciwko TFSowi to to że nie jest darmowy, ale jak firma może sobie na TFSa pozwolić to nie widzę żadnych innych przeszkód czemu z niego by nie korzystać.
Moje przekonanie o aktualnej beznadziejności TFSa bierze się z obserwacji na twitterze ludzi, którzy są zmuszeni go używać, a wcześniej korzystali z gita lub hg. Ich reakcje całkowicie pokrywają się z moimi doświadczeniami, więc nie mam powodu żeby im nie wierzyć.
Nie przekonasz mnie że TFS nie jest wolny – być może tego nie zauważasz, bo nie korzystałeś z alternatywy.
Nie przekonasz mnie że kontrola wersji w TFSie jest zadowalająca – być może nie zdajesz sobie z tego sprawy bo nie znasz możliwości alternatyw.
Nie przekonasz mnie że cała otoczka "zarządzania projektem" ma jakiekolwiek znaczenie w sytuacji, gdzie praca z kodem (co jest w końcu najważniejsze!) jest skopana.
A to że za TFSa trzeba płacić nigdy nie było i nie jest moim argumentem – nie widzę w tym nic złego. Sam bym nie zapłacił za to złamanego grosza, ale jak ktoś sprzedaje a ktoś inny kupuje to nikomu nic do tego.
Na koniec mała analogia: nie wytłumaczę "jak zajebiście się jeździ ferrari" człowiekowi który całe życie jeździ maluchem – to trzeba poczuć samemu:).
Ciągnięcie tej dyskusji nie ma moim zdaniem większego sensu skoro ja najeżdżam na produkt którego nie używałem od kilku lat i bazuję na opiniach innych, a ty go bronisz bez możliwości sprawdzenia konkurencyjnych rozwiązań. Ja nie sprawdzę twoich argumentów, a ty moich – możemy tak się przerzucać i przez tydzień, ale po co?
Ale w maluchu jestem w stanie Ci przyznać rację że w Farri musi być po prostu lepiej. W przypadku TFS’a ja nie czuję żadnego powodu dla którego miałbym zmieniać repozytorium kodów. Po prostu jest to w całości zadowalające narzędzie a ostatnio nawet potrafi mnie mile zaskakiwać. Mówiąc o TFSie ja sie nie zastanawiam jak ulepszyć składowanie kodu a jak ulepszyć proces wytwarzania oprogramowania. Jaki przyjąć flow w kontaktach programista-tester-kierownik projektu.
Moim zdaniem ciągnięcie tej dyskusji też nie ma żadnego celu – jedyne co chciałem podkreślić, to to że nie akceptuję jak ktoś wypowiada się o produkcie (szczególnie gdy podejmuje ostrą krytykę) nie znając jego możliwości. Jak zwolennik TFS’a chyba sam rozumiesz że musiałem podjąć tą dyskusję :)
Marcin,
Ale nic nowego nie napisałeś. Ja WIEM że są firmy w których korzysta się z TFSa. I WIEM że ludzie są tam zadowoleni. WIEM też, że ci ludzie nie pracowali w alternatywnym środowisku – to wszystko! Nie spotkałem jeszcze ani jednej osoby, która po świadomym używaniu Gita powiedziałaby o TFSie choćby jedno małe dobre słowo. I tyle. Tak więc ja swoje zdanie podtrzymuję bazując na doświadczeniach własnych i opiniach osób, które mogą wypowiedzieć się zarówno o TFSie jak i rozwiązaniach konkurencyjnych – nie krytykuję więc nie wiedząc o co chodzi bo "tak jest trendy" tylko krytykuję coś, co jest beznadziejne na tle innych narzędzi.
Ta, zażarta dyskusja :)
W swojej aktualnej pracy przeforsowałem wprowadzenie GIT-a zamiast MS VSS. Scentralizowany system, blokowanie plików i wiele wiele innych (w tym praktycznie brak możliwości tworzenia Branchy – przynajmniej praktycznych) doprowadzały zespół do szału i wielu problemów.
GIT sprawdza się w codziennej pracy w tak kosmicznych scenariuszach, że nawet w najśmielszych snach nie mogłem ich przewidzieć :) W VSS rozpoczęcie pracy nad plikiem często gęsto stawało się mordęgo i wiązało się z wycieczką do Pana X który aktualnie nie odbiera wiadomości na skyp-ie a wypadało by, żeby odblokował zajmowany plik (w takich sytuacjach najczęściej okazywało się, że "coś tam" ma do skończenia i finalnie wszystko kończyło się kopiowaniu plików lub odpinaniu od repo). Nie wspomnę już o mergowaniu – tylko staży programiści z brodą i rozciągniętym swetrem są w stanie to ogarnąć w VSS.
Trzeba przyznać, że na początku bardzo ciężko było mi (anty konsolowo – linuxowemu człowiekowi) się przyzwyczaić do GIT-a, ale po 6-8 miesiącach nie zamienił bym tego systemu na żaden inny a już na pewno nie na scentralizowany.
Przewaga systemów zdecentralizowanych nad scentralizowanymi jest faktem i nie ma się co sprzeczać.
Argument że TFS jest do wszystkiego…. wiadomo :)
MS VSS to faktycznie było dno – w TFS teraz już nie ma czegoś takiego jak blokowanie pliku (można to właczyć ale jest to opcja domyślnie nie włączona). I wiele innych problemów (m.in. z branch i merge) też zostało sensownie rozwiązanych. Może faktycznie jakichś scenariuszy związanych z repozytorium kodu nie da się w nim zrobić, ale dla mnie TFS to jest przede wszystkim narzędzie do kontroli projektu pozwalające zarządzać pracą programistów, monitorować ich postępy, szukać historii zmian w projekcie w powiązaniu z wymaganiami (jeżeli klient mówi że coś miało być inaczej). Kod do repozytorium wrzuca się przyjemnie prawym na projekt "check in" i już. Nawet jak wystąpią konflikty to z większością radzi sobie sam (a jak nie radzi to też jest dobre narzędzie do rozwiązywania konfliktów). Daje możliwość powiązania dodatkowych "sprawdzaczy" do check ina, typu sprawdzenie kodu StyleCop’em (i nie pozwolenie wcheckowania) czy jakieś inne wymyślne reguły. Jako kierownik projektu w notyfikacjach dostaję zielone bądź czerwone powiadomienie jak ktoś wrzucił checkina i jego build się powiódł lub nie. No po prostu repozytorium spełnia swoją funkcję i mogę się skupić na ważniejszym aspekcie definiowania/poprawiania procesu wytwarzania oprogramowania (dostosowywać szablony procesu według utartych zwyczajów w firmie i kolejnych doświadczeń).
Jeżeli chodzi o GIT’a to na pewno tego nie krytykuję, chciałbym spróbować, ale nie usłyszałem jeszcze żadnego argumentu który choć trochę przekonałby mnie do tego (bądź innego) rozwiązania, nie widzę jak GIT mógłby przyspieszyć moją codzienną pracę (bo o to w tym wszystkim chodzi).
Z mojej perspektywy (programisty) ciężko mi by się teraz pracowało bez takich dodatków jak:
stash
reflog
reset (soft/hard)
chery-pick
remote’s
To jest tylko kilka przykładów, ale naprawdę bardzo, ale to bardzo przydatnych (stasha używam kilka razy dziennie). Odnośnie powiadamiania i innych fajnych dodatków – można tutaj zrobić praktycznie wszystko, chodź nie jest to za naciśnięciem jednego przycisku :) W firmie wykorzystujemy z powodzeniem powiadomienia o push-ach na główne repo.
Nie wiem jak z perspektywy kierownika projektu, ale programistą, już sam rozproszony charakter GIT-a, znacznie przyspiesza pracę- większość rzeczy nie przechodzi przez główne (produkcyjne) repozytorium, można swobodnie wymieniać się zmianami, nie tracąc przy tym kontroli na kodem.
A możesz po krótce opisać co te dodatki robią i w czym Ci usprawniają pracę?
Marcin,
Najlepiej naprawdę ściągnij sobie książkę o Gicie, zainstaluj w domu i pobaw się godzinkę.
Wszystkie komendy znajdziesz także w świetnej dokumentacji: http://www.kernel.org/pub/software/scm/git/docs/ .
Ale:
stash – usuwa zmiany od ostatniego commita i zapamiętuje je "gdzieś" – masz pierwotny kod, jednak w każdej chwili możesz owe zmiany przywrócić (coś jak shelve w TFS, tyle że lepsze)
reflog – zapis wszystkich wykonanych akcji
reset – usuwa zmiany względem ostatniego commita, z tym że jest to mechanizm dużo bardziej zaawansowany niż zwykłe SVNowe czy TFSowe "revert", co ma związek z kolejnym doskonałym rozwiązaniem w Gicie – indexem
cherry-pick – pozwala wybrać jeden konkretny commit z jakiejś gałęzi i zaaplikować go w innej gałęzi
remotes – zdalne repozytoria, które można "podpiąć" pod swoje lokalne repo, synchronizując się z nimi w bardzo swobodny sposób
Dodatkowo super przydatne bywa bisect, o którym osobno kiedyś pisałem: http://www.maciejaniserowicz.com/post/2011/04/26/git-bisect.aspx .
Trochę to uproszczone:), i polecam jednak samodzielne zapoznanie się z gitem.
TFS to nie tylko system kontroli wersji. TFS to połączenie w jedno wiele narzędzi. Największą jego zaletą jest że wszystkie informacje o projekcie są w jednym miejscu. Oprócz repozytorium kodu TFS daje rejestracje bugów, zadań, raporty, automatyczne buildy itd. Dla większych firm takie ujednolicone repozytorium dla wszystkich projektów to duża wartość.
Czy w gicie możesz w łatwy sposób powiązać zdanie ze zmianami w kodzie ? W TFS-ie robisz polisy które wymaga wybranie Work Item przy check-in i wiesz dokładnie jakie zmiany związane są z konkretnym bugiem czy zmianą.
Waldi,
Oczywicie że TFS to coś więcej niż kontrola wersji, ale nie ma to znaczenia gdy kontrola wersji skutecznie uprzykrza pracę z kodem. Cały projekt bez możliwości wydajnego kodowania traci, niezależnie od tego jakie fajne ficzery ma system zarządzania projektem.
Rolę "ujednoliconego repozytorium dla wszystkich projektów" może pełnić chyba każdy system do zarządzania projektem? W Redmine mam wszystko – projektów ile chcę, dostęp do kodu (wraz z diffami, commitami itd) i masę fajnej funkcjonalności, bez narzutu Sharepointa, dedykowanej maszyny i milionmegabitowego łącza pomiędzy serwerem a każdym deweloperem.
W Gicie nie mogę nic z niczym powiązać, bo Git to kontrola wersji. Ale mogę zintegrować Redmine z Gitem – wtedy Redmine pobiera kod z repozytorium, analizuje commity i przypisuje commity odpowiednim zadaniom.
Procent,
chodzi mi o to że porównywanie TFS z systemem kontroli wersji ponieważ TFS to system do "zarządzania projektami".
Jeżeli jakaś firma posiada licencję na TFS-a to naturalne jest używanie tego narzędzia "out-of-the-box", jest świetnie zintegrowany z Visual Studio i od wersji 2010 instalacja jest naprawdę prosta.
Używanie TFS-a tylko do kontrolę wersji dla mnie mija się z celem.
Co do samej kontroli wersji to dla kilku-osobowego zespołu projektowego w firmie wystarcza, chociaż na pewno nie jest tak dobry jak Git.
Przejście z TFS-a na Git-a oznacza uczenie się nowego narzędzie przez wszystkich deweloperów oraz rezygnację z integracji z TFS-em.
Musiałbym mieć mocne argumenty żeby to zrobić (a już przekonanie o tym PM-a nie wchodzi w grę).
Ale przekonałeś mnie żeby wreszcie znaleźć czas i pobawić się tym Git-em w domu, do tej pory używałem VSS, SVN i TFS.
Waldi,
Tak jak już pisałem wyżej kilkukrotnie: kodowanie i zarządzanie kodem jest najważniejszym elementem prac nad projektem. Używanie narzędzia przeszkadzającego w pisaniu kodu tylko dlatego że ma doklejone zarządzanie projektem wydaje mi się nieporozumieniem.
Ale doskonale rozumiem, że da się z tym pracować, w końcu masa ludzi tak robi. Tyle że są lepsze sposoby na osiągnięcie tego samego efektu.
Procent
Moim zdaniem trochę za dużo powiedziałeś w zdaniu "używanie narzedzia przeszkadzającego w pisaniu kodu". Żeby rzeczywiście te narzędzie przeszkadzało mi w czymś, nie pozwalałoby mi być produktywnym to po prostu bym go nie używał szukałbym alternatyw. W mojej codziennej pracy TFS pomaga mi wielu zadaniach i w tej chwili nie wyobrażam sobie pracy bez niego. To o jakim przeszkadzaniu tu mowa skoro dzięki temu narzędziu jestem bardziej produktywny?
Żeby przejść na inne narzędzie typu GIT potrzebne mi są konkretne argumenty mówiące o tym jakie moje problemy te narzędzie rozwiąże, w jakich chwilach w mojej codziennej pracy zrobię coś szybciej. Do tej pory takich argumentów po prostu nie usłyszałem, a pisanie żebym sobie poczytał jakąś książkę nie jest na miejscu bo mógłbym poczytać również książkę o TFSie i skorzystać jeszcze z większej ilości jego dobrodziejstw.
Podkreślę jeszcze raz, moim zdaniem za bardzo jedziesz po tym produkcie skoro go na codzień nie używasz.
@Procent
"używanie narzedzia przeszkadzającego w pisaniu kodu" – tutaj to się chyba trochę zagalopowałeś :)
Tak jak w "Seksmisji" :
– [Albercik] A może Curie-Skłodowska też?! (… była kobietą)
– [Maks] To akurat nie najlepszy przykład…