Nelle squadre amatoriali, lo schieramento è un “Evento”. Lo sviluppatore principale grida: “Smettete tutti di fondervi! Sto distribuendo!” Si collegano tramite SSH a un server. Eseguono “git pull”. Pregano. Se si rompe, vanno nel panico.

Nei team professionistici, l’implementazione è un Non-Evento. Succede 20 volte al giorno. È noioso. È invisibile. Se si rompe, il sistema torna automaticamente indietro prima che l’utente lo veda.

Ciò si ottiene tramite Integrazione continua/Distribuzione continua (CI/CD). La Pipeline è un robot che presidia il tuo ambiente produttivo. Il suo compito è semplice: Rifiutare spietatamente il codice dannoso.

Perché Maison Code ne parla

In Maison Code Paris, agiamo come la coscienza architettonica dei nostri clienti. Spesso ereditiamo stack “moderni” costruiti senza una comprensione fondamentale della scala.

Discutiamo di questo argomento perché rappresenta un punto di svolta critico nella maturità ingegneristica. Implementarlo correttamente differenzia un MVP fragile da una piattaforma resiliente di livello aziendale.

1. La Filosofia: il Ramo Principale è Santo

L’obiettivo di CI/CD è garantire che il ramo “principale” sia sempre distribuibile. Non eseguire mai il push direttamente su “main”. Aderisci allo Sviluppo basato su trunk (o rami di funzionalità di breve durata).

Lo sviluppatore crea il ramo “feat/new-checkout”.
Lo sviluppatore inserisce il codice.
Esecuzioni della pipeline CI. I test passano.
Lo sviluppatore apre la richiesta pull (PR).
Viene distribuito l’Ambiente di anteprima.
Si verifica la Peer Review.
Unisci a “principale”.
La pipeline CD viene eseguita. Distribuisce alla produzione.

2. Livello 1: Analisi statica (La polizia grammaticale)

I bug più economici da correggere sono quelli rilevati prima dell’esecuzione del codice. Lo eseguiamo su ogni “git push”.

Linting (ESLint): rileva errori di sintassi e pattern errati (no-unused-vars).
Formattazione (più bella): applica lo stile. Nessun argomento su tabulazioni e spazi durante la revisione del codice.
Controllo del tipo (TypeScript): il controllo più critico. “Hai passato una stringa a una funzione che aspettava un numero.”

# .github/workflows/ci.yml
nome: CI
su: [premi]
lavori:
  convalidare:
    funziona su: ubuntu-latest
    passaggi:
      - utilizza: azioni/checkout@v3
      - utilizza: actions/setup-node@v3
      - corsa: npm ci
      - esegui: npm esegui type-check # tsc --noEmit
      - esegui: npm esegui lint

Costo: 30 secondi. Valore: Risparmia ore di debug “undefinito non è una funzione”.

3. Livello 2: Unit test (il controllo logico)

(Vedi Unit Testing). La funzione calculateTax() restituisce il valore corretto per un utente tedesco? Usiamo Vitest. Deve essere veloce. Se gli unit test richiedono >5 minuti, gli sviluppatori ne interromperanno l’esecuzione in locale.

4. Livello 3: L’ambiente di anteprima (Vercel)

Questo è il punto di svolta. Quando viene aperta una PR, Vercel distribuisce automaticamente tale codice in un URL univoco: “https://my-app-git-feat-checkout.vercel.app”. Ciò consente:

QA visivo: il designer può fare clic sul checkout per vedere se i pixel sono perfetti.
Revisione del prodotto: il PM può verificare che la funzionalità soddisfi i requisiti.
Test E2E automatizzati: la pipeline può eseguire un browser su questo URL reale.

5. Livello 4: test end-to-end (E2E) (il simulatore utente)

I test unitari non sono sufficienti. “La connessione al database funziona. Il pulsante viene visualizzato. Ma facendo clic sul pulsante non viene salvato nel database.” Solo Drammaturgo (o Cypress) lo capisce.

La pipeline CI avvia un browser headless e si comporta come un utente.

Vai su “/prodotto/scarpe da ginnastica”.
Fare clic su “Aggiungi al carrello”.
Aspettatevi che il “Carrello (1)” sia visibile.

  e2e:
    esigenze: anteprima
    funziona su: ubuntu-latest
    passaggi:
      - utilizza: azioni/checkout@v3
      - nome: Run Playwright
        esegui: test del drammaturgo npx
        ambiente:
          BASE_URL: ${{ github.event.deployment_status.target_url }}

Blocco: se i test E2E falliscono, il pulsante “Unisci” in GitHub è disabilitato.

6. Distribuzione continua: il rilascio

