Continuous Deployment con GitHub Actions (su server condiviso)

Continuous Deployment con GitHub Actions

By on Sun Oct 24 in Continuous Deployment, GitHub Actions, Programming


5
(1)

Introduzione

Tempo fa ho avuto la necessitá di implementare un sistema di Continuous Deployment con GitHub Actions per un progetto personale. A livello enterprise, e lavorando in team, ho usato diversi servizi come per esempio Team City, che è una soluzione CI/CD che permette la massima flessibilità per tutti i tipi di flussi di lavoro e pratiche di sviluppo.

In locale invece, e come sviluppatore solitario, inizialmente non facevo altro che caricare su server i file modificati, via FTP. Dinosaur style!

Alcune note: uso Docker per lo sviluppo in locale per essere in grado di replicare lo stesso ambiente di produzione. Github invece mi permette di tracciare i cambiamenti apportati al codice e lavorare in isolamento usando i feature branch. Per completare il quadro, il progetto personale é basato su Laravel 6, ed é ospitato su un server condiviso.

Deploy in produzione con Github Actions

Ad un certo punto, per quanto il progetto sia personale e le modifiche siano poche, trovo sempre interessante imparare ad utilizzare nuovi servizi e Github Actions era quello che mi serviva perché giá usavo Github e anche perché é uno strumento gratuito.

Le GitHub Actions aiutano ad automatizzare attivitá come il deploy durante il ciclo di vita di sviluppo del tuo software. Le GitHub Actions sono guidate dagli eventi, il che significa che puoi eseguire una serie di comandi dopo che si è verificato un evento specifico. Per esempio, ogni volta che qualcuno crea una pull request per un repository, puoi eseguire automaticamente un comando che esegue uno script di test del software o appunto, come interessa a noi in questo articolo, un deploy automatico dei file modificati sul server.

Vediamo ora come configurare le Github Actions.

Come configurare Github Actions per un deploy automatico via FTP

Se come me, avete un server condiviso, potete seguire la mia configurazione e il risultato sará quello di configurare un deploy automatico via FTP, ogni volta che una Pull Request viene approvata e viene fatto il merge del feature branch con il master branch (o main branch).

Sul marketplace di Github, nella sezione Actions, possiamo trovare lo strumento, gratuito, che fa per noi: FTP Deploy che serve appunto per automatizzare il deploy di siti web e web app.

Possiamo dire che ci sono due pre-requisiti da rispettare:
– avere l’accesso FTP al proprio server. Se il vostro server invece richiede un accesso con chiave SSH, allora questo non é lo strumento che fa per voi;
– il vostro progetto su Github deve rispecchiare l’esatta struttura del progetto su server, quindi non va bene se avete per esempio salvato su Github anche l’infrastruttura Docker, con all’interno il vostro progetto, e che non esiste su server.

Il file di Workflows

Per prima cosa dobbiamo creare una nuova directory all’interno del nostro progetto, chiamata .github e all’interno di quest’ultima, crearne un’altra chiamata workflows. A questo punto possiamo creare un nuovo file chiamato main.yml all’interno di /.github/workflows/ e incollare questo codice all’interno del file appena creato:

# This is a basic workflow to help you get started with Actions

name: 🚀 Automatic YOUR-PROJECT Deploy on pull_request

on:
  pull_request:
    branches: 
      - master
      - main
    types: [closed]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  web-deploy:
    name: 🎉 Deploy
    runs-on: ubuntu-latest
    steps:
    - name: 🚚 Get latest code
      uses: actions/[email protected]

    - name: 📂 Sync files
      uses: SamKirkland/[email protected]
      with:
        server: YOUR-PROJECT-FTP-HOST
        username: YOUR-PROJECT-FTP-USERNAME
        password: ${{ secrets.FTP_PASSWORD }}
        server-dir: YOUR-PROJECT-FTP-DIRECTORY

Prima di tutto modificare tutti i placeholder con i vostri valori di progetto: YOUR-PROJECT, YOUR-PROJECT-FTP-HOST, YOUR-PROJECT-FTP-USERNAME, YOUR-PROJECT-FTP-DIRECTORY.

Ora bisogna aggiungere una chiave alla sezione secrets del tuo progetto. Per aggiungere una password segreta é necessario cliccare sulla tab Settings del progetto e selezionare la voce Secrets. Aggiungere quindi una nuova stringa segreta per la password cliccando in alto a destra “New repository secret”. Usiamo FTP_PASSWORD come nome per valore e inseriamo la password del proprio server FTP nell’area di testo corrispondente al valore della nostra nuova stringa segreta.

