Można powiedzieć, że lipiec kończy się dla mnie pewnego rodzaju sukcesem. Udało mi się bowiem przeforsować, zaplanować oraz wykonać migrację naszego firmowego repozytorium kodu ze znienawidzonego Team Foundation Server na Mercuriala. Zmiana ta jest o tyle wiekopomna przez pełną zmianę logikę działania repozytorium oraz potrzebę zmiany nawyków u wszystkich zainteresowanych współpracowników. Jednak, jak na początek pracy po migracji, muszę przyznać, że mimo obaw co do tego jak się sprawdzi rozproszony system zarządzania kodem, odczucia odnośnie zmiany są pozytywne (i oby tak zostało). W dalszej części wpisu przedstawię powody, dla których migracja na inny SCM była konieczna. W drugiej części wpisu, która będzie niedługo, kilka słów o tym jak skonfigurować centralne repozytorium kodu na Windows Server 2008 R2 oraz o tym jak korzystać z klienta (np. TortoiseHg) oraz generalnie o tym, czego się wystrzegać i o czym pamiętać w codziennej pracy.

Logo Mercurial

Dlaczego porzucać TFS?

Po takim tytule można by napisać całą książkę – tak szeroki jest to temat :) W dużym skrócie Microsoft nie zna się zbytnio na pisaniu oprogramowania (a przynajmniej ta drużyna od TFS-a) i dość często korzystanie z tego produktu bywa frustrujące, irytujące, choć przyznać trzeba, że można przy nim rozwijać swoje pokłady cierpliwości (choć czasem można zwariować, w szczególności, gdy spieszymy się i jedyne na co cały czas czekamy to Visual Studio i TFS, aż łaskawie odblokuje plik). Poniżej kilka punktów, które dla mnie były ponadto szczególnie ważne:

  • Baaaaardzo wolny. Spory czas oczekiwania na prawie każdą akcję (pierwsza edycja z moim osobistym rekordem: 6min 35sek; dodanie pliku do solucji, pobranie najnowszej wersji, wykonanie shelve’a, odrzucenie własnych zmian, itd.). Przy okazji ciekawostka-cytat ze strony Fowl Coder na temat zalet nowego TFS: “It's fast as hell, at least compared to Source Safe. It's designed to run over a WAN and it communicates with the server via web services. Getting latest is very efficient because TFS only gives you what you need and doesn't need to check every file in your solution.”. Aż się boję wobec tego sprawdzać kiedykolwiek wydajności SourceSafe.
  • System check-in check-out, co po polsku nazywa się chyba systemem ewidencjonowania plików. Tzn. plik jest blokowany tylko dla 1 użytkownika i dopóki nie zostanie przez tego użytkownika odblokowany, nikt inny nie ma możliwości wprowadzenia do niego jakichkolwiek zmian. Dla mnie osobiście jest to minus, bo bywa to strasznie ograniczające, ale przez wiele osób uważane jest to za największy plus Team Foundation Servera (choć taką funkcjonalność ma także kilka innych systemów kontroli wersji, jak np. Plastic SCM). Warto przy okazji wspomnieć o tym, że potrzeba każdorazowego sprawdzenia, czy plik jest dostępny do edycji oraz zmiana stanu na zablokowany w repozytorium to coś co zasadniczo spowalnia cały produkt (w każdym bądź razie Plastic SCM działał podobnie wolno, mimo iż nie był związany z Microsoftem)
  • Blokowanie plików na dysku. To jedna z bardziej uciążliwych cech, w szczególności dla osób, które do edycji używają też innych narzędzi niż Visual Studio. Prawda jest taka, że Visual Studio nie nadaje się do wykonywania niektórych czynności. Jakakolwiek bardziej zaawansowana obróbka tekstu jest raczej niemożliwa, edycja plików RESX jest niesamowicie uciążliwa i bezsensowna, itd. Istnieje oprogramowanie, które skutecznie pomaga w tych kwestiach, np. bardzo dobry Simple Resx Editor, czy Sublime Text 2 (fenomenalny edytor tekstu dla programistów), ale TFS skutecznie nam utrudnia życie, gdyż kwestia blokowania plików jest determinowana przez parametr Read Only we właściwościach pliku należącego do solucji, a ten praktycznie zawsze jest zablokowany ;] Zmieniając samemu tę wartość powodujemy, że TFS gubi się i nie wie co z takim plikiem robić (jest wtedy ignorowany).
  • Standardowo brak jest nakładki do Explorera (jak w przypadku wszystkich żółwików), choć oczywiście można takową ściągnąć i zainstalować. Waży tylko 300MB.
  • Marne narzędzia do pokazywania zmian i do wykonywania scalania (czasem to też się zdarza nawet w TFS)
  • Drogi. Sam TFS kosztuje co prawda $499, ale firmy informatycznie na ogół nie ponoszą tego kosztu, bo licencja na niego jest w subskrypcji MSDN, ale w dalszym ciągu jest to droga alternatywa przez to, że: należy mieć jeszcze komputer z Windows Server 2003 (minimum) i go osobno utrzymywać. Są też dostępne w Internecie usługi do zewnętrznego utrzymywania repozytoriów, ale i w tym przypadku jest to bardzo droga alternatywa (np. $109.99 per użytkownik per miesiąc). Porównując to do np. BitBucketa, gdzie nielimitowana ilość użytkowników kosztuje $80 per miesiąc, można się zastanowić czy jest sens wydawać taką ilość pieniędzy za tego typu oprogramowanie ;]
  • Trudność wykonania backupu i jego przywracania. Pada maszyna z naszym TFSem – co robimy? Trzeba skądś załatwić zrzut instalacji i go przywrócić (w przypadku gdybyśmy go nie mieli – to mamy niezły problem), a następnie przywracamy backup bazy danych TFSa i już jesteśmy w domu. Ciekawe ile to trwa w praktyce? :> W przypadku systemów rozproszonych, awaria centralnego repozytorium w najmniejszym stopniu nie utrudnia pracy dla programistów. Na czas awarii używa się innego repozytorium jako głównego, albo zmiany wysyła się do siebie mailem. A sam backup – to tylko folder z plikami repozytorium, jego przywrócenie i backup są prawie natychmiastowe :)
  • I na koniec standardowo: mnóstwo problemów i jakichś wątpliwych rozwiązań, które przestają działać w momencie, gdy najmniej tego oczekujemy. Zawsze mnie na przykład zastanawiało czemu należy konfigurować jeszcze jakiś workspace po pobraniu najnowszej wersji solucji na dysk, albo czemu nie można mieć solucji w dwóch miejscach (problem z tym zauważyłem przy próbie użycia narzędzia do migracji repozytorium). Pewnie ktoś byłby w stanie mi to wyjaśnić, ale w dalszym ciągu niektóre rozwiązania wydają mi się cokolwiek wątpliwe.