Una volta unito il codice a “main”, viene avviata la pipeline del CD. Per Vercel/Netlify, questo è automatico. Per AWS (Docker/ECS), utilizziamo GitHub Actions per creare il contenitore, inviarlo a ECR e aggiornare la definizione dell’attività.

Zero tempi di inattività (blu/verde)

Non riavviamo mai un server live.

Gira su Verde (nuova versione).
Attendere il controllo dello stato (“200 OK”).
Imposta il bilanciamento del carico su Verde.
Uccidi Blu (vecchia versione). Ciò garantisce che se la nuova versione si arresta in modo anomalo all’avvio, nessun utente la vedrà.

7. La regola dello “schieramento del venerdì”.

C’è un meme: “Non schierare venerdì”. A Maison Code, siamo operativi il venerdì. Se hai paura di effettuare la distribuzione venerdì, significa che non ti fidi della tua pipeline. Significa che ti affidi al QA manuale o alla speranza. Una pipeline robusta ti dà la sicurezza di spedire in qualsiasi momento.

8. Scansione di sicurezza (Shift Left)

La sicurezza viene spesso eseguita “alla fine” tramite un Pentest. Lo spostiamo nella Pull Request.

Snyk / Dependabot: esegue la scansione di package.json per individuare dipendenze vulnerabili.
Trivy: analizza i contenitori Docker per le vulnerabilità del sistema operativo.
SonarQube: esegue la scansione del codice per gli hotspot (ad esempio, password codificate). Se impegni una chiave AWS, la pipeline esplode. Impedisce al segreto di raggiungere la cronologia del ramo “principale”.

9. Gestione dei costi (Infracost)

Gli sviluppatori adorano creare istanze di grandi dimensioni. “Ho bisogno di un database X1.Large per i test.” Utilizziamo Infracost. Funziona nel PR e commenta:

“Questo PR aumenta la fattura mensile di € 150 (aggiornamento a X1.Large).” Ciò rende i costi trasparenti. Il CTO può approvare o respingere la “Modifica finanziaria” proprio come una “Modifica del codice”. Porta FinOps in DevOps.

10. Gestione dei segreti (Env Vars)

Non eseguire mai il commit di file .env. Utilizziamo Vercel Env Management o AWS Secrets Manager. La pipeline CI li inserisce in fase di compilazione. Per i controlli Open Source (come npm audit), ci assicuriamo che i segreti non vengano registrati sulla console.

9. GitOps (ArgoCD): Il Santo Graal

Per i nostri cluster Kubernetes utilizziamo GitOps. Lo stato del cluster è definito in Git. Se vuoi scalare da 3 pod a 5 pod, non esegui “kubectl scale”. Puoi modificare deployment.yaml in Git. ArgoCD vede la modifica e sincronizza il cluster. Rilevamento della deriva: Se un ingegnere cowboy modifica manualmente il cluster (SSH), ArgoCD rileva la deriva e sovrascrive lo riporta allo stato Git. Ciò applica religiosamente “Infrastruttura come codice”.

10. Seeding del database per le anteprime

Un ambiente di anteprima è inutile se ha un database vuoto. Accedi e non ci sono prodotti. Implementiamo il Semina automatizzato.

Distribuire DB (ramo Neon/Supabase).
Eseguire “npm run seed”.
Iniezioni: 10 prodotti, 2 utenti (amministratore/cliente), 5 ordini. Ora il PM può testare immediatamente la pagina “Cronologia ordini”. Questa è la differenza tra una “distribuzione tecnica” e un “prodotto utilizzabile”.

11. Rollback avanzato: distribuzioni Canary

Per le app ad alto rischio, Blu/Verde è troppo binario. Utilizziamo Canary Deployments.

Distribuisci la v2 al 5% del traffico.
La pipeline controlla il tasso di errore.
Se il tasso di errore è < 0,1%, aumentare al 20%.
Se il tasso di errore aumenta, rollback automatico allo 0%. Ciò limita il “raggio di esplosione” di un bug dannoso. Solo il 5% degli utenti ha visto l’errore. Ciò richiede sofisticati bilanciatori di carico (AWS ALB / Cloudflare), ma è la rete di sicurezza definitiva.

12. Conclusione

Le operazioni manuali sono nemiche della scala. Ogni volta che un essere umano tocca un server, il rischio di errore è del 10%. Ogni volta che uno script tocca un server, il rischio è dello 0% (dopo la prima esecuzione riuscita). Automatizza tutto. Fare della “cosa giusta” la “cosa facile”.

Leggi informazioni su [Test automatizzati](/it/blog/tech-automated-testing-it) e [Infrastructure as Code](/it/blog/tech-infrastructure-code-it).