Jaka jest różnica między Jenkinsem a innymi CI, takimi jak GitLab CI, drone.io, które są dostarczane z dystrybucją Git. Na podstawie niektórych badań mogłem tylko dojść do wniosku, że wydanie społeczności GitLab nie pozwala na dodanie Jenkinsa, ale wydanie GitLab dla przedsiębiorstw tak. Czy są jakieś inne istotne różnice?
132
Odpowiedzi:
Oto moje doświadczenie:
W mojej pracy zarządzamy naszymi repozytoriami za pomocą GitLab EE i mamy uruchomiony serwer Jenkins (1.6).
W zasadzie robią prawie to samo. Uruchomią niektóre skrypty na serwerze / obrazie Dockera.
TL; DR;
Większość serwerów CI jest dość prosta ( concourse.ci ), gitlab-ci , circle-ci , travis-ci , drone.io , gocd i co jeszcze masz). Umożliwiają one wykonywanie skryptów powłoki / nietoperzy z definicji pliku YAML. Jenkins jest znacznie bardziej podłączany i ma interfejs użytkownika. Może to być zaletą lub wadą, w zależności od Twoich potrzeb.
Jenkins jest bardzo konfigurowalny ze względu na wszystkie dostępne wtyczki. Wadą tego jest to, że twój serwer CI może stać się spaghetti wtyczek.
Moim zdaniem łączenie i organizowanie zadań w Jenkins jest znacznie prostsze (ze względu na interfejs użytkownika) niż przez YAML (wywoływanie poleceń curl). Poza tym Jenkins obsługuje wtyczki, które zainstalują określone pliki binarne, gdy nie są dostępne na twoim serwerze (nie wiem o tym w przypadku innych).
Obecnie ( Jenkins 2 obsługuje również bardziej „właściwego” z CI
Jenkinsfile
a PipLine wtyczki, która pochodzi z domyślnego jako Jenkins 2), ale kiedyś mniej sprzężony z repozytorium niż IE GitLab CI.Używanie plików YAML do definiowania potoku kompilacji (i na końcu uruchamiania czystej powłoki / nietoperza) jest czystsze.
Wtyczki dostępne dla Jenkins umożliwiają wizualizację wszelkiego rodzaju raportów, takich jak wyniki testów, pokrycie i inne analizatory statyczne. Oczywiście zawsze możesz napisać lub użyć narzędzia, które zrobi to za Ciebie, ale jest to zdecydowanie plus dla Jenkinsa (szczególnie dla menedżerów, którzy zbytnio cenią te raporty).
Ostatnio coraz więcej pracuję z GitLab CI. W GitLab wykonują naprawdę świetną robotę, sprawiając, że całe doświadczenie jest przyjemne. Rozumiem, że ludzie używają Jenkinsa, ale gdy masz działającego i dostępnego GitLab, bardzo łatwo jest zacząć z GitLab CI. Nie będzie niczego, co zintegruje się tak płynnie jak GitLab CI, mimo że wkładają sporo wysiłku w integracje z innymi firmami.
Niektóre korzyści w momencie pisania:
źródło
Zgadzam się z większością uwag Rika, ale moja opinia o tym, która jest prostsza, jest odwrotna : GitLab okazuje się świetnym narzędziem do pracy.
Większość mocy pochodzi z niezależności i integracji wszystkiego w tym samym produkcie na tej samej karcie przeglądarki: od przeglądarki repozytorium, tablicy problemów lub historii kompilacji po narzędzia do wdrażania i monitorowanie .
Używam go teraz do automatyzacji i testowania, jak aplikacja instaluje się w różnych dystrybucjach Linuksa, a konfiguracja jest po prostu błyskawiczna (spróbuj otworzyć złożoną konfigurację zadania Jenkinsa w przeglądarce Firefox i poczekaj, aż pojawi się niereagujący skrypt vs . jak lekka jest edycja
.gitlab-ci.yml
).Czas spędzony na konfigurowaniu / skalowaniu slaveów jest znacznie mniejszy dzięki plikom binarnym runner ; plus fakt, że w GitLab.com dostajesz całkiem przyzwoitych i darmowych współdzielonych biegaczy.
Jenkins czuje się bardziej manualny po kilku tygodniach bycia zaawansowanym użytkownikiem GitLab CI, np. Powielanie zadań na gałąź, instalowanie wtyczek do wykonywania prostych czynności, takich jak przesyłanie SCP. Jedynym przypadkiem użycia, z jakim się spotkałem, w którym tęsknię za tym na dzień dzisiejszy, jest sytuacja, gdy w grę wchodzi więcej niż jedno repozytorium; trzeba to jeszcze ładnie wymyślić.
BTW, obecnie piszę serię na temat GitLab CI, aby zademonstrować, jak nietrudno jest skonfigurować z nim infrastrukturę CI repozytorium. Opublikowany w zeszłym tygodniu pierwszy artykuł przedstawia podstawy, zalety i wady oraz różnice w stosunku do innych narzędzi: Szybka i naturalna ciągła integracja z GitLab CI
źródło
Jenkinsfile
. Masz rację,Jenkinsfile
że masz groovy (+ dodatkowe biblioteki java) dostępne do uruchomienia kodu, gdzie.gitlab-ci.yaml
plik będzie głównie obsługiwał powłokę, ale (w zależności od lokalizacji runnera). Z drugiej strony możesz to wszystko wywołać również ze skryptu powłoki, ale wadą jest to, że tworzysz zależności maszynowe (które moim zdaniem nie są zbyt przejrzyste).Przede wszystkim od dzisiaj GitLab Community Edition może być w pełni interoperacyjna z Jenkins. Bez pytania.
Poniżej przedstawiam kilka opinii na temat udanego doświadczenia, które łączy zarówno Jenkins, jak i GitLab CI. Omówię również, czy należy używać obu, czy tylko jednego, iz jakiego powodu.
Mam nadzieję, że dostarczy Ci to wartościowych informacji na temat Twoich własnych projektów.
Mocne strony GitLab CI i Jenkins
GitLab CI
GitLab CI jest naturalnie zintegrowany z GitLab SCM. Możesz tworzyć potoki za pomocą
gitlab-ci.yml
plików i manipulować nimi za pomocą interfejsu graficznego.Te potoki jako kod można oczywiście przechowywać w bazie kodu, wymuszając praktykę „wszystko jako kod” (dostęp, wersjonowanie, odtwarzalność, możliwość ponownego użycia itp.).
GitLab CI to świetne narzędzie do zarządzania wizualnego:
Jenkins
Jenkins to świetne narzędzie do budowania. Jego siła tkwi w wielu wtyczkach. Szczególnie miałem wielkie szczęście w używaniu wtyczek interfejsu między Jenkinsem a innymi narzędziami CI lub CD. Jest to zawsze lepsza opcja niż przebudowa (prawdopodobnie źle) interfejsu dialogowego między dwoma komponentami.
Pipeline jako kod jest również dostępny za pomocą
groovy
skryptów.Używanie GitLab CI i Jenkins razem
Na początku może wydawać się to trochę zbędne, ale połączenie GitLab CI i Jenkinsa jest dość potężne.
Kolejną zaletą tego projektu jest luźne połączenie między narzędziami:
Kompromis
Cóż, oczywiście za ten projekt trzeba zapłacić: początkowa konfiguracja jest uciążliwa i musisz mieć minimalny poziom zrozumienia wielu narzędzi.
Z tego powodu nie polecam takiej konfiguracji, chyba że
Jeśli nie jesteś w żadnej z tych sytuacji, prawdopodobnie lepiej będzie, jeśli masz tylko jedną z nich, ale nie obie.
Gdybym miał wybrać jedną
Zarówno GitLab CI, jak i Jenkins mają wady i zalety. Oba są potężnymi narzędziami. Więc który wybrać?
odpowiedź 1
Wybierz tę, w której Twój zespół (lub ktoś bliski) ma już pewien poziom wiedzy.
Odpowiedź 2
Jeśli wszyscy jesteście na pierwszym roku w technologiach CI, po prostu wybierzcie jedną i zacznijcie.
Ci z was, którzy używają GitLab i nie są pewni, czy będą to robić nadal, muszą pamiętać, że wybranie GitLab CI oznaczałoby usunięcie wszystkich twoich potoków CI / CD.
Ostatnie słowo jest takie: równowaga przechyla się trochę w stronę Jenkinsa ze względu na wiele wtyczek, ale są szanse, że GitLab CI szybko wypełni tę lukę.
źródło
Chciałbym dodać kilka ustaleń z moich ostatnich eksperymentów z GitLab CI. Funkcje dostępne w wersjach 11.6 i 11.7 są po prostu niesamowite!
W szczególności uwielbiam
only
warunki, które w zasadzie pozwalają budować oddzielne potoki dlamerge_request
lubpush
(pełna lista znajduje się tutaj )Poza tym bardzo podoba mi się brak wtyczek. Kiedy potrzebuję bardziej złożonej funkcjonalności, po prostu piszę niestandardowy obraz Dockera, który obsługuje wymaganą funkcjonalność (to ta sama koncepcja, którą można zobaczyć w drone.io ).
Jeśli zastanawiasz się nad DRY , w dzisiejszych czasach jest to absolutnie możliwe! Możesz napisać swoje „szablony”,
Umieść je w jakimś publicznym repozytorium, dołącz je do głównego potoku:
I użyj ich do przedłużenia pracy:
Bardzo kocham GitLab CI! Tak, to (jak dotąd) nie może rysować ładnych wykresów z pokryciem i tak dalej, ale ogólnie jest to naprawdę fajne narzędzie!
Edytuj (2019-02-23): oto mój post o rzeczach, które kocham w GitLab CI. Został napisany w 11.7 „era”, więc kiedy czytasz tę odpowiedź, GitLab CI prawdopodobnie ma o wiele więcej funkcji.
Edycja (2019-07-10): Gitlab CI obsługuje teraz wiele,
extends
npSprawdź oficjalną dokumentację, aby uzyskać więcej informacji o wielu rozszerzeniach
źródło
Jeśli twoje zadania związane z budowaniem / publikowaniem / wdrażaniem i testowaniem nie są bardzo złożone, użycie gitlab ci ma naturalne zalety.
Ponieważ gitlab-ci.yml jest obecny obok twojego kodu w każdej gałęzi, możesz efektywniej modyfikować swoje kroki ci / cd, szczególnie testy (które różnią się w zależności od środowiska).
Na przykład, chcesz wykonać testy jednostkowe dla dowolnego checkin to dev branch, podczas gdy możesz chcieć przeprowadzić pełne testy funkcjonalne w gałęzi QA i ograniczoną liczbę testów typu get na produkcji, można to łatwo osiągnąć za pomocą gitlab ci.
Drugą zaletą oprócz świetnego interfejsu użytkownika jest możliwość użycia obrazów dockera do wykonania dowolnego etapu, dzięki czemu host runner jest nienaruszony, a tym samym mniej podatny na błędy.
Co więcej, gitlab ci automatycznie zamelduje się dla Ciebie i nie musisz osobno zarządzać mistrzem Jenkinsa
źródło