Lezione 28 di 35

Git 28

🔀 Git & GitHub · Modulo 5 · Lezione 28

CD: deploy automatico 🚀

GitHub Pages · Deploy automatico dopo il merge · Da commit a sito online in un minuto

⏱️ Durata stimata: 60–75 min 📊 Livello: Avanzato (Modulo 5) 🔧 Strumenti: Terminale · GitHub 📋 Prerequisiti: Lezioni 25–27 (workflow, YAML, test CI)

🚀 CI verifica che il codice funziona. CD lo mette online. Con GitHub Pages + GitHub Actions, il tuo sito si pubblica automaticamente ogni volta che fai merge in main. Niente upload manuale via FTP, niente “ho dimenticato di aggiornare il server”. Pusha il codice → il sito è online. Questo è il Continuous Deployment nella sua forma più pura.

🎯 Obiettivi della lezione

  • Capire cos’è GitHub Pages e come funziona
  • Configurare GitHub Pages per il tuo repository
  • Creare un workflow di deploy automatico con GitHub Actions
  • Combinare CI (test) e CD (deploy) in un’unica pipeline
  • Capire il flusso completo: push → test → deploy → sito online

📖 1. Teoria

1.1 — Cos’è GitHub Pages

GitHub Pages è un servizio gratuito di hosting integrato in GitHub. Trasforma un repository in un sito web pubblico accessibile a un URL del tipo tuousername.github.io/nome-repo. Perfetto per siti statici: HTML, CSS, JavaScript.

🆓
Gratuito
Hosting gratuito per repository pubblici. Nessun costo, nessun abbonamento.
🔒
HTTPS automatico
Certificato SSL gratuito. Il tuo sito è sicuro (https) senza configurazione.
⚡
Deploy automatico
Si aggiorna da solo a ogni push. Con Actions, controlli esattamente il processo.
Cosa può ospitare GitHub Pages
✅ Sì
Siti statici: HTML, CSS, JavaScript. Portfolio, documentazione, landing page, blog con Jekyll, siti con framework statici (React build, Vue build, Astro).
❌ No
Applicazioni server-side: PHP, Python Flask/Django, Node.js Express, database. Per queste serve un hosting come Heroku, Vercel, Railway.

1.2 — Due modi per configurare Pages

Modo 1: Deploy da un branch
GitHub pubblica direttamente i file di un branch (es. main). Semplice ma limitato: nessun passo di build, nessun test prima del deploy.
Settings → Pages → Source: “Deploy from a branch” → seleziona main → Save.
Modo 2: Deploy con GitHub Actions ⭐
Un workflow Actions costruisce il sito e lo pubblica. Hai pieno controllo: puoi testare prima, fare build, trasformare file. È il modo consigliato.
Settings → Pages → Source: “GitHub Actions”.

1.3 — Configurare Pages con GitHub Actions

PASSO 1
Repository → Settings → Pages (menu a sinistra).
PASSO 2
In “Build and deployment” → Source: seleziona “GitHub Actions”.
PASSO 3
Crea il workflow di deploy (sezione 1.4). Committa e pusha.
PASSO 4
Dopo il primo deploy: https://tuousername.github.io/nome-repo/

1.4 — Il workflow di deploy per un sito HTML statico

# File: .github/workflows/deploy.yml

name: Deploy su GitHub Pages

on:
push:
branches: [main]

# Permessi necessari per il deploy su Pages
permissions:
contents: read
pages: write
id-token: write

# Un solo deploy alla volta
concurrency:
group: “pages”
cancel-in-progress: false

jobs:
deploy:
runs-on: ubuntu-latest
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
steps:
– name: Checkout
uses: actions/checkout@v4

– name: Configura Pages
uses: actions/configure-pages@v5

– name: Carica artefatto
uses: actions/upload-pages-artifact@v3
with:
path: “.” ← pubblica tutta la cartella

– name: Deploy su GitHub Pages
id: deployment
uses: actions/deploy-pages@v4
Spiegazione delle parti nuove
Chiave Cosa fa
permissions Concede al workflow i permessi per scrivere su Pages. Senza, il deploy fallisce con “403 Forbidden”.
concurrency Se un deploy è in corso e ne arriva un altro, il secondo aspetta. Evita conflitti.
environment Collega il job all’ambiente “github-pages” — GitHub mostra l’URL nella tab Deployments.
configure-pages Prepara l’ambiente Pages sul runner.
upload-pages-artifact Impacchetta i file da pubblicare. path: "." = tutta la cartella del repo.
deploy-pages Pubblica l’artefatto su GitHub Pages. Il sito è online.

📌 Se il tuo progetto ha una cartella dist/ o build/ (perché usi un framework con passo di build), cambia path: "." con path: "dist" (o "build"). Se il progetto è HTML/CSS/JS senza build, path: "." pubblica tutto.

1.5 — La pipeline completa: CI + CD

Il vero potere emerge quando combini test e deploy in un’unica pipeline: prima verifica che il codice funzioni (CI), poi lo pubblica (CD). Se i test falliscono, il deploy non parte.

