GitLab CI vs. Jenkins [chiuso]

Qual è la differenza tra Jenkins e altri CI come GitLab CI, drone.io in arrivo con la distribuzione Git. In alcune ricerche ho potuto solo scoprire che l'edizione della comunità GitLab non consente l'aggiunta di Jenkins, ma l'edizione aziendale di GitLab sì. Ci sono altre differenze significative?

Questa è la mia esperienza:

Nel mio lavoro gestiamo i nostri repository con GitLab EE e abbiamo un server Jenkins (1.6) in esecuzione.

Nella base fanno praticamente lo stesso. Eseguiranno alcuni script su un'immagine server / Docker.

TL; DR;

• Jenkins è più facile da usare / imparare, ma ha il rischio di diventare un inferno plug-in
• Jenkins ha una GUI (questa può essere preferita se deve essere accessibile / gestibile da altre persone)
• L'integrazione con GitLab è inferiore rispetto a GitLab CI
• Jenkins può essere diviso dal tuo repository

La maggior parte dei server CI sono piuttosto semplici ( concourse.ci ), gitlab-ci , circle-ci , travis-ci , drone.io , gocd e cos'altro hai). Consentono di eseguire script shell / bat da una definizione di file YAML. Jenkins è molto più collegabile e viene fornito con un'interfaccia utente. Questo può essere un vantaggio o uno svantaggio, a seconda delle tue esigenze.

Jenkins è molto configurabile a causa di tutti i plugin disponibili. L'aspetto negativo di questo è che il tuo server CI può diventare uno spaghetti di plugin.