Salvare, poi con git aggiungiamo il nuovo file /.github/workflows/main.yml e facciamo un commit e un push per salvare il nuovo file sul repository remoto:

git add .
git commit -m "Added github actions workflow"
git push

In questo caso é possibile lavorare sul branch principale, master o main.

Prima sincronizzazione

A questo punto torniamo sul nostro repository Github e clicchiamo sulla tab Actions. A sinistra, sotto la voce “All workflows”, dovremmo trovare il nostro nuovo workflow, e cliccandoci sopra entreremo nella pagina di riepilogo del workflow. Potremo vedere quante volte é stato eseguito (per ora zero volte).

Per questa prima volta eseguiamolo manualmente, cosí che il workflow sincronizzerá il progetto. Il risultato é la creazione automatica di due file:

  • .ftp-deploy-sync-state.json
  • .gitattributes

Il primo é un file di indice che indicherá al workflow quali file sono contenuti all’interno del vostro progetto, ed è usato per tenere traccia di quali file sono stati sincronizzati nella distribuzione più recente. Se si elimina questo file sarà necessario effettuare una risincronizzazione. Nel secondo file vengono salvate alcun e informazioni necessario al workflow. Se avete un progetto WordPress la prima esecuzione ci metterá parecchio tempo per finire, anche fino a un’ora, perché i file in un progetto del genere sono migliaia.

Pull request e deploy automatico

Una volta finita la sincronizzazione, possiamo testare la nostra nuova Action per controllare il nostro sistema di Continuous Deployment con GitHub Actions.

Creiamo un nuovo branch, chiamato autodeploy:

git checkout -b autodeploy

Ora apriamo il file README del progetto, e aggiungiamo la seguente riga in fondo al file:

Automatic YOUR-PROJECT deployed on pull_request with FTP Deploy and Github Action.

Sostituire il placeholder YOUR-PROJECT con il nome del progetto in questione.

Possiamo quindi aggiungere il file al repository, lanciando un comando di commit e un push:

git add .\readme.html
git commit -m "Readme updated"
git push --set-upstream origin autodeploy

Ora andiamo su Github e creiamo una pull request:

Setup Continuous Delivery - Github Actions compare and pull request
Setup Continuous Delivery – Github Actions compare and pull request

Una volta creata, possiamo cliccare su Merge pull request e Confirm merge per fondere il nostro feature branch autodeploy con il branch master (o main). Possiamo quindi cliccare su Delete branch perché autodeploy non ci servirá piú. È possibile cancellare anche il branch in locale, ecco i comandi da utilizzare nel terminale:

git checkout master
git pull
git branch -d autodeploy

In questo modo ci siamo spostati sul branch master, lo abbiamo aggiornato con le ultime modifiche dovute al merge, e abbiamo cancellato il feature branch autodeploy in locale.

Se ora torniamo sul nostro repository Github e clicchiamo sulla tab Actions, possiamo vedere che il nostro workflows Readme updated é stato eseguito in quanto ha la spunta verde!

Setup Continuous Delivery - Github Actions workflow run successfully
Setup Continuous Delivery – Github Actions workflow run successfully

Possiamo controllare il file Readme, via browser o scaricandono via FTP, e vedere come automaticamente é stata aggiunta la nuova riga che abbiamo inserito senza il nostro intervento manuale di upload del file via FTP.

Conclusione

Grazie all’implementazione di questo sistema di Continuous Deployment con GitHub Actions e FTP Deploy, d’ora in poi non sarà più necessario caricare i file uno ad uno via FTP, ma dopo avere fatto le nostre modifiche in locale, in isolamento all’interno di un feature branch, sarà sufficiente creare una pull request e quando questa sarà chiusa, le modifiche verranno automaticamente caricate su server. Sicuramente un bel risparmio di tempo.

Se hai trovato questo articolo interessante o, ancora meglio, ti ha aiutato con il tuo flusso di lavoro, valuta l’articolo cliccando sulle stelle. Se hai dubbi o domande, scrivimi attravero il form dei contatti.

Buon lavoro!

How useful was this post?

Click on a star to rate it!

Average rating 5 / 5. Vote count: 1

No votes so far! Be the first to rate this post.

Leave a Reply

Your email address will not be published.

Comments

  1. Bella storia! Questaa non la sapevo, uso le actions nella estensione di plesk gir enable, x fare fare deploy auto da locale con git push su dev e master dopo merge ma ignoravo farlo con ftp! Grazie!