Indietro

Prossima

In che modo GitHub Actions consente di automatizzare le attività di sviluppo?

Completato

In questo modulo verranno introdotti GitHub Actions e i flussi di lavoro. Verranno specificate informazioni sui tipi di azioni che è possibile usare e su dove trovarle. Verranno anche esaminati esempi di questi tipi di azioni e il modo in cui operano in un flusso di lavoro.

Con GitHub viene ridotto il tempo dall'idea iniziale alla distribuzione

GitHub è progettato per aiutare i team di sviluppatori e tecnici DevOps a creare e distribuire rapidamente le applicazioni. A questo scopo GitHub include molte funzionalità, che in genere rientrano in una delle due categorie seguenti:

• Comunicazione: tenere presenti tutti i modi in cui GitHub semplifica la comunicazione di un team di sviluppatori sul progetto di sviluppo del software, ad esempio revisioni del codice nelle richieste pull, problemi di GitHub, bacheche dei progetti, wiki, notifiche e così via.
• Automazione: GitHub Actions consente al team di automatizzare i flussi di lavoro in ogni passaggio del processo di sviluppo software, dall'integrazione alla distribuzione. Consente inoltre di automatizzare l'aggiunta di etichette alle richieste pull e il controllo di eventuali problemi di aggiornamento e delle richieste pull.

Usate in combinazione, queste funzionalità hanno consentito a migliaia di team di sviluppo di ridurre in modo efficace il tempo necessario dall'idea iniziale alla distribuzione.

Usare l'automazione del flusso di lavoro per ridurre i tempi di sviluppo

Questo modulo è incentrato sull'automazione, quindi verrà dedicato tempo alla comprensione del modo in cui i team possono usare l'automazione per ridurre il tempo necessario per completare un flusso di lavoro tipico per lo sviluppo e la distribuzione.

Tenere presenti tutte le attività che devono essere eseguite dopo che il codice è stato scritto ma prima che possa essere usato in modo affidabile per lo scopo previsto. A seconda degli obiettivi dell'organizzazione, sarà probabilmente necessario eseguire una o più delle attività seguenti:

• Assicurarsi che il codice superi tutti gli unit test
• Eseguire controlli di conformità e qualità del codice per verificare che il codice sorgente soddisfi gli standard dell'organizzazione
• Controllare il codice e le relative dipendenze per individuare eventuali problemi di sicurezza noti
• Compilare il codice integrando la nuova origine da più collaboratori, ove possibile
• Verificare che il software superi i test di integrazione
• Assegnare la versione alla nuova build
• Inviare i nuovi file binari al percorso del file system appropriato
• Distribuire i nuovi file binari in uno o più server
• Se una di queste attività non riesce, segnalare il problema all'utente o al team appropriato per la risoluzione

La sfida consiste nell'eseguire queste attività in modo affidabile, coerente e sostenibile. Si tratta di un processo ideale per l'automazione dei flussi di lavoro. Se si usa già GitHub, è probabile che si voglia configurare l'automazione del flusso di lavoro con GitHub Actions.

Che cosa sono le azioni di GitHub Actions?

Le azioni di GitHub Actions sono script pacchettizzati per automatizzare attività all'interno di un flusso di lavoro di sviluppo software in GitHub. È possibile configurare GitHub Actions per attivare flussi di lavoro complessi che soddisfano le esigenze dell'organizzazione ogni volta che gli sviluppatori controllano il nuovo codice sorgente in un ramo specifico, a intervalli prestabiliti o manualmente. Il risultato è un flusso di lavoro automatizzato affidabile e sostenibile con una riduzione significativa dei tempi di sviluppo.

Dove trovare GitHub Actions?

GitHub Actions sono script conformi al formato di dati yml. Ogni repository include una scheda Actions (Azioni) che offre un modo semplice e rapido per iniziare a configurare il primo script. Se viene visualizzato un flusso di lavoro che si ritiene possa essere un ottimo punto di partenza, è sufficiente selezionare il pulsante di configurazione per aggiungere lo script e iniziare a modificare il file yml di origine.

Tuttavia, oltre alle azioni di GitHub Actions disponibili nella scheda Actions (Azioni), è possibile:

• Cercare GitHub Actions nel marketplace GitHub. Nel marketplace GitHub si possono trovare e acquistare strumenti per l'estensione del flusso di lavoro.
• Cercare progetti open source. Ad esempio, l'organizzazione GitHub Actions offre molti repository open source popolari contenenti azioni di GitHub Actions utilizzabili.
• Scrivere da zero le proprie GitHub Actions. Se si vuole, è anche possibile renderle open source e persino pubblicarle nel marketplace GitHub.