A mio avviso, concatenare e orchestrare i lavori in Jenkins è molto più semplice (a causa dell'interfaccia utente) rispetto a via YAML (chiamando i comandi di arricciatura). Inoltre, Jenkins supporta plug-in che installeranno determinati file binari quando non sono disponibili sul tuo server (non lo so per gli altri).

Al giorno d'oggi ( Jenkins 2 supporta anche più "proprio ci" con il plug-in Jenkinsfilee la pipeline che viene di default a partire da Jenkins 2), ma era meno accoppiato al repository rispetto a GitLab CI.

L'uso dei file YAML per definire la pipeline di compilazione (e alla fine eseguire pure shell / bat) è più pulito.

I plug-in disponibili per Jenkins consentono di visualizzare tutti i tipi di report, come i risultati dei test, la copertura e altri analizzatori statici. Certo, puoi sempre scrivere o utilizzare uno strumento per farlo per te, ma è sicuramente un vantaggio per Jenkins (specialmente per i manager che tendono a valutare troppo questi rapporti).

Ultimamente ho lavorato sempre di più con GitLab CI. In GitLab stanno facendo un ottimo lavoro rendendo divertente l'intera esperienza. Capisco che le persone usano Jenkins, ma quando hai GitLab in esecuzione e disponibile è davvero facile iniziare con GitLab CI. Non ci sarà nulla che si integri perfettamente come GitLab CI, anche se fanno un certo sforzo nelle integrazioni di terze parti.

• La loro documentazione dovrebbe iniziare in pochissimo tempo.
• La soglia per iniziare è molto bassa.
• La manutenzione è semplice (nessun plug-in).
• Scalare i corridori è semplice.
• CI fa parte del tuo repository.
• I lavori / le viste di Jenkins possono diventare disordinati.

Alcuni vantaggi al momento della scrittura:

• Supporto solo per un singolo file nell'edizione della comunità. File multipli nell'edizione enterprise .

Sono d'accordo con la maggior parte delle note di Rik, ma la mia opinione su quale sia più semplice è l'opposto : GitLab si sta dimostrando uno strumento fantastico con cui lavorare.

Gran parte del potere deriva dall'essere autonomo e dall'integrazione di tutto nello stesso prodotto nella stessa scheda del browser: dal browser del repository, dalla scheda delle emissioni o dalla cronologia delle costruzioni agli strumenti di distribuzione e al monitoraggio .

Lo sto usando in questo momento per automatizzare e testare come un'applicazione si installa su diverse distribuzioni Linux, ed è semplicemente velocissima da configurare (prova ad aprire una complessa configurazione di lavoro Jenkins in Firefox e attendi che lo script non responsive arrivi vs quanto sia leggero da modificare .gitlab-ci.yml).

Il tempo dedicato alla configurazione / ridimensionamento degli slave è notevolmente inferiore grazie ai binari del corridore ; inoltre il fatto che su GitLab.com ottieni corridori condivisi abbastanza decenti e gratuiti.

Jenkins si sente più manuale dopo alcune settimane di essere un utente esperto di GitLab CI, ad esempio duplicando lavori per ramo, installando plugin per fare cose semplici come il caricamento di SCP. L'unico caso d'uso che ho affrontato dove mi manca come oggi è quando è coinvolto più di un repository; che deve ancora essere ben capito.

A proposito, sto attualmente scrivendo una serie su GitLab CI per dimostrare come non sia così difficile configurare la tua infrastruttura CI repository con esso. Pubblicato la scorsa settimana, il primo pezzo introduce le basi, i pro ei contro e le differenze con altri strumenti: integrazione continua veloce e naturale con GitLab CI

Prima di tutto, ad oggi, GitLab Community Edition può essere completamente interoperabile con Jenkins. Nessuna domanda.

Di seguito, do un feedback su un'esperienza di successo che combina Jenkins e GitLab CI. Discuterò anche se dovresti usare entrambi o solo uno di essi, e per quale motivo.

Spero che questo ti dia informazioni di qualità sui tuoi progetti.

Punti di forza di GitLab CI e Jenkins

GitLab CI

GitLab CI è naturalmente integrato in GitLab SCM. È possibile creare pipeline utilizzando i gitlab-ci.ymlfile e manipolarli tramite un'interfaccia grafica.

Queste pipeline come codice possono ovviamente essere archiviate nella base di codice, applicando la pratica "tutto come codice" (accesso, controllo delle versioni, riproducibilità, riusabilità, ecc.).

GitLab CI è un ottimo strumento di gestione visiva:

• tutti i membri dei team (inclusi quelli non tecnici) hanno accesso rapido e semplice allo stato del ciclo di vita delle applicazioni.
• pertanto può essere utilizzato come dashboard interattivo e operativo per la gestione delle versioni.

Jenkins

Jenkins è un ottimo strumento di costruzione. La sua forza è nei suoi numerosi plugin. In particolare, ho avuto una grande fortuna nell'uso dei plugin di interfaccia tra Jenkins e altri strumenti CI o CD. Questa è sempre un'opzione migliore rispetto a riqualificare (possibilmente male) un'interfaccia di dialogo tra due componenti.

Pipeline come codice è disponibile anche tramite groovyscript.

Utilizzando GitLab CI e Jenkins insieme

All'inizio potrebbe sembrare un po 'ridondante, ma la combinazione di GitLab CI e Jenkins è piuttosto potente.

• GitLab CI orchestra condutture (catene, condutture, monitor ...) e si può beneficiare della sua interfaccia grafica integrata in GitLab
• Jenkins esegue il lavoro e facilita il dialogo con strumenti di terze parti.

Un altro vantaggio di questo design è di avere un accoppiamento libero tra gli strumenti:

• potremmo sostituire qualsiasi componente dello stabilimento di produzione senza dover rielaborare l'intero processo CI / CD
• potremmo avere un ambiente di costruzione eterogeneo, combinando (forse diversi) Jenkins, TeamCity, tu lo chiami, e avere ancora un singolo strumento di monitoraggio.

Il compromesso

Bene, ovviamente, c'è un prezzo da pagare per questo progetto: l'installazione iniziale è ingombrante e devi avere un livello minimo di comprensione di molti strumenti.

Per questo motivo, a meno che non raccomandi un simile set-up

• hai molti strumenti di terze parti da gestire. Questo è quando Jenkins è molto utile con i suoi numerosi plugin.
• devi avere a che fare con applicazioni complesse con tecnologie eterogenee, ognuna con un ambiente di build diverso e avere comunque un'interfaccia utente unificata per la gestione del ciclo di vita delle applicazioni.

Se non ti trovi in ​​nessuna di queste situazioni, probabilmente stai meglio con solo una delle due, ma non entrambe.

Se dovessi sceglierne uno

Sia GitLab CI che Jenkins hanno pro e contro. Entrambi sono strumenti potenti. Quindi quale scegliere?

risposta 1

Scegli quello in cui il tuo team (o qualcuno vicino) ha già un certo livello di competenza.

Risposta 2

Se sei una matricola completa nelle tecnologie CI, basta sceglierne una e iniziare.

• Se stai usando GitLab e hai un talento per tutto come codice, ha senso scegliere GitLab CI.
• Se devi dialogare con molti altri strumenti CI / CD o hai assolutamente bisogno di quella GUI per creare i tuoi lavori, scegli Jenkins.

Quelli di voi che usano GitLab e non sono sicuri che continueranno a farlo, devono comunque tenere presente che, avendo scelto GitLab CI, ciò significherebbe eliminare tutti i gasdotti CI / CD.

La parola finale è: l'equilibrio si inclina un po 'verso Jenkins a causa dei suoi numerosi plugin, ma è probabile che GitLab CI colmerà rapidamente il divario.

Vorrei aggiungere alcuni risultati del mio recente esperimento con GitLab CI. Le funzionalità fornite con 11.6 e 11.7 sono semplicemente fantastiche!

In particolare, adoro le onlycondizioni che in sostanza ti consentono di costruire condutture separate per merge_requesto push(l'elenco completo è qui )

Inoltre, mi piace molto l'assenza di plugin. Quando ho bisogno di alcune funzionalità più complesse, scrivo solo un'immagine Docker personalizzata che gestisce le funzionalità richieste (è lo stesso concetto che puoi vedere in drone.io ).

Se ti stai chiedendo di DRY , oggi è assolutamente possibile! Puoi scrivere i tuoi "modelli"

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

Inseriscili in alcuni repository pubblici, includili nella pipeline principale:

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

E usali per estendere un po 'di lavoro:

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

Adoro GitLab CI così tanto! Sì, (finora) non è possibile disegnare bei grafici con copertura e così via, ma nel complesso è uno strumento davvero pulito!

Modifica (23-02-2019): ecco il mio post sulle cose che amo in GitLab CI. È stato scritto in "era" 11.7, quindi quando leggi questa risposta, GitLab CI probabilmente ha molte più funzionalità.

Modifica (10-07-2019): Gitlab CI ora supporta più extendses

extends:
 - .pieceA
 - .pieceB

Controlla la documentazione ufficiale per ottenere maggiori informazioni su più estensioni

se i lavori di creazione / pubblicazione / distribuzione e test non sono molto complessi, l'utilizzo di gitlab ci presenta vantaggi naturali.

Poiché gitlab-ci.yml è presente accanto al codice in ogni ramo, è possibile modificare i passaggi ci / cd in particolare i test (che differiscono tra gli ambienti) in modo più efficace.

Ad esempio, si desidera eseguire test di unità per qualsiasi check-in al ramo di sviluppo, mentre si potrebbe desiderare di eseguire test funzionali completi sul ramo di controllo qualità e un limitato tipo di test di produzione può essere raggiunto facilmente utilizzando gitlab ci.

un secondo vantaggio oltre alla grande interfaccia utente è la sua capacità di utilizzare immagini docker per l'esecuzione di qualsiasi fase mantiene intatto il corridore host e quindi meno soggetto a errori.

inoltre gitlab ci farebbe automaticamente il check-in per te e non dovrai gestire jenkins master separatamente