Jak ocenić przejście na Team Foundation Server

Mój zespół programistów obecnie korzysta z następującego oprogramowania w naszym przepływie pracy:

• JIRA
• Bambus (ciągła integracja Atlassian)
• Greenhopper (Atlassian zwinne zarządzanie projektami)
• Zbieg
• Git, hostowany na BitBucket
• Visual Studio 2012

Jak widać, jesteśmy dość mocno zainwestowani w ekosystem Atlassian. Zastanawiamy się nad przejściem na TFS, abyśmy mogli poznać zalety zaawansowanych integracji Visual Studio, takich jak recenzje kodu i, co ważniejsze, Microsoft Test Manager.

Moje poprzednie doświadczenia z TFS były w 2005 lub 2008 roku (nie pamiętam) i mam złe wspomnienia z tego, choć nie tak złe, jak mój czas z ClearCase.

Jakie kryteria powinniśmy wziąć pod uwagę, aby właściwie ocenić nasze przejście do TFS?

Mała ankieta Martina Fowlera mówi dużo o stanie TFS w poprzednich latach. „niebezpieczne” ma rację. (Myślę, że odnosi się to do sposobu, w jaki nie rozpoznaje zmian dokonanych poza VS, więc możesz utworzyć projekt WCF, a następnie użyć zewnętrznego narzędzia svcutil, aby utworzyć klienta, a następnie sprawdzić wszystkie zmiany w ... ale TFS będzie na szczęście zignoruj ​​zmiany w kliencie, ponieważ nie zostały wprowadzone w VS).

Musisz policzyć koszt: wymagana wersja VS, aby uzyskać korzyści - na przykład recenzje kodu wymagają wersji Premium, która jest znacznie droższa, jeśli otrzymasz VS przez MSDN. Również dostęp do systemu dla użytkowników spoza VS jest w porządku, ale jeśli chcą pełnego dostępu zamiast do przyciętego widoku internetowego, będziesz musiał wydać dla nich licencje CAL. Całkowity koszt TFS może być dość wysoki. Nawet najnowszy raport Forrester(na zlecenie Microsoft, więc trzeba trochę przeczytać między wierszami) mówi, że TFS wymaga znacznego wsparcia administracyjnego - 2 konsultantów i 6 administratorów (którzy spędzili 25% swojego czasu) musiało wspierać TFS w swoim studium przypadku 122 użytkowników (działa z 4,5 administratorami na tych 122 użytkowników ... to dużo w porównaniu do mnie, która konfiguruje i utrzymuje pełne rozwiązanie SVN, jednocześnie wykonując swoją codzienną pracę). TFS może wymagać wiele wysiłku, aby kontynuować pracę zgodnie z oczekiwaniami.

Z mojego doświadczenia z TFS2012 (zapomnij o poprzednich wersjach, bo to bzdury), jest to bardzo skomplikowane administrowanie systemem, szczególnie jeśli wykraczasz poza wcześniej zdefiniowaną konfigurację. Na przykład, jeśli używasz MSBuild do budowania wszystkiego, wszystko w porządku. Ale jeśli masz, powiedzmy, mnóstwo starych propozycji .vdproj, które nie są już obsługiwane przez MSBuild, musisz edytować ogromny skrypt kompilacji xaml, aby umożliwić tworzenie tych projektów. Po kilku dniach pracy nad tym, co mogłem zrobić, to przebudować rozwiązanie, przekazując je devenv, a nawet wtedy uzyskanie wyników kompilacji i podsumowanie kompilacji było niemożliwe. Podobne wyniki uzyskały inne zespoły, które wykorzystały NUnit do swoich testów - jeśli użyjesz wbudowanego MSTest, to zadziała. W przeciwnym razie jesteś prawie wypchany.

Jako użytkownik uważam, że integracja jest bardziej uciążliwa. Wolę TortoiseSVN i wykonuję przez to prawie całą moją pracę SCM (ponieważ jest to niesamowite narzędzie). Dzięki TFS otrzymujesz nowy ekran wewnątrz VS dla każdej operacji. Masz więc w swoim środowisku nową kartę dla eksploratora zespołu, kolejną dla kompilacji i kolejną dla każdego podsumowania kompilacji, które chcesz zobaczyć (a jeśli chcesz zobaczyć szczegóły kompilacji, na przykład błąd, masz klikać za dużo linków). Przekonałem się, że liczba dokumentów, które miałem otwarte podczas korzystania z TFS, była większa niż pliki źródłowe!

