CI/CD per Laravel: Git workflow e deploy zero-downtime

Di Andrea Pollastri · Ultimo aggiornamento: 4 agosto 2026 · lettura gratuita, nessun paywall

Il divario tra "funziona sul mio computer" e "si deploya da solo in sicurezza" è più piccolo che mai. Questa guida ti offre un Git workflow che scala anche per un team di uno, una pipeline CI copia-incolla e i pattern di deploy zero-downtime che rendono noiose le release del venerdì.

Perché le pipeline ripagano (anche da solo)

CI/CD non è cerimonia enterprise — è l'assicurazione più economica che un codebase possa comprare:

• Ripetibilità: la pipeline esegue gli stessi controlli ogni volta; gli umani no.
• L'ansia da deploy va a zero. Quando i deploy sono una push e i rollback un symlink, spedisci piccoli cambiamenti spesso invece di batch spaventosi di rado.
• La qualità delle review sale perché CI ha già intercettato i problemi meccanici prima che un umano guardi.
• Il codice generato dall'AI rende tutto questo obbligatorio: se gli agent scrivono più del tuo codice, la pipeline è l'arbitro che mantiene gli standard oggettivi (approfondisci nella guida allo sviluppo spec-driven).

Un Git workflow che scala verso il basso

Salta git-flow a meno che non spedisci release in scatola. Per web app, trunk-based con branch di breve durata vince:

• main è sempre deployabile. Proteggila: niente push dirette, le PR devono passare CI.
• I branch vivono giorni, non settimane. feature/checkout-vat, fix/queue-timeout — mergia o elimina.
• Conventional commits (feat:, fix:, chore:) rendono la history scansionabile e i changelog automatizzabili.
• Tagga le release (v2026.08.04 o semver) così puoi sempre rispondere a "cosa era live martedì?".
• Le PR sono la traccia di audit. Anche da solo: una self-review di due minuti con CI verde intercetta sorprendentemente tanto.

La pipeline CI, pronta da copiare

Quattro stage, ognuno che fallisce in fretta: style, analisi statica, test, audit di sicurezza. Ecco un workflow GitHub Actions completo per un'app Laravel (mettilo in .github/workflows/ci.yml):

name: CI

on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.4'
          extensions: mbstring, xml, curl, zip, intl, pdo_sqlite
          coverage: none

      - name: Install dependencies
        run: composer install --prefer-dist --no-progress

      - name: Prepare environment
        run: |
          cp .env.example .env
          php artisan key:generate

      - name: Code style (Pint)
        run: vendor/bin/pint --test

      - name: Static analysis (Larastan)
        run: vendor/bin/phpstan analyse --memory-limit=1G

      - name: Tests (Pest)
        run: php artisan test --parallel

      - name: Security audit
        run: composer audit

Note da rubare:

• Pint, Larastan, Pest, audit — in quest'ordine: controlli più economici prima, così i fallimenti sono rapidi.
• --parallel su Pest di solito dimezza il tempo della suite gratis.
• composer audit fa fallire la build quando una dipendenza ha una CVE nota — il tuo tripwire della supply chain (vedi la checklist di sicurezza per la sezione completa sull'igiene delle dipendenze, inclusa la scansione Laravel-specifica con Checkpoint).
• Aggiungi npm ci && npm run build come job separato se la build degli asset non è banale.

Opzioni di deploy zero-downtime

Zero-downtime significa: costruisci la nuova release accanto a quella vecchia, scambia atomicamente, riavvia i worker. Tre modi per ottenerlo:

1. Webhook push-to-deploy (default consigliato)

Il tuo host Git chiama un webhook alla push; il server costruisce una nuova release in releases/, esegue composer install, migrate --force e le cache, scambia il symlink current e riavvia i queue worker. È esattamente ciò che Cipi configura automaticamente quando colleghi GitHub o GitLab a un'app — deploy key, webhook, release e swap del symlink inclusi, più build asset Node al deploy e snapshot database pre-deploy in Cipi 5. Costo di setup: un cipi app create.

2. Deploy guidato da CI (SSH da Actions)

La pipeline costruisce gli artifact e li spinge via SSH (Deployer o rsync + script). Più controllo, più YAML da gestire — vale la pena quando ti servono artifact di build identici tra ambienti.

3. L'ibrido

CI esegue i test; se verde, colpisce il webhook di deploy. Ottieni deploy gated senza spostare la logica di deployment in CI. Con Cipi, basta un curl di una riga a fine workflow.

Dopo il deploy

• Health check: verifica che l'app risponda prima di festeggiare — Cipi 5 include health check per app che puoi puntare ai monitor.
• Smoke test del percorso critico: un curl alla pagina di login e uno a un endpoint autenticato intercettano la maggior parte degli stati "deployato ma rotto".
• Osserva le eccezioni per 15 minuti. Un tracker self-hosted come Boogle rende visibile subito il picco di errori post-deploy.
• Notifica il team: notifiche deploy su Slack o Telegram chiudono il cerchio (la documentazione Cipi include esempi pronti di notifiche CI).

Migrazioni e strategia di rollback

• Expand/contract: aggiungi prima la nuova colonna e il codice che scrive entrambe; rimuovi la vecchia release dopo. Mai rinominare sul posto.
• Le migrazioni distruttive hanno la loro release — dopo che il codice che ha smesso di usare i dati è verificato in produzione.
• Il rollback del codice è il symlink alla release precedente; ecco perché il pattern releases conta.
• Il rollback dei dati è uno snapshot. Cipi 5 scatta automaticamente uno snapshot database pre-deploy, così al peggior errore di migrazione hai un pulsante annulla.

Domande frequenti

Continua a leggere