Hudson czy Teamcity do ciągłej integracji? [Zamknięte]
100
Jesteśmy sklepem Java szukającym narzędzia CI do wykorzystania. Wydaje się, że zarówno Hudson, jak i Teamcity są wolne, ale Teamcity wydaje się być bardziej przejrzysty i ma większe wsparcie.
Zastanawiałem się, dlaczego nadal można by używać Hudsona i czy ktoś mógłby przedstawić argument za / przeciw któremuś z nich?
Wrzuciłbym CruiseControl do miksu - jeśli jeszcze tego nie rozważałeś. Nie mogę komentować punktu widzenia Java, ponieważ korzystałem z wersji .NET, ale to mi się podoba.
AdaTheDev
3
@ire_and_curses żadna z odpowiedzi w poście nie daje dobrego argumentu dla któregokolwiek narzędzia w porównaniu z drugim
pdeva
4
-1 dla tempomatu - ZNACZNIE zbyt wiele plików konfiguracyjnych, które trzeba skonfigurować ręcznie „tak”.
Bevan
3
O ile widzę, istnienie darmowego TeamCity sprawia, że CruiseControl przestaje istnieć. Nie widzę powodu, aby używać CruiseControl zamiast TeamCity. I wiele powodów na odwrót.
Niall Connaughton
Odpowiedzi:
113
Team City jest zdecydowanie najlepszym serwerem CI. Jego zabójczą cechą jest dla mnie ścisła integracja z IDE (IntelliJ, Eclipse i VisualStudio). Może na przykład pokazać, kiedy plik, który edytujesz w IDE, staje się nieaktualny, kto go zmienił i co zmienił. Możesz zatwierdzić z IDE do serwera CI, uruchomić kompilację i testy w siatce kompilacji, a następnie serwer CI zatwierdzi, jeśli kompilacja się powiedzie. Możesz kliknąć raporty kompilacji w aplikacji internetowej CI, a otworzy ona odpowiednie pliki w IDE.
Zdalne uruchamianie / Wstępnie przetestowane zatwierdzenie to bardzo przydatne funkcje TeamCity. Ogólnie rzecz biorąc, TC może być wygodniejsze, jeśli twoje kompilacje nie są szybkie, ponieważ w TeamCity otrzymujesz ciągłe informacje zwrotne na temat tego, co dzieje się w twojej kompilacji (ile testów przeszło, nie powiodło się, na jakim etapie jest kompilacja i tak dalej). Również powiadomienia NW są bardziej wyrafinowane. Możesz skonfigurować różne reguły dla różnych typów kompilacji i dla szerokiej gamy powiadamiających (e-mail, Jabber, okienko).
Pavel Sher
6
@Pavel: Nie znam TeamCity tak dobrze, jak Hudson, więc nie będę kwestionował początku twojego komentarza. Ale jeśli chodzi o powiadomienia, twierdzenie, że TC jest bardziej wyrafinowany, jest moim niezbyt skromnym zdaniem czystym FUDem. Wszystkie wymienione kanały powiadomień są dostępne na Hudson (możesz nawet dodać Twittera). Właściwie założę się, że Hudson ma znacznie więcej wtyczek niż TC (sprawdź wiki.hudson-ci.org/display/HUDSON/Plugins ) i jestem pewien, że TC ma więcej ograniczeń niż Hudson.
Pascal Thivent
3
Zgadzam się co do kanałów (Hudson ma dużo wtyczek), ale nie zgadzam się co do zasad. W TeamCity możesz subskrybować kompilacje ze swoimi zmianami, możesz wybrać opcję powiadamiania, gdy kompilacja zaczyna się kończyć (np. Gdy pierwszy test zaczyna się nie powieść). Możesz poprosić o powiadomienie o pierwszej nieudanej kompilacji po sekwencji sukcesu + o pierwszym sukcesie po niepowodzeniu. Te opcje są dostępne dla wszystkich kanałów powiadomień. Jednym z takich kanałów jest powiadomienie IDE: gdy coś pójdzie nie tak, otrzymasz powiadomienie bezpośrednio w swoim IDE. Jak pamiętam, zasady powiadamiania Hudson były znacznie prostsze.
Pavel Sher
2
Pavel - nie chcąc tutaj meczu procy, ale domyślnie Hudson wyśle Ci e-maila tylko wtedy, gdy przyczynisz się do niepowodzenia kompilacji. Jeśli chcesz, możesz także zasubskrybować, aby otrzymywać powiadomienia o każdej nieudanej kompilacji. Jest też więcej opcji we wtyczce email-ext. Nie musisz tego zatwierdzać, ale nie wprowadzajmy w błąd.
Jim T
4
Szybkie Google pokaże Ci, że istnieją wtyczki do kontrolowania królików nabaztag i innych uroczych urządzeń z Team City. Lub możesz użyć wtyczki, do której dołączyłem w mojej odpowiedzi . Zaletą ścisłej integracji IDE jest znacznie szybsza i bardziej ukierunkowana informacja zwrotna na temat kodu, nad którym pracujesz podczas pracy z nim. Nie musisz czekać na powiadomienie, przełączyć się na przeglądarkę tge, przeczytać raport, przełączyć się z powrotem do IDE i otworzyć odpowiedni plik. Okienko edytora zmienia się podczas pracy, aby pokazać, jak inni członkowie zespołu wpłynęli na kod.
Nat
58
+1 dla Hudsona.
Hudson to bardzo aktywny projekt, ma szeroką społeczność użytkowników i lista mailingowa aktywnych użytkowników, jest naprawdę łatwa do rozpoczęcia, jest łatwa w użyciu, była używana w ogromnych, bardzo dużych projektach (JBoss, JAX-WS, itp.), a tym samym ma udokumentowane rekordy sukcesu, oferuje bardzo dobre zaawansowane funkcje (np. macierz kompilacji, klastrowanie kompilacji itp.), jest open source, ma wiele wtyczek ...
A jeśli wsparcie jest naprawdę ważną rzeczą, można uzyskać komercyjne wsparcie od Słońca . Ale FWIW, nigdy nie miałem problemu z blokowaniem w przypadku Hudson.
Aktualizacja: Jak być może wiesz, Kohsuke Kawaguchi (twórca Hudson) opuścił Sun / Oracle i założył własną firmę, aby przenieść Hudson do następnego etapu . Innymi słowy, nie stanowi to zagrożenia dla Hudsona. A jeśli szukasz wsparcia, możesz otrzymać certyfikowaną wersję Hudson CI Server w ramach planu subskrypcji (ta certyfikowana wersja zawiera wysokiej jakości wydanie Hudson z predefiniowanym zestawem wtyczek oraz kilka komercyjnych).
Aktualizacja: aby zilustrować wielkość ich odpowiedniej bazy użytkowników, oto porównanie trendów zatrudnienia dla kilku narzędzi CI w usłudze Indeed (zapytanie na żywo):
Być może TeamCity jest tak łatwy w użyciu, że nie wymaga nikogo specjalnie zatrudnionego do jego konfiguracji?
Henrik
3
@Henrik: Interpretacja powyższego wykresu zależy od Twojego uznania. Ale tak, może TeamCity to magia.
Pascal Thivent
16
Jeśli zatrudniasz inżyniera budowania na pełny etat do prowadzenia ciągłej integracji, masz teraz dwa problemy: 1) Twój CI jest trudny w obsłudze, więc twoi programiści będą się z tym zmagać, a wiedza będzie tkwić w głowie tej jednej osoby, 2) Płacisz komuś za pracę, której nie trzeba wykonywać!
Niall Connaughton
15
Gdybym wybierał serwer CI, wybrałbym ten, który miał NAJNIŻSZE oferty pracy dla dedykowanego inżyniera do administrowania nim. Jest to narzędzie programistyczne, a programiści powinni być w stanie samodzielnie nim zarządzać. Jeśli nie, potrzebujesz innego narzędzia lub różnych programistów.
Nat,
Wykres trendów w pracy wcale nie oznacza +1 dla
hudsona
17
Zaczęliśmy z Hudsonem przy kilku projektach Flex, a następnie przenieśliśmy się do TeamCity, kiedy programiści .NET dołączyli do naszych wysiłków związanych z CI. Teraz ponownie wymieniliśmy serwer TeamCity, z powrotem do Hudson. Główne powody to: - Tętniąca życiem społeczność Hudson, lepsza niż wsparcie. - Ogromna ilość wtyczek do każdego rodzaju zadań. - Otwarte źródło. - Hudson jest darmowy, TeamCity jest darmowy tylko dla 10 projektów.
edycja: TeamCity jest teraz bezpłatne dla 20 projektów.
Spadło 10 ograniczeń projektu, jedynym ograniczeniem jest teraz 20 konfiguracji kompilacji. W przypadku małych i średnich projektów może wystarczyć.
jesion
4
Z ciekawości, jakich funkcji, które były dostępne przez wtyczki Jenkinsa, brakowało w świecie TeamCity?
Behrang Saeedzadeh
14
TeamCity jest świetny, ponieważ pozwala każdemu programistowi mieć własny profil kompilacji i podłączyć się do niego ze swojego IDE. Że samotny „kopie tyłki”. Jest też wsparcie dla GIT itp. Spójrz na to poważnie. Wersja profesjonalna jest bezpłatna.
GIT jest również obsługiwany przez Jenkins / Hudson
CJBrew,
14
Największym argumentem przeciwko Hudsonowi jest to, że każde wydanie wprowadza nowe błędy.
Wydania są bardzo częste, więc musisz często aktualizować, aby nie zostać w tyle. Oznacza to, że musisz poświęcić dużo czasu na diagnozowanie problemów i cofanie się do poprzednich wersji Hudson. (Czasami wycofanie nie jest nawet możliwe!)
Wprowadzamy ciągłe wdrażanie w naszym sklepie (kiedy sprawdzasz kod, jest on wdrażany w witrynie na żywo!), A zmaganie się z Hudsonem kosztuje nas zbyt wiele.
Aktywnie przyglądamy się migracji do TeamCity wyłącznie ze względu na koszty błędów Hudsona.
To, że dostępna jest aktualizacja, nie oznacza, że musisz ją zaktualizować. Wolałbym, żeby wypuszczali częściej niż rzadziej. To mój wybór, kiedy dokonać aktualizacji i na pewno nie robię tego co tydzień. Ponadto opiekunowie są bardzo konserwatywni, jeśli chodzi o kompatybilność wsteczną. Wtyczki generalnie nie wymagają najnowszej wersji Hudson do działania. W rzeczywistości 130 dostępnych obecnie wtyczek jest zbudowanych dla wersji Hudson, które mają ponad rok. Jeśli nadal jesteś zaniepokojony, pracujemy nad automatyczną wtyczką do wycofywania zmian ..;)
Christopher Orr
1
Z mojego doświadczenia wynika, że problem dotyczy bardziej wtyczek niż samego Hudsona, chociaż z punktu widzenia użytkownika nie robi to dużej różnicy. Ale nic nie zmusza cię do aktualizacji, chyba że napotkasz konkretny błąd lub nie możesz żyć bez nowej funkcji. Po prostu nie śledzimy każdego wydania i nie używanie ostatecznej wersji nie jest dla nas żadnym problemem: „Jeśli się nie zepsuje, nie naprawiaj go” .
Pascal Thivent
2
Powód do aktualizacji jest uzasadniony, gdy główny inicjator wysyła komunikat informujący o naprawieniu poważnej luki w zabezpieczeniach. Mój punkt widzenia jest nadal aktualny: Hudson jest po prostu zbyt kruchy - nawet bez zainstalowanych dodatkowych wtyczek.
jdtangney
1
Mogę powiedzieć, że po półtora roku używania Hudson / Jenkins w jednym projekcie, chociaż jest to świetne narzędzie - zbyt często doświadczyliśmy niespójnej jakości między wydaniami - i uaktualnialiśmy się tylko wtedy, gdy było to absolutnie konieczne. Znaleźliśmy obejścia, w tym częste tworzenie kopii zapasowych konfiguracji. Nie mogę się doczekać wypróbowania TeamCity w moim najnowszym projekcie.
JaysonRaymond
4
Dlaczego aktualizacje i stabilność powinny być czynnikami przeciwstawnymi? Czy to nie tylko wskazuje na brak jakości?
Niall Connaughton,
6
Naprawdę podobało mi się Teamcity, ale w środowisku, w którym pracuję, czas potrzebny na uzyskanie zamówienia dla Teamcity przez warstwy zarządzania prawdopodobnie przekroczyłby czas potrzebny na migrację wszystkiego do Hudson.
@Pavel, mamy ponad 20 użytkowników i znacznie więcej kompilacji.
sal
22
@sal zawsze mnie zadziwia, jak firmy mogą być tak zaniepokojone kilkoma tysiącami dolarów na narzędzia swoich zespołów programistycznych i wolałyby, aby marnowały setki połączonych godzin, których nie miałyby z tym narzędziem.
Chris Marisic,
5
@Chris A co, jeśli zaczną od darmowego narzędzia open source, aby tylko zobaczyć, jak coś działa, a 2 lata później zdać sobie sprawę, że nadal działa bez żadnych problemów? Czy nadal sugerowałbyś wydanie kilku tysięcy dolarów na uaktualnienie do komercyjnego narzędzia, które prawdopodobnie robi dokładnie to samo?
stefanB
1
@stefan Jeśli używasz narzędzia przez 2 lata i spełnia ono Twoje potrzeby, chyba że istnieje funkcja X, której potrzebujesz z innego narzędzia, dlaczego miałbyś przełączyć się na inne narzędzie bezpłatne lub płatne?
Chris Marisic
2
Używałem i konfigurowałem TeamCity i Jenkins (aka nowy Hudson) już wcześniej i chociaż zgodzę się, że TeamCity jest dużo szybszy w konfiguracji, jest darmowy tylko dla zespołów liczących maksymalnie 10 użytkowników. Oba systemy są bardzo łatwe w konfiguracji i mają system wtyczek, który jest dobrze obsługiwany. Zabójczą funkcją w TeamCity jest przepływ pracy przed sprawdzeniem, w którym można przetestować kod przed sprawdzeniem go w kontroli źródła, a zaletą Jenkinsa jest to, że jest całkowicie bezpłatny, nawet jeśli przekroczysz 10 użytkowników i zbudujesz agentów.
Podoba mi się również widok wykresu Jenkinsa, a tego właśnie mi brakuje w Teamcity. Dalej zgadzam się z twoim komentarzem!
Danny Gloudemans
Jeśli zgadzasz się z komentarzem, zagłosuj na niego :)
runxc1 Bret Ferrier
1
Dopiero zaczynam przyzwyczajać się do tego, że hudson jest gotowy do eksperymentowania i zobaczę, jak będzie pasował do naszego obecnego środowiska. Nie mam absolutnie żadnego doświadczenia z Teamcity, więc nie mogę tego komentować, ale dotychczasowa praca z hudsonem sprawia mi przyjemność.
Polecałem klientom, że uważają Bamboo. Powodem jest to, że (ok, czytając specyfikacje!) Ma bardzo podobny zestaw funkcji do TeamCity. Jednak główną zaletą jest bardzo ścisła integracja z JIRA, która jest dość popularna jako system śledzenia funkcji / błędów. Kompletny zestaw to JIRA, Greenhopper, Bamboo i Eclipse. Spora część klientów ma również centrum jakości HP i są wtyczki, które łączą to również z JIRA. Podoba mi się również to, że JIRA, Bamboo i GreenHopper pochodzą z Atlassian.
Po intensywnym korzystaniu z TeamCity Jenkins wygląda bardzo surowo. Tak, wtyczki pozwalają na wszystko, po ich zainstalowaniu. TeamCity ma dojrzały zestaw funkcji, dzięki którym możesz wyjść z pudełka. Jednak na poziomie ciągłych dostaw oba pozostawiają niezaimplementowany właściwy potok pomostowy. QuickBuild to jeszcze bardziej bogaty w funkcje produkt, który zasługuje na uwagę, jest płatny.
bbaassssiiee
Widząc teraz Bamboo w akcji w witrynie klienta, nie jestem już nim zainteresowany. Istnieją pewne obszary związane ze skryptami i przesyłaniem informacji między kompilacjami, z którymi ma problemy. W rezultacie programiści umieszczają różne rzeczy w globalnym obszarze zmiennych CI, których po prostu nie powinno tam być.
Odpowiedzi:
Team City jest zdecydowanie najlepszym serwerem CI. Jego zabójczą cechą jest dla mnie ścisła integracja z IDE (IntelliJ, Eclipse i VisualStudio). Może na przykład pokazać, kiedy plik, który edytujesz w IDE, staje się nieaktualny, kto go zmienił i co zmienił. Możesz zatwierdzić z IDE do serwera CI, uruchomić kompilację i testy w siatce kompilacji, a następnie serwer CI zatwierdzi, jeśli kompilacja się powiedzie. Możesz kliknąć raporty kompilacji w aplikacji internetowej CI, a otworzy ona odpowiednie pliki w IDE.
Są dostępne wtyczki (napisałem jedną: http://team-piazza.googlecode.com ), ale niewiele.
źródło
+1 dla Hudsona.
Hudson to bardzo aktywny projekt, ma szeroką społeczność użytkowników i lista mailingowa aktywnych użytkowników, jest naprawdę łatwa do rozpoczęcia, jest łatwa w użyciu, była używana w ogromnych, bardzo dużych projektach (JBoss, JAX-WS, itp.), a tym samym ma udokumentowane rekordy sukcesu, oferuje bardzo dobre zaawansowane funkcje (np. macierz kompilacji, klastrowanie kompilacji itp.), jest open source, ma wiele wtyczek ...
A jeśli wsparcie jest naprawdę ważną rzeczą, można uzyskać komercyjne wsparcie od Słońca . Ale FWIW, nigdy nie miałem problemu z blokowaniem w przypadku Hudson.Aktualizacja: Jak być może wiesz, Kohsuke Kawaguchi (twórca Hudson) opuścił Sun / Oracle i założył własną firmę, aby przenieść Hudson do następnego etapu . Innymi słowy, nie stanowi to zagrożenia dla Hudsona. A jeśli szukasz wsparcia, możesz otrzymać certyfikowaną wersję Hudson CI Server w ramach planu subskrypcji (ta certyfikowana wersja zawiera wysokiej jakości wydanie Hudson z predefiniowanym zestawem wtyczek oraz kilka komercyjnych).
Aktualizacja: aby zilustrować wielkość ich odpowiedniej bazy użytkowników, oto porównanie trendów zatrudnienia dla kilku narzędzi CI w usłudze Indeed (zapytanie na żywo):
Nie jest to oczywiście wskaźnik techniczny.
źródło
Zaczęliśmy z Hudsonem przy kilku projektach Flex, a następnie przenieśliśmy się do TeamCity, kiedy programiści .NET dołączyli do naszych wysiłków związanych z CI. Teraz ponownie wymieniliśmy serwer TeamCity, z powrotem do Hudson. Główne powody to: - Tętniąca życiem społeczność Hudson, lepsza niż wsparcie. - Ogromna ilość wtyczek do każdego rodzaju zadań. - Otwarte źródło. - Hudson jest darmowy, TeamCity jest darmowy tylko dla 10 projektów.
edycja: TeamCity jest teraz bezpłatne dla 20 projektów.
źródło
TeamCity jest świetny, ponieważ pozwala każdemu programistowi mieć własny profil kompilacji i podłączyć się do niego ze swojego IDE. Że samotny „kopie tyłki”. Jest też wsparcie dla GIT itp. Spójrz na to poważnie. Wersja profesjonalna jest bezpłatna.
źródło
Największym argumentem przeciwko Hudsonowi jest to, że każde wydanie wprowadza nowe błędy.
Wydania są bardzo częste, więc musisz często aktualizować, aby nie zostać w tyle. Oznacza to, że musisz poświęcić dużo czasu na diagnozowanie problemów i cofanie się do poprzednich wersji Hudson. (Czasami wycofanie nie jest nawet możliwe!)
Wprowadzamy ciągłe wdrażanie w naszym sklepie (kiedy sprawdzasz kod, jest on wdrażany w witrynie na żywo!), A zmaganie się z Hudsonem kosztuje nas zbyt wiele.
Aktywnie przyglądamy się migracji do TeamCity wyłącznie ze względu na koszty błędów Hudsona.
źródło
Naprawdę podobało mi się Teamcity, ale w środowisku, w którym pracuję, czas potrzebny na uzyskanie zamówienia dla Teamcity przez warstwy zarządzania prawdopodobnie przekroczyłby czas potrzebny na migrację wszystkiego do Hudson.
źródło
Używałem i konfigurowałem TeamCity i Jenkins (aka nowy Hudson) już wcześniej i chociaż zgodzę się, że TeamCity jest dużo szybszy w konfiguracji, jest darmowy tylko dla zespołów liczących maksymalnie 10 użytkowników. Oba systemy są bardzo łatwe w konfiguracji i mają system wtyczek, który jest dobrze obsługiwany. Zabójczą funkcją w TeamCity jest przepływ pracy przed sprawdzeniem, w którym można przetestować kod przed sprawdzeniem go w kontroli źródła, a zaletą Jenkinsa jest to, że jest całkowicie bezpłatny, nawet jeśli przekroczysz 10 użytkowników i zbudujesz agentów.
źródło
Dopiero zaczynam przyzwyczajać się do tego, że hudson jest gotowy do eksperymentowania i zobaczę, jak będzie pasował do naszego obecnego środowiska. Nie mam absolutnie żadnego doświadczenia z Teamcity, więc nie mogę tego komentować, ale dotychczasowa praca z hudsonem sprawia mi przyjemność.
Istnieje wiele wtyczek dla hudson, a witryna hudson zawiera wiele porad dotyczących pisania własnych ( http://wiki.hudson-ci.org/display/HUDSON/Extend+Hudson ).
źródło
Polecałem klientom, że uważają Bamboo. Powodem jest to, że (ok, czytając specyfikacje!) Ma bardzo podobny zestaw funkcji do TeamCity. Jednak główną zaletą jest bardzo ścisła integracja z JIRA, która jest dość popularna jako system śledzenia funkcji / błędów. Kompletny zestaw to JIRA, Greenhopper, Bamboo i Eclipse. Spora część klientów ma również centrum jakości HP i są wtyczki, które łączą to również z JIRA. Podoba mi się również to, że JIRA, Bamboo i GreenHopper pochodzą z Atlassian.
źródło