Uso di GitHub Actions open source

Molte funzionalità di GitHub Actions sono open source e disponibili per chiunque voglia usarle. Come per qualsiasi software open source, tuttavia, è necessario verificarle attentamente prima di usarle nel progetto. Analogamente agli standard della community consigliati per gli altri software open source, come l'inserimento di un file Leggimi, di un codice di condotta, di un file dei contributi e di modelli di problemi, è possibile seguire le raccomandazioni seguenti quando si usa GitHub Actions:

• Controllare il file action.yml dell'azione per gli input e gli output e per verificare che il codice consenta effettivamente di eseguire le azioni previste.
• Verificare che l'azione si trovi nel Marketplace GitHub. Si tratta di un controllo molto utile anche se un'azione non deve essere necessariamente presente nel Marketplace GitHub per essere valida.
• Controllare che l'azione sia verificata nel Marketplace GitHub. Questo significa infatti che GitHub ha approvato l'uso dell'azione. Prima di usarla, tuttavia, è sempre necessario controllarla.
• Includere la versione dell'azione in uso specificando un riferimento Git, un SHA o un tag.

Tipi di azioni di GitHub

Esistono tre tipi di azioni GitHub: azioni contenitore, azioni JavaScript e azioni composite.

Con le azioni del contenitore, l'ambiente fa parte del codice dell'azione. Queste azioni possono essere eseguite solo in un ambiente Linux ospitato da GitHub. Le azioni del contenitore supportano molti linguaggi diversi.

Le azioni JavaScript non includono l'ambiente nel codice. Per eseguire queste azioni, è necessario specificare l'ambiente. L'esecuzione di queste azioni può avvenire in una VM nel cloud o in locale. Le azioni JavaScript supportano ambienti Linux, macOS e Windows.

Le azioni composte consentono di combinare più passaggi del flusso di lavoro all'interno di un'azione. Ad esempio, puoi usare questa funzionalità per raggruppare più comandi di esecuzione in un'azione e quindi avere un flusso di lavoro che esegue i comandi in bundle come singolo passaggio usando tale azione.

Anatomia di un'azione GitHub

Di seguito è riportato un esempio di azione che esegue il comando git checkout di un repository. Questa azione, actions/checkout@v1, è parte di un passaggio in un flusso di lavoro. Questo passaggio compila anche il codice Node.js di cui è stato eseguito il checkout. Flussi di lavoro, processi e passaggi verranno illustrati nella sezione successiva.

steps:
  - uses: actions/checkout@v1
  - name: npm install and build webpack
    run: |
      npm install
      npm run build

Si supponga di voler usare un'azione del contenitore per eseguire il codice incluso in un contenitore. L'azione sarà come segue:

name: "Hello Actions"
description: "Greet someone"
author: "octocat@github.com"

inputs:
    MY_NAME:
      description: "Who to greet"
      required: true
      default: "World"

runs:
    uses: "docker"
    image: "Dockerfile"

branding:
    icon: "mic"
    color: "purple"

Si noti la sezione inputs. Qui si ottiene il valore della variabile denominata MY_NAME. Questa variabile verrà impostata nel flusso di lavoro che esegue l'azione.

Nella sezione runs si noti che nell'attributo uses viene specificato docker. Quando si esegue questa operazione, è necessario specificare il percorso del file di immagine Docker, in questo caso denominato Dockerfile. In questo articolo non verranno analizzate le specifiche di Docker ma, per altre informazioni, vedere il modulo Introduzione ai contenitori Docker.

L'ultima sezione, relativa alla personalizzazione, illustra come personalizzare l'azione nel Marketplace GitHub se si decide di pubblicarla.

È possibile trovare un elenco completo dei metadati delle azioni in Sintassi dei metadati per le azioni di GitHub Actions.

Che cos'è un flusso di lavoro di GitHub Actions?

Un flusso di lavoro di GitHub Actions è un processo configurato nel repository per automatizzare le attività del ciclo di vita dello sviluppo software, comprese le azioni di GitHub Actions. Con un flusso di lavoro è possibile compilare, testare, aggiungere a un pacchetto, rilasciare e distribuire qualsiasi progetto in GitHub.

Per creare un flusso di lavoro, è possibile aggiungere azioni a un file con estensione yml nella directory .github/workflows del repository GitHub.

Nel prossimo esercizio il file del flusso di lavoro, main.yml, sarà simile al seguente:

name: A workflow for my Hello World file
on: push
jobs:
  build:
    name: Hello world action
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: ./action-a
      with:
        MY_NAME: "Mona"

