GitLab CI vs. Jenkins [zamknięte]

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?

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;

• Jenkins jest łatwiejszy w użyciu / nauce, ale istnieje ryzyko, że stanie się piekłem wtyczek
• Jenkins ma GUI (może to być preferowane, jeśli ma być dostępne / możliwe do utrzymania przez inne osoby)
• Integracja z GitLab jest mniejsza niż z GitLab CI
• Jenkins można oddzielić od repozytorium

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 Jenkinsfilea 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.

• Ich dokumentacja powinna umożliwić Ci błyskawiczne rozpoczęcie pracy.
• Próg do rozpoczęcia jest bardzo niski.
• Konserwacja jest łatwa (bez wtyczek).
• Skalowanie biegaczy jest proste.
• W pełni część twojego repozytorium.
• Zadania / widoki Jenkins mogą stać się nieporządne.

Niektóre korzyści w momencie pisania:

• Obsługa tylko jednego pliku w wydaniu społecznościowym. Wiele plików w wersji Enterprise .

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

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.ymlplikó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:

• wszyscy członkowie zespołów (w tym nietechniczni) mają szybki i łatwy dostęp do stanu cyklu życia aplikacji.
• dlatego może być używany jako interaktywny i operacyjny pulpit nawigacyjny do zarządzania wersjami.

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ą groovyskryptó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.

• GitLab CI organizuje (łańcuchy, przebiegi, monitory ...) potoki i można skorzystać z jego graficznego interfejsu zintegrowanego z GitLab
• Jenkins wykonuje zadanie i ułatwia dialog z narzędziami innych firm.

Kolejną zaletą tego projektu jest luźne połączenie między narzędziami:

• moglibyśmy wymienić dowolny z komponentów build factory bez konieczności przeróbki całego procesu CI / CD
• moglibyśmy mieć heterogeniczne środowisko kompilacji, łączące (prawdopodobnie kilka) Jenkins, TeamCity, jak to nazywasz, i nadal mieć jedno narzędzie do monitorowania.

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

• masz do czynienia z wieloma narzędziami innych firm. Wtedy Jenkins jest bardzo przydatny dzięki wielu wtyczkom.
• musisz radzić sobie ze złożonymi aplikacjami z heterogenicznymi technologiami, z których każda ma inne środowisko kompilacji, i nadal musisz mieć ujednolicony interfejs zarządzania cyklem życia aplikacji.

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.

• Jeśli używasz GitLab i masz talent do wszystkiego jako kodu, wybór GitLab CI jest absolutnie sensowny.
• Jeśli musisz dialogować z wieloma innymi narzędziami CI / CD lub absolutnie potrzebujesz tego GUI do tworzenia swoich zadań, wybierz Jenkins.

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ę.

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 onlywarunki, które w zasadzie pozwalają budować oddzielne potoki dla merge_requestlub push(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”,

.myTemplate:
  image: node:10.14.2
  script:
    - npm install
    - npm run test

Umieść je w jakimś publicznym repozytorium, dołącz je do głównego potoku:

include:
  - remote: https://....

I użyj ich do przedłużenia pracy:

test:
  extends: .myTemplate
  only:
    refs: ["master"]
    variables:
      - $CI_PIPELINE_SOURCE == "push"

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, extendsnp

extends:
 - .pieceA
 - .pieceB

Sprawdź oficjalną dokumentację, aby uzyskać więcej informacji o wielu rozszerzeniach

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