To samo dotyczy meldowań, dokonywanie zmian wymagało kliknięcia kilku kart w okienku Oczekujące zmiany w VS, aby przypisać element pracy i komentarz do swoich meldunków. To drobiazg, ale denerwowało mnie to, ponieważ przyzwyczaiłem się do bardziej usprawnionych narzędzi.

Rozszerzenie systemu kompilacji było kolejnym obszarem, którego mi brakowało. Dodanie nowych funkcji do kompilacji jest trudne ze względu na konfigurację Xaml, a umieszczenie wyników tych funkcji na ekranach kompilacji jest bardzo trudne lub niemożliwe. Jeśli więc lubisz dodawać takie elementy, jak złożoność kodu lub analiza statyczna, a nawet automatyczne testowanie za pomocą np. Selenu lub wdrożeń ... zapomnij o tym. Chyba że używasz narzędzi Microsoft do tych aspektów (np. Fxcop).

Aktualizowanie przepływu pracy było kolejnym drobiazgiem - chociaż narzędzia były niezwykle pomocne, nadal było niezręcznie uzyskać prawidłowy przepływ pracy i nadal nie można skonfigurować tablicy scrum z informacjami, które naprawdę chcesz zobaczyć - znowu otrzymujesz wartości domyślne lub nic .

Scalanie było również bolesne, myślę, że istnieje bardzo dobry powód, dla którego MS przyjęło git dla TFS (uwaga: działa to tylko z nowymi projektami TFS, nie można przekonwertować z TFS na backendy git).

Podsumowując, nie jest tak źle, ponieważ działa, ale odkryłem, że wiele innych narzędzi jest znacznie lepszych. Wadą tych narzędzi jest to, że nie są one w pełni zintegrowane, ale IMHO jest to siła, ponieważ możesz wybrać i wybrać najlepsze bity, które chcesz. Dzięki TFS dostajesz prawie to, co ktoś inny chce, abyś miał. Jeśli zdecydujesz, że system błędów w TFS jest słaby (i myślę, że tak będzie), będziesz miał trudności z przejściem na inny.

TFS należy rozważyć wraz z innymi dużymi, grubymi narzędziami w pełnym cyklu życia. Większość programistów nienawidzi takich rzeczy, ponieważ nie lubią ograniczeń, które nakładają na nie te narzędzia.

Chciałbym jednak spróbować, pobrać 30-dniowe wersje próbne i zainstalować. Podczas oceny pamiętaj, aby zmienić trochę tu i tam, nie używaj go tylko do sprawdzania kodu źródłowego, meldowania się z wymaganym elementem roboczym i otrzymywania raportów na podstawie tego elementu roboczego. Spróbuj przypisać zameldowanie do wielu elementów roboczych i spróbuj połączyć elementy robocze razem jako powiązane. Spróbuj włączyć coś innego do systemu kompilacji, zobacz, jak uzyskać codzienny raport postępu z usług raportowania, połącz dokument z wymogiem przepływu pracy i prześledzić go przez triage błędów do kodowania w celu kompilacji do przeróbki, a następnie wydania. Rozgałęziaj i łącz dużo. Jeśli nie możesz łatwo zrobić tych wszystkich rzeczy, równie dobrze możesz trzymać się git. Nie ma sensu używać TFS, jeśli nie korzystasz z większości jego funkcji ALM.

Przeniosłem się z firmy z dużym stosem Atlassian (i Mercurial) do firmy z dużym stosem TFS. Znajduję dwa podrażnienia.

Pierwszy to kontrola źródła .

Kiedy przyzwyczaisz się do DVCS, powrót do CVCS jest bolesny. TFS jest szczególnie bolesny, ponieważ aby cała ta integracja działała, nalega na ciągłe połączenie z serwerem.

Jednak na szczęście Microsoft ostatnio zezwolił na integrację kontroli wersji Git z resztą stosu TFS. Więc nie musisz rezygnować z Gita i radzę ci tego nie robić, biorąc pod uwagę, że wszyscy już to wiedzą.

Nie jestem jednak pewien, jak dobrze narzędzie do sprawdzania kodu działa przeciwko Gitowi, ponieważ wydaje się, że w dużej mierze opiera się na zestawach półek (trochę jak skrytki, ale nie tak potężne). Ale opieranie się na zestawach półek przy przeglądaniu kodu jest samo w sobie bolesne, ponieważ zniechęca do regularnych zatwierdzeń.