Osservare l'attributo on:. Si tratta di un trigger per specificare quando verrà eseguito il flusso di lavoro. In questo caso attiva un'esecuzione quando è presente un evento push nel repository. È possibile specificare singoli eventi come on: push, una matrice di eventi come on: [push, pull_request] o una mappa di configurazione di eventi che pianifica un flusso di lavoro o limita l'esecuzione di un flusso di lavoro a file, modifiche del ramo o tag specifici. Tale mappa sarà simile alla seguente:

on:
  # Trigger the workflow on push or pull request,
  # but only for the main branch
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  # Also trigger on page_build, as well as release created events
  page_build:
  release:
    types: # This configuration does not affect the page_build event above
      - created

Un evento viene attivato su tutti i tipi di attività per l'evento, a meno che non si specifichino solo alcuni tipi. Per un elenco completo degli eventi e dei relativi tipi di attività, vedere: Eventi che attivano i flussi di lavoro nella documentazione di GitHub.

È necessario che un flusso di lavoro includa almeno un processo. Un processo è una sezione del flusso di lavoro associata a uno strumento di esecuzione. Uno strumento di esecuzione può essere ospitato in GitHub o self-hosted e il processo può essere eseguito in un computer o in un contenitore. Lo strumento di esecuzione viene specificato con l'attributo runs-on:. In questo caso si indica al flusso di lavoro di eseguire il processo in ubuntu-latest.

Ogni processo prevede passaggi da completare. In questo esempio il passaggio usa l'azione actions/checkout@v1 per estrarre il repository. È interessante notare il valore uses: ./action-a, ovvero il percorso per l'azione contenitore creata in un file action.yml. I contenuti del file action.yml sono stati esaminati nella sezione Che cos'è GitHub Actions?.

Nell'ultima parte di questo file del flusso di lavoro viene impostato il valore della variabile MY_NAME per il flusso di lavoro. Ricordare che l'azione del contenitore ha accettato un input denominato MY_NAME.

Per altre informazioni sull'esecuzione del checkout della sintassi del flusso di lavoro, vedere Sintassi del flusso di lavoro per GitHub Actions

Strumenti di esecuzione self-hosted e ospitati da GitHub

È stato brevemente accennato di come gli strumenti di esecuzione siano associati a un processo. Uno strumento di esecuzione non è altro che un server in cui è installata l'applicazione dello strumento di esecuzione GitHub Actions. Nell'esempio precedente del flusso di lavoro era presente un attributo runs-on: ubuntu-latest all'interno del blocco jobs, che indicava al flusso di lavoro che il processo verrà eseguito usando il runner ospitato da GitHub in esecuzione nell'ambiente ubuntu-latest.

Quando si tratta di strumenti di esecuzione, sono disponibili due opzioni tra cui scegliere: Strumenti di esecuzione ospitati da GitHub e strumenti di esecuzione self-hosted. Se si usa uno strumento di esecuzione ospitato da GitHub, ogni processo viene eseguito in una nuova istanza di un ambiente virtuale specificata dal tipo di strumento di esecuzione ospitato da GitHub definito dall'utente: runs-on: {operating system-version}. Con gli strumenti di esecuzione self-hosted, è necessario invece applicare l'etichetta self-hosted e specificare il sistema operativo e l'architettura di sistema. Uno strumento di esecuzione indipendente con un sistema operativo Linux e un'architettura ARM32, ad esempio, avrà un aspetto simile al seguente: runs-on: [self-hosted, linux, ARM32].

Ogni tipo di strumenti di esecuzione presenta dei vantaggi ma quelli ospitati da GitHub offrono un modo più semplice e rapido di eseguire i flussi di lavoro, seppur con opzioni limitate. Gli strumenti di esecuzione self-hosted rappresentano invece una soluzione altamente configurabile con cui eseguire i flussi di lavoro nell'ambiente locale personalizzato. Gli strumenti di esecuzione self-hosted possono essere eseguiti in locale o nel cloud. Possono essere usati anche per creare una configurazione hardware personalizzata con una maggiore capacità di elaborazione o di memoria per l'esecuzione di processi più grandi, per installare applicazioni software nella rete locale o per scegliere un sistema operativo non disponibile con gli strumenti di esecuzione ospitati da GitHub.

GitHub Actions può avere alcuni limiti di utilizzo

L'utilizzo di GitHub Actions presenta alcuni limiti a seconda che lo strumento di esecuzione sia ospitato da GitHub o self-hosted e in base al piano GitHub. Per altre informazioni sui limiti d'uso, vedere Limiti d'uso, fatturazione e amministrazione nella documentazione di GitHub.

Continua