GitHub Actions: Pipeline CI/CD per Ogni Progetto
Ogni push su un repository i3k attiva una pipeline automatica: lint, type-check, test, build, deploy. Niente va in produzione senza passare per GitHub Actions. Ecco come abbiamo strutturato i workflow per gestire frontend Vercel, backend Docker e deploy on-premise.
La Pipeline Standard: Dal Push al Deploy
Ogni repository i3k ha un workflow GitHub Actions che si attiva su push al branch main e su ogni pull request. La pipeline è divisa in job paralleli per massimizzare la velocità: lint (ESLint + Prettier check) e type-check (tsc --noEmit) girano contemporaneamente. Se entrambi passano, parte il job di test (Vitest con coverage report). Solo se i test superano la soglia dell'85% di coverage, il job di build viene eseguito. Per i frontend React come i3k.eu, il build produce asset statici che Vercel distribuisce automaticamente. Non abbiamo bisogno di un job di deploy esplicito — Vercel è integrato nativamente con GitHub e rileva ogni push. Per i backend Python (RAG Enterprise, CRM81 cloud), il job di build crea un'immagine Docker e la pusha su GitHub Container Registry. La pipeline completa per il frontend impiega circa 2 minuti. Per il backend, incluso il build Docker multi-stage, circa 5 minuti. Abbiamo ottimizzato i tempi con caching aggressivo: le dipendenze npm vengono cachate con actions/cache e la cache dei layer Docker riduce i rebuild del 70%. Prima del caching, il build backend richiedeva 14 minuti.
Staging, Produzione e Gestione dei Secrets
Abbiamo workflow separati per staging e produzione con gate manuali. Il push su main deploya automaticamente in staging. Il deploy in produzione richiede un'approvazione manuale tramite GitHub Environments — un membro senior del team deve cliccare "Approve" nella UI di Actions. Questo ci ha salvato almeno tre volte da deploy affrettati il venerdì sera. I secrets sono gestiti interamente tramite GitHub Secrets a livello di repository e di environment. Le chiavi API dei provider LLM (Anthropic, OpenAI), le credenziali del database, i token SSH per i server on-premise — tutto vive nei secrets, mai nel codice. Ogni environment (staging, production, on-premise) ha il suo set di secrets isolato. Un workflow di staging non può accedere ai secrets di produzione. Per i deploy on-premise, il workflow è più complesso. Dopo il build dell'immagine Docker, un job dedicato si connette via SSH al server del cliente (usando una chiave Ed25519 salvata nei secrets), pusha l'immagine, e esegue un rolling update con docker compose. L'intero processo è automatizzato ma richiede approvazione manuale e una finestra di manutenzione concordata con il cliente.
Docker Image Builds e Integrazione con Vercel
I nostri backend Python usano build Docker multi-stage per produrre immagini leggere. Il primo stage installa le dipendenze con pip in un virtualenv, il secondo copia solo il virtualenv e il codice sorgente su un'immagine python:3.12-slim. L'immagine finale di RAG Enterprise pesa 1.8 GB (inclusi i modelli di embedding), mentre CRM81 è più snello a 650 MB. GitHub Actions builda le immagini con docker/build-push-action e le pusha su ghcr.io (GitHub Container Registry). Usiamo il caching dei layer Docker tramite actions/cache con mode=max, che salva tutti i layer intermedi. Quando cambia solo il codice sorgente (e non le dipendenze), il rebuild impiega 45 secondi invece di 8 minuti perché il layer di pip install viene riusato dalla cache. Per il frontend, la relazione con Vercel è più sfumata. Vercel ha il suo sistema di build, ma noi eseguiamo comunque lint, type-check e test in GitHub Actions prima che Vercel faccia il deploy. Se la pipeline GitHub fallisce, il commit è marcato con un check rosso e Vercel non deploya automaticamente su produzione (abbiamo configurato Vercel per richiedere checks passati). Questo doppio layer di validazione ci dà la certezza che nessun codice rotto arrivi in produzione.
Interessato?
Contattaci per ricevere un preventivo personalizzato.
Securvita S.r.l. — i3k.eu