Pipeline CI/CD completa
1. PUSH su main
Codice arriva su GitHub
2. CI: TEST
Workflow esegue i test
❌ fallito → stop
✅ passato → continua
3. CD: DEPLOY
Pubblica su Pages
(solo se test passati)
4. ONLINE! 🌐
tuousername.github.io
/nome-repo
# File: .github/workflows/ci-cd.yml — Pipeline completa

name: CI/CD

on:
push:
branches: [main]

permissions:
contents: read
pages: write
id-token: write

concurrency:
group: “pages”
cancel-in-progress: false

jobs:
# === JOB 1: TEST (CI) ===
test:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v4
– name: Verifica file essenziali
run: |
for file in index.html style.css; do
test -f “$file” && echo “✅ $file” || (echo “❌ $file mancante” && exit 1)
done
– name: Verifica HTML
run: |
for f in $(find . -name “*.html”); do
grep -qi “doctype” “$f” && echo “✅ $f” || (echo “❌ $f senza DOCTYPE” && exit 1)
done

# === JOB 2: DEPLOY (CD) — solo se test passati ===
deploy:
needs: test
runs-on: ubuntu-latest
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
steps:
– uses: actions/checkout@v4
– uses: actions/configure-pages@v5
– uses: actions/upload-pages-artifact@v3
with:
path: “.”
– name: Deploy
id: deployment
uses: actions/deploy-pages@v4

📌 Il trucco è needs: test. Il job deploy aspetta che test finisca con successo. Se test fallisce, deploy non parte — il sito non viene aggiornato con codice rotto.

1.6 — Verificare il deploy

Actions
Il workflow mostra 2 job: “test” (verde se passato) e “deploy” (verde se pubblicato). Cliccando su deploy, vedi l’URL del sito.
Deployments
Nella sidebar destra del repository appare “Deployments” con link al sito e storia dei deploy.
Settings
In Settings → Pages appare il messaggio “Your site is live at…” con l’URL verde cliccabile.

💻 2. Esempi guidati

Esempio A — Deploy di un sito HTML in 5 minuti

# 1. Assicurati di avere almeno un index.html
$ cat index.html
<!DOCTYPE html>
<html lang=”it”>
<head><title>Il mio sito</title><link rel=”stylesheet” href=”style.css”></head>
<body><h1>Ciao mondo!</h1></body>
</html>

# 2. Configura Pages su GitHub
# Settings → Pages → Source: “GitHub Actions”

# 3. Crea il workflow di deploy
$ mkdir -p .github/workflows
# Copia il contenuto della sezione 1.4 in .github/workflows/deploy.yml

# 4. Committa e pusha
$ git add . && git commit -m “Aggiungo deploy automatico su Pages”
$ git push

# 5. Aspetta ~1 minuto → vai su Actions → job verde
# 6. Apri https://tuousername.github.io/nome-repo/
# 🎉 Il sito è online!

Esempio B — Aggiornare il sito: il deploy continuo

1
Modifica index.html in locale (es. cambia il testo dell’h1).
2
git add . && git commit -m "Aggiornato titolo" && git push
3
Il workflow parte automaticamente. Dopo ~1 minuto, ricarica il sito. Il testo è aggiornato.
4
Questo è il deploy continuo: ogni push su main aggiorna il sito. Nessun passo manuale.

Esempio C — Pubblicare solo una sottocartella

# Se il tuo sito è nella cartella public/ (non alla radice)
📁 progetto/
├── 📁 public/ ← questa va pubblicata
│ ├── index.html
│ └── style.css
├── 📁 src/ ← codice sorgente (non pubblicare)
├── 📁 test/ ← test (non pubblicare)
└── README.md

# Nel workflow, cambia path:
– uses: actions/upload-pages-artifact@v3
with:
path: “public” ← pubblica solo public/

🏋️ 3. Esercizi

🟢 Esercizio 1 — Il tuo primo deploy (Facile)

a) Assicurati di avere un index.html nel repository.
b) Configura Pages: Settings → Pages → Source: “GitHub Actions”.
c) Crea il file .github/workflows/deploy.yml con il contenuto della sezione 1.4.
d) Committa e pusha. Vai sulla tab Actions: il workflow è verde?
e) Apri https://tuousername.github.io/nome-repo/ — il sito è online?
f) Modifica index.html, committa e pusha. Il sito si aggiorna in ~1 minuto?

🔵 Esercizio 2 — Pipeline CI + CD (Medio)

a) Usa il workflow ci-cd.yml della sezione 1.5 (test + deploy).
b) Pusha su main: entrambi i job (test e deploy) passano?
c) Rinomina style.css in styles.css. Committa e pusha. Cosa succede?
d) Il job test fallisce? Il job deploy parte lo stesso? (Non deve partire — needs: test.)
e) Il sito è rimasto con la versione precedente (funzionante)?
f) Correggi, pusha, verifica che tutto torni verde e il sito si aggiorni.

🟠 Esercizio 3 — Deploy con sottocartella (Medio)

a) Riorganizza il progetto: crea una cartella public/ e sposta i file HTML e CSS lì dentro.
b) Modifica il workflow: cambia path: "." in path: "public".
c) Committa e pusha. Il sito mostra i file dalla cartella public?
d) Verifica: file come README.md o test.sh non sono visibili sul sito (non sono in public/).

