2010-07-30 21 views
8

Jakie problemy możemy napotkać, jeśli przejdziemy z TFS do Fogbugz Kiln?TFS vs FogBugz Kiln

obecnie używamy TFS do kontroli źródła, patrzymy na opcję przeniesienia do Kiln.

jesteśmy całkowicie narzędzi programistycznych firmy Microsoft w oparciu firmę od używamy Visual Studio .NET, SQL Server, Windows Servers TFS, etc ..

powodem ruchu wydaje się to:

  1. lepszy kod narzędzia do oceny w piecu
  2. lepsze zarządzanie połączeniem w oddziale.

Czy ktoś już to zrobił? Czy ktoś wie, kiedy używamy visual studio z Kiln?

+0

Przed podjęciem decyzji sprawdź program Visual Studio 2010. Wiele, wiele ulepszeń w tych obszarach. –

Odpowiedz

4

Nie mogę odpowiedzieć na twoje pytanie całkowicie, ponieważ nie używam (i nigdy nie używałem) TFS. Jednak mój pracodawca używa StarTeam, który jest dość typowy, jeśli chodzi o kontrolę kodu źródłowego.

Dla mnie przejście z tradycyjnej metody SCC na check/check in, do modelu rozproszonego była pierwszą przeszkodą psychiczną. Aby pokonać tę przeszkodę, przekonałem się, że samouczek pod adresem http://hginit.com/ był pomocny.

Jeśli chodzi o używanie pieca do użycia z VS, używam zarówno klienta pieca (zasadniczo TortoiseHg), jak i plugin for VS 2010. Mogę zatwierdzać, ciągnąć, pchać itd. Zarówno z Eksploratora Windows, jak iz Visual Studio. Nie miałem żadnych problemów, poza nauką mercurial i działaniem rozproszonej kontroli wersji.

Jeśli chodzi o inne kwestie, jedyne, co mogę wymyślić, to aktualizowanie dowolnego serwera kompilacji lub ciągłych serwerów integracyjnych w celu pobrania z odpowiednich repozytoriów.

0

Codereview istnieje w TFS (wystarczy pobrać darmowe rozszerzenie), fuzja jest bardzo dobra w TFS, raporty są lepsze w TFS, metodologiach, integracji, a nawet cenie. W moim skromnym punkcie widzenia. Ale oba są świetnymi produktami, jeśli pracujesz lub potrzebujesz rozproszonego sc lub mieszanych zespołów (linux, itp.), TFS ma rozwiązanie, ale nie jest tak tanie

+2

Od TFS 2008 było możliwe złapanie się w pułapkę bezpodstawnego połączenia. Teraz to nie było nic dobrego. A nawet bezpodstawne scalenia wciąż nie utrzymują historii połączonych oddziałów (w porównaniu z Mercurial lub Git). Czy poprawiło się w TFS 2010? – Helgi

+0

Nie, nie. I nie mam zbytniej pewności, że tak się stanie. Wydaje się, że zespół TFS uważa bezpodstawne scalanie za cechę, a nie za błąd, z powodów, które kompletnie mnie oszałamiają. – jammycakes

0

Gałęzie są lepsze w Mercurial, ale to ma swoją cenę: ty " będzie mieć znacznie więcej oddziałów, a deweloperowi łatwiej będzie popełnić błąd i zrobić coś w niewłaściwym oddziale. Elastyczność może powodować zamieszanie.

Ale najważniejszą rzeczą jest twój plan przejściowy. Jeśli masz długi rekord zatwierdzenia w TFS, prawdopodobnie będziesz chciał go zachować. Niestety, wydawało się, że nie ma bezpośredniego narzędzia do konwersji, które pomogłoby w konwersji TFS na Hg, kiedy tego potrzebowałem. Próbowałem używać tfs2svn z hg convert, ale tfs2svn utknął ze złożonymi nazwami i zostałem zmuszony napisać zamiast tego głupie narzędzie do bezpośredniej konwersji.

0

Przerzuciliśmy ze Skarby Sourcegeara (w Bugzilli) do Kiln (w/FogBugz) ostatniej jesieni. Wszyscy nasi programiści uwielbiają ścisłą integrację commitów, aby kodować recenzje do przypadków (błędów/biletów) do specyfikacji/wymagań.

Potrzeba było kilku prób i błędów, aby opanować organizację centralnych repozytoriów. Piec (i Mercurial przez proxy) jest tak elastyczny, że można łatwo zbudować strukturę organizacyjną, która jest zbyt prosta lub zbyt skomplikowana. Znacznie ogranicza to łatwość, z jaką możesz rozgałęziać się i łączyć.Naszym celem było skonstruowanie systemu, który pozwalał tylko na przeglądanie kodu w repozytorium przemieszczania, które następnie mogło zostać wdrożone w celu wydania do kontroli jakości. Potrzeba było około 6 tygodni (głównie do prób i błędów), aby sfinalizować naszą organizację repozytorium, aby usprawnić ten proces.

Będąc w Vault (porównywalnym z Subversion z filozoficznego punktu widzenia), można łatwo zatwierdzić zmianę, która może kosztować cofanie w czasie, w Kiln jest to banalne, aby wprowadzić zmiany i wyrzucić je. Chociaż nie mogę mówić za TFS, kompilowanie do wydania w Vault było koszmarem. Zrób 90 minut wydajności i wyrzuć go. W Kiln można napisać kilka skryptów Perla, aby zautomatyzować kompilację/wydanie, co byłoby teraz niemal natychmiastowe, gdyby nie kilka minut ręcznej recenzji.

Największym wyzwaniem (jak sugeruje Helgi) jest zarządzanie oddziałami. Niektórzy programiści uważają to za wyjątkowo łatwe, inni z tym walczą.

Nie było również ścieżki konwersji z Vault do Kiln, więc utrzymujemy instancję serwera Vault do celów archiwalnych i zaczęliśmy od nowa z Kiln.

6 miesięcy później zmieniło to nasze życie (na lepsze).