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?
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.
+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.
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.
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.
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.
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.
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.
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 ).
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.