Hudson vs Jenkins w 2012 roku [zamknięte]

W 2011 sytuacja z Hudsonem i Jenkinsem była następująca (IMHO) - Hudson był trochę stabilny, ale rozwój Jenkinsa był trochę szybszy.
Jak wygląda sytuacja z "Hudson vs Jenkins" teraz w 2012 roku?

Jeśli chodzi o stabilność, od ponad roku Jenkins oferuje wersję długoterminowego wsparcia (LTS) dla osób, które chcą mieć większą pewność co do stabilności i wsparcia instalowanego oprogramowania.

Mniej więcej co trzy miesiące wybierana jest poprzednia wersja, która została uznana za dobrze działającą przez społeczność użytkowników Jenkins. Ta wersja jest następnie rozgałęziona, wszelkie ważne poprawki (które zostały „przetestowane w walce”) są przenoszone z powrotem do tej wersji Jenkinsa, a następnie to wydanie przechodzi dodatkowe testy przez różne osoby i firmy. Gdy będzie gotowy do wydania, stanie się nową wersją LTS.

W miarę pojawiania się nowych poprawek o wysokim priorytecie są one przenoszone do wersji LTS.

Wielu dużych użytkowników Jenkinsa trzyma się linii wydań LTS, a według publicznych statystyk użytkowania Jenkinsa korzysta z niej kilka tysięcy wdrożeń.

Powinno to oznaczać, że wersja LTS, którą pobierasz, jest jeszcze bardziej stabilna niż wersja losowa wybrana ze zwykłej cotygodniowej linii wydań.

Poza statystykami, sytuacja dotycząca użycia Jenkinsa, rozmiaru społeczności, poziomu jej rozwoju, tempa dodawania nowych funkcji, liczby nowych wtyczek i aktywności na listach mailingowych w porównaniu z Hudsonem nie zmieniła się (tj. Jenkins pozostaje coraz bardziej naprzód ).

Zasadniczo większość punktów poruszonych w tej poprzedniej dyskusji nadal ma zastosowanie, chociaż wydaje się, że początkowe wsparcie korporacyjne Hudsona nieco osłabło.

Użyłem zarówno Hudsona, jak i Jenkinsa. Śledziłem obie listy zmian.

Nadal uważam, że dokonaliśmy właściwego wyboru, przenosząc się z Hudson do Jenkins. Główni programiści Hudson pracują teraz nad Jenkinsem. Ci, którzy nadal są zatrudnieni przez Oracle, to głównie ci, którzy wspierają Hudson (o ile wiem, ludzie Apache Maven również wnoszą poprawki).

Zgłosiłem wiele błędów w erze Hudsona. Mogę powiedzieć, że większość z nich została rozwiązana w Jenkins. Wiele miesięcy po rozwiązaniu problemu ludzie z Hudson naprawili lub poprosili o dalsze uwagi dotyczące tych konkretnych błędów.

Większość twórców wtyczek (to znaczy prawie wszyscy) dokonała migracji swoich wtyczek do Jenkins i teraz obsługuje głównie Jenkins. Pod względem wtyczek Jenkins rozwija się dużo, dużo szybciej. Istnieje teraz kilka płatnych wtyczek dostarczanych przez Cloudbees.

O ile mi wiadomo, większość społeczności open source przeniosła się do Jenkinsa.

Niektóre firmy, które wolą płatne wsparcie i nie chcą kłopotów z migracją do Jenkins, nadal korzystają z Hudson. Szczerze mówiąc, nie rozumiem dlaczego. Jenkins ma również wsparcie komercyjne od Cloudbees, w którym teraz pracuje Kohsuke Kawaguchi (twórca Hudson). Cloudbees mają teraz nawet bezpłatną usługę do hostowania projektów hostowanych na GitHub w ich chmurze. Pozwalają budować projekty OSS za darmo! :)

Jenkins ulepszył obsługę chmury. Jak wspomniano powyżej, Cloudbees również zapewnia to SaaS w chmurze. Nie jestem pewien, czy i w jakim stopniu Hudson to popiera. Myślę, że w tej chwili nie są tak zaawansowani; w każdym przypadku Hudson nie zapewnia usługi SaaS dla chmury, o ile wiem.

Uważam, że jeśli musisz wybrać jeden, powinien to być Jenkins.

Myślę, że https://stackoverflow.com/a/5970813/556520 odpowiada na wiele ważnych pytań dotyczących problemu Hudson vs Jenkins. Temat wyjaśnia obie strony sytuacji z zaletami i wadami każdego produktu.

Z własnego doświadczenia w pracy z CI przez lata, a ostatnio zacząłem tworzyć dla Hudson, trzymałbym się stabilnej wersji hudsona tylko dlatego, że jenkins zajmuje się rozwojem i wsparciem dla ich usługi Cloudbees, gdzie Hudson przeniósł się do fundacji Eclipse i nie jest rozwijanie się dla usługi. To tylko moje 0,02 dolara.