GitHub Actions è una piattaforma CI/CD che consente agli sviluppatori di creare, testare e distribuire automaticamente tutte le applicazioni su GitHub, senza utilizzare strumenti esterni. Con quanto è facile da usare, hai anche bisogno di un server di build esterno?
CI/CD è il processo di creazione e distribuzione automatica delle applicazioni, in genere tramite una “pipeline di compilazione” automatizzata che prende il tuo codice, esegue lo script di compilazione e lo distribuisce dove deve andare. Le pipeline di compilazione sono generalmente gestite da software server di compilazione esterni come TeamCity, Travis CI o Jenkins, che sono strumenti standard del settore per la gestione di tutto ciò che riguarda CI/CD.
Tuttavia, sono generalmente complicati da configurare, che è dove Azioni GitHub offre un’alternativa per i programmatori di tutti i giorni. È molto più semplice e spesso gratuito per la maggior parte degli utenti e, nonostante sia uno strumento gratuito, resiste alle soluzioni proprietarie, soprattutto con i recenti aggiornamenti e il supporto della community.
La configurazione con un clic e la facilità d’uso di GitHub Actions lo rendono un ottimo strumento entry-level per l’apprendimento dell’automazione della build, soprattutto perché non devi configurare tu stesso tutta l’infrastruttura per iniziare e non hai bisogno del tuo propri server in esecuzione 24 ore su 24, 7 giorni su 7 per gestire le build.
La maggior parte dei tipi di applicazioni avrà modelli già creati, il che significa che la creazione automatica dell’applicazione è in genere semplice come fare clic sulla scheda “Azioni” nel repository e configurare un modello predefinito. GitHub può persino consigliartene uno in base alla tua base di codice:
Puoi anche scrivere i tuoi file di configurazione YAML, che sono in grado di utilizzare qualsiasi strumento e contenitore Docker disponibile per creare qualsiasi applicazione, sia su Windows che su Linux. Questi possono eseguire qualsiasi tipo di script desiderato, inclusi gli script Bash/PowerShell che si trovano nel tuo repository.
Una delle migliori funzionalità di GitHub Actions è il mercato della comunità, che funziona come un gestore di pacchetti per gli strumenti spesso utilizzati negli script di compilazione. Questi possono farti risparmiare un sacco di tempo che verrebbe speso tu stesso per l’automazione degli script. Ad esempio, una tattica di distribuzione comune consiste nel caricare gli artefatti della build in un bucket di archiviazione Amazon S3 e sul mercato sono disponibili molti strumenti che possono farlo per te.
Utilizzando il marketplace, GitHub Actions può fare praticamente tutto ciò che possono fare altre soluzioni autonome, solo con un piccolo sforzo manuale in più. Dopotutto, esegue solo script di base su un sistema Linux o Windows.
Ad esempio, strumenti come Jenkins offrono l’integrazione con software di gestione dei problemi come Jira o Trello o integrazioni di registrazione con Slack. Questi sono integrati nel software e facili da configurare e sono ottimi punti di forza dei sistemi di compilazione autonomi. Tuttavia, GitHub Actions può anche essere configurato per fare tutte queste cose configurando strumenti dal marketplace.
Uno dei maggiori svantaggi di GitHub Actions è la struttura dei prezzi. Ogni account o organizzazione GitHub ha un determinato numero di minuti del server di compilazione condivisi tra tutti i repository. Ogni minuto che un server GitHub impiega per eseguire la tua build utilizza minuti da questo bucket. Il livello gratuito è di 2000 minuti, o la metà di quello per Windows, che è ancora più che sufficiente per la maggior parte degli utenti occasionali.
Puoi pagare di più per GitHub Pro, Team o Enterprise per più minuti, ma puoi anche aggirare del tutto questo problema fornendo il tuo corridore autonomo. Se hai un server aggiuntivo in giro, puoi configurarlo abbastanza rapidamente per accettare le attività di GitHub Actions. A seconda delle prestazioni di quel server, potrebbe anche essere significativamente più veloce dell’hosting condiviso di GitHub Action. Puoi leggere la nostra guida su come configurare i tuoi corridori self-hosted per saperne di più.
Nel complesso, GitHub Actions è fantastico per gli hobbisti e funziona abbastanza bene che la maggior parte dei piccoli team non avrebbe problemi a costruire i propri progetti utilizzando il servizio.
Server di compilazione esterni D’altra parte, un server di compilazione esterno, come Jenkins o TeamCity, di solito fornisce funzionalità più avanzate per la creazione, il test e la distribuzione di applicazioni ed è generalmente preferito da team e aziende più grandi per avere una maggiore flessibilità.
Se il tuo team ha molti progetti, è molto utile disporre di un luogo centralizzato per gestire l’automazione e l’implementazione di tali progetti. Ciò separa le preoccupazioni di ciascun servizio e consente al controllo del codice sorgente di concentrarsi sull’hosting del codice e al server di compilazione sulla sua creazione.
Ad esempio, se desideri gestire gli script di compilazione per molti repository, dovrai farlo dalle impostazioni di ciascun repository. Ma con un server di compilazione, puoi creare gruppi di configurazioni di compilazione che utilizzano tutte lo stesso modello e apportare modifiche al modello. È anche solo più facile vedere cosa sta succedendo con la tua automazione in generale quando hai una bella dashboard
Cruscotto di TeamCity La divisione del sistema di compilazione dal controllo del codice sorgente consente inoltre una maggiore flessibilità nella scelta di strumenti e servizi. Ad esempio, se si desidera utilizzare soluzioni di controllo del codice sorgente alternative come Gitlab o BitBucket, è possibile sostituirle facilmente senza modificare la configurazione del server di compilazione. Con GitHub Actions, sei praticamente bloccato nell’utilizzo di GitHub.
Le soluzioni autonome possono anche utilizzare file di configurazione in stile YAML, ma di solito hanno più funzionalità integrate e offrono un maggiore controllo sui passaggi e sull’automazione. Ad esempio, TeamCity suddivide la build in singoli passaggi, ognuno dei quali può eseguire diversi script, azioni o eseguibili e può essere configurato con maggiore fedeltà rispetto a un semplice file YAML.
Infine, le funzionalità e le integrazioni offerte dalle soluzioni proprietarie sono utili e generalmente piacevoli da avere. Ad esempio, TeamCity offre l’integrazione personalizzata dell’app Slack, che può registrare gli errori di compilazione direttamente nel tuo team.
Nel complesso, se il tuo team ha più progetti e si preoccupa di gestirli in modo efficiente, potrebbe valere la pena esaminare la configurazione del tuo server CI/CD.
Fortunatamente, molte delle buone soluzioni CI/CD sono gratuite o open source. Jenkins è completamente open source, ma richiede il self hosting. Jet Brain Team City è gratuito se sei self-hosting, ma offre anche un servizio cloud a pagamento. Travis C.I è solo a pagamento, ma è un’altra soluzione popolare utilizzata nel settore.
IMPARENTATO: Come costruire un server di build Jenkins
