Negli ultimi anni, DevOps è diventato una parte cruciale del ciclo di vita del software. Ciò ha alimentato la crescita di molti strumenti e pratiche DevOps. È possibile trovare una gamma di strumenti per supportare il processo CI/CD. Jenkins e GitHub Actions sono probabilmente ora gli strumenti di punta.
Introduzione Jenkins e GitHub Actions
Cominciamo con Jenkins. Ecco una breve descrizione, “Jenkins è un server di automazione gratuito e Open Source. Aiuta ad automatizzare le parti dello sviluppo del software relative alla creazione, al test e alla distribuzione, facilitando l'integrazione continua e il deploy". ~ Da Wikipedia
Allo stesso modo, GitHub Actions è l'ultima delle due offerte da GitHub come offerta SaaS.
"GitHub Actions ora rende più semplice automatizzare il modo in cui crei, collaudi e distribuisci i tuoi progetti su qualsiasi piattaforma, inclusi Linux, MacOS e Windows. Esegui i tuoi flussi di lavoro in un contenitore o in una macchina virtuale ". ~ Dal blog di GitHub
Prima di decidere se vale la pena cambiare, capiamo chi dovrebbe considerarlo in primo luogo.
Dovresti considerare il passaggio da Jenkins?
Se tutto funziona per te con Jenkins, sei sicuro della tua configurazione pur avendo il pieno controllo e il costo non è un problema, consiglierei di rimanere con Jenkins. Per coloro che utilizzano GitHub come piattaforma di controllo del codice sorgente e già sentono di non essere sicuri della configurazione di Jenkins e cercano un'alternativa migliore, le azioni di GitHub diventeranno la scelta principale da prendere in considerazione.
Poiché GitHub Actions è un servizio completamente gestito da GitHub, non è necessario sapere come ridimensionare e utilizzare l'infrastruttura per eseguirlo.
Questo è il motivo principale per cui ho scelto di trasferirmi da Jenkins, dove non avevo il pieno controllo di ciò che stava accadendo con le mie pipeline CI/CD.
Alcune delle sfide che ho dovuto affrontare su Jenkins:
- Mantenere aggiornati i plugin.
- La mia singola build del server Jenkins costa denaro anche se non eseguo nessuna build.
- Non coerente su build simultanee.
- Ho dovuto dipendere da diversi plugin, che vengono forniti con aggiornamenti che devo gestire di volta in volta.
- So che esistono soluzioni con Jenkins per risolvere alcuni di questi problemi, ma ne avevo abbastanza e sono passato a una piattaforma gestita.
Diamo un'occhiata alle funzionalità offerte da GitHub Actions per considerare questa mossa.
Facilità di installazione: è tutto gestito da GitHub
Il primo e più importante punto di forza delle azioni GitHub su Jenkins, a mio parere, è la facilità di installazione in GitHub Actions. Le azioni di GitHub operano nel cloud. Hai anche la possibilità di eseguirlo localmente, funzionalità che si chiama runner. Al contrario, Jenkins non dispone di un'offerta di servizi gestiti ufficialmente. E potrei non scegliere alcuna offerta gestita da terze parti per Jenkins. Ritengo che sia troppo rischioso cedere l'accesso al codice sorgente e alle informazioni sensibili a un provider di terze parti.
Per questo motivo, il server Jenkins necessita di installazione, mentre GitHub Actions non ne ha bisogno. Di conseguenza, il processo di configurazione è molto conveniente nelle azioni di GitHub. Inoltre, le GitHub Actions sono una serie di docker runs. Richiede solo una docker build e docker run. Questo lo rende molto facile da eseguire ed eseguire il debug.
All'inizio, Jenkins sembra più flessibile delle azioni di GitHub. Jenkins si basa principalmente su account e trigger e si concentra sulle build. Questi non sono conformi agli eventi GitHub. Al contrario, le GitHub Actions coprono un'ampia gamma. Pertanto, c'è un'azione GitHub per ogni evento GitHub.
Le azioni di GitHub supportano molti linguaggi e framework e sono anche scritte in YAML. Pertanto, questi possono essere modificati, riutilizzati, condivisi proprio come il codice. È semplice da usare con GitHub perché quando esegui il fork di un repository, le azioni vengono automaticamente duplicate con fork.
Ciò consente di testare e creare progetti in modo molto efficiente e persino di eseguirli più vicino allo sviluppatore. Inoltre, hai un accesso immediatamente disponibile all'API GitHub, rendendola più popolare tra gli sviluppatori.
Un caso d'uso popolare di un'integrazione così stretta può essere visto quando si usa Bit (Github). Bit è uno strumento e una piattaforma che semplifica la condivisione di componenti JS (Node, React, Vue, Angular, ecc.) Da qualsiasi repository al servizio cloud di Bit e da lì ad altri repository.
Il servizio cloud di Bit può generare automaticamente richieste pull a tutti i repository Github interessati da una modifica apportata a un componente condiviso. Questi PR generati automaticamente possono fungere da trigger per le azioni GitHub. Tutto ciò significa che una modifica apportata a un singolo componente (condiviso) può propagarsi in tutti i repository che lo utilizzano , attivando CI che convalidano che nulla sia stato corroto in tutti i progetti
Un'altra grande "caratteristica" delle GitHub Actions è che possono essere condivise tra loro tramite GitHub Marketplace. Potresti riutilizzare le azioni scritte da altri sviluppatori, il che potrebbe farti risparmiare molto tempo ed evitare di riscrivere il codice già disponibile.
Le GitHub Actions per impostazione predefinita seguono il modello master-slave (coordinatore e nodi di compilazione) in contrasto con la pipeline sequenziale che Jenkins ci offre.
Tuttavia, è importante notare che una configurazione simile è possibile con Jenkins, ma richiederà ulteriori sforzi e conoscenze per renderlo operativo.
Se utilizzi Jenkins, la configurazione predefinita eseguirà ogni passaggio della pipeline di distribuzione in modo sincrono. Ad esempio, se è necessario eseguire test unitari, test di integrazione e alcune verifiche sonar, dovranno essere eseguiti in un unico ambiente server. Potrebbe ritardare le esecuzioni in base alle risorse disponibili nel tuo server. Inoltre, non dovrai compiere ulteriori sforzi per rendere affidabili le condutture.
Con l'uso di GitHub Actions, queste possono essere parallelizzate.
Abbiamo esaminato criticamente alcune aree in cui le azioni di GitHub precedono Jenkins per quanto riguarda i loro vantaggi. Inoltre, le azioni GitHub stanno crescendo più velocemente di Jenkins, dove migliaia di azioni GitHub vengono rilasciate sul mercato GitHub. La comunità attorno a questo sta anche migliorando dove ci sono repository dedicati per le azioni GitHub. Cosa significa?
Fonte: bitsrc.io
