{"id":1490,"date":"2021-10-24T14:59:41","date_gmt":"2021-10-24T14:59:41","guid":{"rendered":"https:\/\/www.giuseppemaccario.com\/it\/?p=1490"},"modified":"2026-10-17T21:11:46","modified_gmt":"2026-10-17T21:11:46","slug":"continuous-deployment-con-github-actions-su-server-condiviso","status":"publish","type":"post","link":"https:\/\/www.giuseppemaccario.com\/it\/continuous-deployment-con-github-actions-su-server-condiviso\/","title":{"rendered":"Continuous Deployment con GitHub Actions (su server condiviso)"},"content":{"rendered":"\n

Introduzione<\/h2>\n\n\n\n

Tempo fa ho avuto la necessit\u00e1 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 \u00e8 una soluzione CI\/CD che permette la massima flessibilit\u00e0 per tutti i tipi di flussi di lavoro e pratiche di sviluppo.<\/p>\n\n\n\n

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

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 \u00e9 basato su Laravel 6, ed \u00e9 ospitato su un server condiviso.<\/p>\n\n\n\n

Deploy in produzione con Github Actions<\/h2>\n\n\n\n

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<\/a> era quello che mi serviva perch\u00e9 gi\u00e1 usavo Github e anche perch\u00e9 \u00e9 uno strumento gratuito.<\/p>\n\n\n\n

Le GitHub Actions aiutano ad automatizzare attivit\u00e1 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 \u00e8 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.<\/p>\n\n\n\n

Vediamo ora come configurare le Github Actions.<\/p>\n\n\n\n

Come configurare Github Actions per un deploy automatico via FTP<\/h2>\n\n\n\n

Se come me, avete un server condiviso, potete seguire la mia configurazione e il risultato sar\u00e1 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).<\/p>\n\n\n\n

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

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<\/em> \u00e9 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.<\/p>\n\n\n\n

Il file di Workflows<\/h2>\n\n\n\n

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

# This is a basic workflow to help you get started with Actions\n\nname: \ud83d\ude80 Automatic YOUR-PROJECT Deploy on pull_request\n\non:\n  pull_request:\n    branches: \n      - master\n      - main\n    types: [closed]\n\n  # Allows you to run this workflow manually from the Actions tab\n  workflow_dispatch:\n\n# A workflow run is made up of one or more jobs that can run sequentially or in parallel\njobs:\n  web-deploy:\n    name: \ud83c\udf89 Deploy\n    runs-on: ubuntu-latest\n    steps:\n    - name: \ud83d\ude9a Get latest code\n      uses: actions\/checkout@v2\n\n    - name: \ud83d\udcc2 Sync files\n      uses: SamKirkland\/FTP-Deploy-Action@4.1.0\n      with:\n        server: YOUR-PROJECT-FTP-HOST\n        username: YOUR-PROJECT-FTP-USERNAME\n        password: ${{ secrets.FTP_PASSWORD }}\n        server-dir: YOUR-PROJECT-FTP-DIRECTORY<\/code><\/pre>\n\n\n\n
Prima di tutto modificare tutti<\/em> i placeholder con i vostri valori di progetto: YOUR-PROJECT, YOUR-PROJECT-FTP-HOST, YOUR-PROJECT-FTP-USERNAME, YOUR-PROJECT-FTP-DIRECTORY.<\/p>\n\n\n\n
Ora bisogna aggiungere una chiave alla sezione secrets del tuo progetto. Per aggiungere una password segreta \u00e9 necessario cliccare sulla tab Settings del progetto e selezionare la voce Secrets<\/em>. 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.<\/p>\n\n\n\n
Salvare, poi con git aggiungiamo il nuovo file \/.github\/workflows\/main.yml<\/em> e facciamo un commit e un push per salvare il nuovo file sul repository remoto:<\/p>\n\n\n\n
git add .\ngit commit -m \"Added github actions workflow\"\ngit push<\/code><\/pre>\n\n\n\n
In questo caso \u00e9 possibile lavorare sul branch principale, master o main.<\/p>\n\n\n\n
Prima sincronizzazione<\/h2>\n\n\n\n
A questo punto torniamo sul nostro repository Github e clicchiamo sulla tab Actions<\/em>. 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 \u00e9 stato eseguito (per ora zero volte).<\/p>\n\n\n\n
Per questa prima volta eseguiamolo manualmente, cos\u00ed che il workflow sincronizzer\u00e1 il progetto. Il risultato \u00e9 la creazione automatica di due file:<\/p>\n\n\n\n