🟣 Esercizio 4 — Pipeline CI/CD completa per il progetto di classe (Difficile)

Configura la pipeline definitiva per un progetto di gruppo:

a) Job 1 — test-struttura: verifica file essenziali, DOCTYPE, no credenziali.
b) Job 2 — test-codice: se il progetto ha JavaScript, esegui i test con Node.js.
c) Job 3 — deploy: needs: [test-struttura, test-codice]. Pubblica su Pages.
d) Trigger: solo push su main. Le PR attivano solo i test (non il deploy).
e) Aggiungi un job separato che si attiva su pull_request con solo i test (senza deploy).
f) Testa la pipeline: apri una PR con un bug → test falliscono → merge bloccato. Correggi → merge → deploy automatico → sito aggiornato.

❓ 4. Quiz di verifica

1. Cos’è GitHub Pages?

Mostra risposta

Un servizio di hosting gratuito integrato in GitHub che trasforma un repository in un sito web pubblico. Il sito è accessibile a https://tuousername.github.io/nome-repo/. Supporta solo siti statici (HTML, CSS, JavaScript) — non applicazioni server-side. Include HTTPS automatico (certificato SSL gratuito) e si aggiorna automaticamente quando il codice cambia. È perfetto per portfolio, documentazione, landing page e progetti scolastici.

2. Qual è la differenza tra “Deploy from a branch” e “GitHub Actions” come source di Pages?

Mostra risposta

“Deploy from a branch” pubblica direttamente i file di un branch (es. main) così come sono — semplice ma non puoi fare test prima del deploy, né passi di build. “GitHub Actions” usa un workflow per costruire e pubblicare il sito — hai pieno controllo: puoi testare, fare build, trasformare file, e il deploy avviene solo se i test passano. Il metodo con Actions è consigliato per i progetti reali perché permette di combinare CI e CD in un’unica pipeline.

3. A cosa serve il blocco permissions nel workflow di deploy?

Mostra risposta

Concede al workflow i permessi necessari per scrivere su GitHub Pages. I 3 permessi sono: contents: read (leggere il codice del repo), pages: write (scrivere su Pages), e id-token: write (autenticazione per il deploy). Senza questi permessi, il deploy fallisce con un errore “403 Forbidden”. Sono necessari perché GitHub Actions ha un modello di sicurezza restrittivo: i workflow non hanno permessi di default e devi dichiararli esplicitamente.

4. Come impedisci che un deploy pubblichi codice rotto?

Mostra risposta

Con needs: test nel job di deploy. Crei due job nel workflow: il primo (test) esegue i test automatici, il secondo (deploy) ha needs: test che lo fa partire solo se test ha successo. Se i test falliscono, il deploy non parte — il sito resta con la versione precedente funzionante. Per le PR, combinare questo con “Require status checks to pass” nelle branch protection rules impedisce anche il merge di codice che non passa i test.

5. Come pubblichi solo una sottocartella del repository (es. public/)?

Mostra risposta

Nello step upload-pages-artifact, cambi il parametro path da "." (tutta la cartella) a "public" (solo la sottocartella). Solo i file in quella cartella verranno pubblicati sul sito. Questo è utile quando il repository contiene sia il codice sorgente (src/, test/) che i file da pubblicare (public/dist/) — non vuoi che test e script siano visibili nel sito. Nei progetti con framework (React, Vue), la build produce una cartella dist/ o build/ che è quella da pubblicare.

6. Dopo il push, quanto tempo ci vuole perché il sito si aggiorni?

Mostra risposta

Tipicamente 1-3 minuti. Il tempo include: l’avvio del runner (~15-30 secondi), l’esecuzione degli step (checkout, eventuale build, upload artefatto, deploy), e la propagazione del deploy. Puoi seguire il progresso in tempo reale nella tab Actions. Se il workflow include anche test, il tempo dipende dalla durata dei test. Una volta che il job deploy è verde, il sito è aggiornato. In rari casi, potresti dover fare un hard refresh nel browser (Ctrl+Shift+R) per vedere le modifiche a causa della cache del browser.

📚 Riepilogo della lezione

Cosa hai imparato oggi:
  • GitHub Pages = hosting gratuito per siti statici, URL: tuousername.github.io/repo
  • Configurazione: Settings → Pages → Source: “GitHub Actions”
  • 4 actions del deploy: configure-pages → upload-pages-artifact → deploy-pages
  • permissions: contents: read + pages: write + id-token: write
  • Pipeline CI/CD: test (needs) → deploy — se test fallisce, deploy non parte
  • Sottocartella: cambia path: "." in path: "public" per pubblicare solo una cartella
  • Deploy continuo: push → test → deploy → sito online in ~1 minuto

Prossima lezione →

Lezione 29 — Linting e quality check
Controllare la qualità del codice automaticamente. ESLint, HTMLHint, Stylelint.
Integrare i linter nel workflow CI.

Corso Git & GitHub · Per studenti e insegnanti · Lezione 28 di 45