Czemu w ogóle TFS był wykorzystywany?

Jest też trochę plusów, o których warto pamiętać (a, które nie były aż tak ważne dla naszego zespołu):

  • TFS nadaje się lepiej do dużych zespołów, które poza narzędziem wersjonowania kodu źródłowego projektu chcą także zintegrowane narzędzie do zarządzania zadaniami, raportowania, zarządzania projektem i system automatycznych build-ów. W naszym zespole nie było potrzeby używania czegokolwiek poza SCM, więc cała idea stosowania TFS była generalnie dość wątpliwa.
  • Bo był. Cóż, trochę to smutne, ale skoro był w cenie pakietu, który i tak już był zakupiony i opłacony, to czemu by go nie użyć. Przecież wszyscy to robią - to musi być dobre narzędzie. Nic bardziej mylnego ;]
  • Dobra integracja z Visual Studio, co ja bym osobiście sprowadził do: działa z Visual Studio. Ponadto nie trzeba specjalnie konfigurować klienta, żeby rozpocząć bezawaryjną pracę z produktem. W przypadku innych rozwiązań i osobnych integracji z VS, może to wyglądać nieco inaczej.
  • System ewidencjonowania plików – jako sposób na uniknięcie konfliktów. W mało doświadczonych zespołach lepiej jest zabronić możliwości doprowadzenia do sytuacji konfliktowych niż pozwolić na własnoręczne ich rozwiązywanie.

W następnej części wpisu kilka informacji o tym jak skonfigurować centralne repozytorium, o migracji repozytorium z TFS, konfiguracji klienta i innych…

Referencje

Phase 2 - Cennik hostingu online dla TFS 2010

TeamDevCentral - Cennik hostingu online dla TFS

BitBucket - Cennik