Il vostro progetto è ora su un sistema di controllo dei sorgenti. Ciò significa che la gestione di diverse versioni del vostro software, il monitoraggio delle modifiche e l’integrazione di correzioni o nuove funzionalità sono ora molto più semplici.
Perché non sfruttare anche l’integrazione continua?
A partire da 4D v19, è possibile avviare la compilazione del progetto con un comando. Di conseguenza, ora disponete di tutti gli elementi necessari per automatizzare la vostra catena di integrazione.
Questo post vi fornirà un esempio di automazione con il GitHub manager e le GitHub Actions.
Che cos’è un’azione GitHub?
Le azioni GitHub consentono di automatizzare le attività. Vengono attivate da eventi come l’invio di codice.
Perché le azioni GitHub?
L’automazione del flusso di lavoro è un requisito fondamentale nel mondo dello sviluppo del software di oggi. I team di sviluppo utilizzano server CI/CD per automatizzare i processi di integrazione e distribuzione continua (CI/CD) nel ciclo di vita del software.
Le azioni GitHub consentono agli utenti di costruire, testare e distribuire il proprio codice direttamente da GitHub senza utilizzare un server esterno come Jenkins o TeamCity. GitHub ospita macchine virtuali sui sistemi operativi Linux, Windows e macOS.
Come utilizzare le Azioni GitHub?
È necessario creare un flusso di lavoro. Un flusso di lavoro è una procedura automatizzata che si aggiunge al repository. Nella scheda Azione, è possibile sceglierne uno dal catalogo dei flussi di lavoro o crearne uno proprio.
In questo esempio, utilizziamo il “flusso di lavoro semplice” proposto da Github:
Questo ha creato uno script nella cartella “.github/workflows” del nostro repository. In questo script, è possibile definire
- l’evento di attivazione: su push/pull/schedule
- il sistema operativo della macchina virtuale:runs-on
- …
Per maggiori dettagli sulle sintassi e sulle possibilità, consultare la documentazione di GitHub.
Successivamente, modifichiamo il file README.md nel nostro repository, che attiva il flusso di lavoro. Nella scheda azione, la modifica è visibile, il flusso di lavoro è in coda:
Voilà! Lo script è stato eseguito.
Ora abbiamo accesso alle informazioni sul sistema operativo e sulla macchina virtuale utilizzata, verificando se corrisponde alla configurazione richiesta.
Tutti i log del nostro script sono ora visibili:
Esempio concreto
Ora che abbiamo visto come creare e impostare le azioni GitHub, ecco un flusso di lavoro creato da Eric Marchand.
Eric è uno degli sviluppatori del team 4D per iOS. Ha sviluppato diverse azioni git per uso personale, utilizzate su un server GitLab per i nostri repository privati e su GitHub per quelli pubblici.
Ecco un esempio di come compilare un progetto e pubblicare il rilascio su GitHub:
Innanzitutto, abbiamo un progetto 4D con codice condiviso che compila altri progetti passati come parametri durante il lancio (con uno script bash su macOS runner). Questo progetto converte gli errori di compilazione in formato log di GitHub. È memorizzato in un repository Github contenente azioni come la compilazione, la generazione di un rilascio, ecc. Queste azioni possono essere utilizzate in qualsiasi altro progetto.
In secondo luogo, per eseguire il progetto e quindi richiamare un’azione come la compilazione, è necessario eseguire un’applicazione 4D. Un’applicazione 4D è disponibile per il download su un server. Deve essere installata ed eseguita sui server GitHub. È necessario aggiungere la chiave SERVER_URL nel parametro“Action Secret” del repository per ogni progetto.
Infine, si creano flussi di lavoro attivati da una richiesta di pull nei progetti, che richiama il flusso di lavoro “build” del repository “azione centralizzata”.
Trovate il repository con la base e i diversi flussi di lavoro e un esempio di integrazione in un progetto.
Fateci sapere cosa ne pensate unendovi alla conversazione sul Forum 4D!