Druga irytacja jest powodem, dla którego większość ludzi nie rozważy odejścia od TFS: Visual Studio Integration .

Muszę jeszcze zrozumieć uzasadnienie poznawcze stojące za tym, ale z mojego doświadczenia (i biorąc pod uwagę, że to jest uogólnienie) ludzie przyzwyczajeni do TFS uwielbiają tę integrację. Nie lubią wychodzić poza swoje IDE.

Ja z drugiej strony nie ogrzałem się po roku. Uważam, że jest zaśmiecony i trudny w nawigacji, w porównaniu do posiadania mojego serwera kompilacji na jednej karcie przeglądarki, moich biletów na innej karcie przeglądarki i tak dalej. (Edycja: Jak zauważa Andrei, istnieje interfejs sieciowy, ale jest również niewytłumaczalny, gdy przyzwyczaiłeś się do nowszych wersji Jiry i Jenkinsa. Ale nadal działa przynajmniej w przeglądarkach innych niż IE. Więc to jest coś.)

Nigdy nie patrzę na kompilacje, chyba że próbuję to zrobić, a potem trudno mi się dowiedzieć, czy ktoś inny już to robi. Nie widzę zmian innych osób, chyba że poproszę o sprawdzenie.

Ale twój przebieg może się różnić. Jak mówię, niektórym wydaje się, że jest to niezbędne. Po prostu nie mogę nie zauważyć, że generalnie ludzie nigdy nie zrobili tego inaczej.

Nie zapominaj też, że są to 2 negatywy, z których jeden może być osobisty, w dość dużej infrastrukturze. Większość mojego doświadczenia jest dobra, a TFS nie jest tak zły, jak niektórzy uwierzą. I większość rzeczy, których brakuje, można prawdopodobnie włączyć (jest to bardzo konfigurowalne); biorąc pod uwagę, że przenosisz cały zespół, a nie jedną osobę, możesz znaleźć mniejszy opór.

Mam bardzo pozytywne doświadczenia z korzystaniem z TFS 2012. Konfigurowanie serwera TFS jest dość łatwe, automatyzacja kompilacji CI jest bardzo prosta i łatwa (a kompilacja odprawy Gated jest po prostu niesamowita. Nie udało nam się osiągnąć tej samej funkcjonalności z Team City). Interakcja w zespole jest również bardzo przejrzysta i prosta. Możesz łatwo powiązać swoje zameldowania z elementami roboczymi TFS, zarządzać zaległościami, śledzić defekty, przeglądać kody i tak dalej. Jest nawet wbudowany komunikator =)

Pamiętaj jednak, że jeśli przyzwyczaiłeś się do przepływu pracy JIRA, skonfigurowanie przepływu pracy TFS może być trudnym zadaniem. Sugeruję przyjęcie jednego ze wstępnie zdefiniowanych przepływów pracy TFS. Będziesz także musiał zachować Confluence jako bazę wiedzy lub przełączyć się na SharePoint, ponieważ w TFS nie ma wbudowanej wiki.

TFS jest znacznie tańszy, jeśli masz subskrypcję MSDN (uważam, że większość firm deweloperskich pracujących ze stosem technologii MS ma ją), w tym przypadku masz TFS za darmo.

Myślę, że nie ma powodu, aby nadal używać narzędzi stron towarzyszących, jeśli wszyscy programiści pracują z Visual Studio. TFS zapewnia zintegrowany, solidny, ale łatwy w użyciu system ALM. Z przyjemnością odpowiem na twoje pytania, jeśli masz jakieś.

Ludzie powinni wiedzieć, że TFS to nie tylko VCS, to ALM .

Wydaje się, że wiele osób chce po prostu VCS, ale pójdź po TFS, to zły sposób.
W przypadku CVCS nadal wolę SVN.
W przypadku solo lub open source wybierz GIT.

Ale TFS2012 nie jest zły, łatwo zrozumieć na scalanie / rozwidlenie, a następnie SVN.
A usługa tworzenia zespołu jest bezpłatna dla 5 użytkowników / nieograniczone, prywatne repo.

Klient jest również darmowy, eksplorator TFS oparty na VS2010 i jest bezpłatny.
W przypadku Eclipse ma wtyczkę Eclipse - TFS wszędzie.

Nie widzę w tym żadnego problemu z kosztami.
TFS express (bezpłatny) może współpracować z SQL Server Express (bezpłatny).