Basta con i conflitti tra ambienti: ecco come E-Pods offre a ogni sviluppatore di SnapLogic il proprio clone di produzione

I team di ingegneri si trovano ad affrontare una sfida cruciale: come testare le funzionalità in ambienti simili a quelli di produzione senza compromettere la stabilità, far lievitare i costi o ostacolare il lavoro degli altri sviluppatori. Il tradizionale modello di ambiente di staging condiviso crea colli di bottiglia, introduce instabilità e rallenta la velocità di distribuzione. Allo stesso tempo, creare cloni completi dell'infrastruttura per ogni sviluppatore è proibitivo dal punto di vista economico e complesso dal punto di vista operativo.

Abbiamo creato gli E-Pods (Ephemeral Pods) proprio per risolvere questo problema: si tratta di un framework basato su GitOps che offre agli sviluppatori ambienti su richiesta, isolati e simili a quelli di produzione attraverso un semplice flusso di lavoro basato su pull request. Questo articolo illustra come gli E-Pods consentano di adottare pratiche di sviluppo attente ai costi e ai rischi, accelerando al contempo l'innovazione.

Il problema dell'ambiente condiviso

Ogni azienda di ingegneria che abbia superato la fase iniziale di pochi sviluppatori conosce bene le difficoltà legate agli ambienti di staging condivisi. Il conflitto è intrinseco: gli sviluppatori hanno bisogno di stabilità per testare le loro modifiche, ma devono anche distribuire codice potenzialmente instabile per convalidarle. Quando più team condividono lo stesso ambiente, ne deriva il caos.

Immaginate questa situazione: il Team A implementa una modifica che comporta un'incompatibilità per testare una nuova funzionalità. Nel frattempo, il Team B sta cercando di presentare il proprio lavoro agli stakeholder. La verifica della correzione di un bug critico da parte del Team C è ora bloccata perché l'ambiente è instabile. Vi suona familiare?

Le soluzioni tradizionali presentano tutte degli svantaggi:

• Ambienti di staging condivisi: causano colli di bottiglia, instabilità e accuse reciproche quando qualcosa va storto
• Ambienti di sviluppo a lunga durata: accumulano scostamenti, diventano costosi e continuano a causare conflitti di pianificazione
• Cloni completi dell'infrastruttura: costi proibitivi e complessità operativa su larga scala
• Solo sviluppo locale: non è sufficiente per testare le integrazioni, le interazioni tra microservizi e le funzionalità che dipendono dall'infrastruttura

Vi presentiamo E-Pods: ambienti temporanei basati su GitOps

Gli E-Pods adottano un approccio diverso. Anziché gestire complessi flussi di lavoro per l'allestimento degli ambienti o effettuare l'implementazione tramite diversi strumenti, gli sviluppatori devono semplicemente aprire una pull request su GitHub. Tutto qui. Il framework si occupa di tutto il resto: allestimento dell'infrastruttura, implementazione dei servizi, configurazione della rete e fornitura delle credenziali di accesso.

Come funzionano gli E-Pod

Il flusso di lavoro di E-Pods è di una semplicità elegante:

1. Aprire una richiesta di pull. Gli sviluppatori creano una richiesta di pull nel nostro repository E-Pods dedicato, specificando i servizi di cui hanno bisogno e le versioni desiderate. La richiesta di pull diventa l'unica fonte di riferimento per la configurazione dell'ambiente.

2. Unire e distribuire. Una volta unita la PR, il nostro controller GitOps (basato su ArgoCD) rileva la modifica e avvia il provisioning. I passaggi:

• Crea namespace Kubernetes isolati
• Distribuisce le versioni specificate del servizio
• Configura le regole di rete e del service mesh
• Configura il monitoraggio e l'osservabilità
• Creazione di database temporanei

3. Ricezione delle credenziali di accesso all'ambiente. In pochi minuti, gli sviluppatori ricevono un'e-mail contenente:

• URL di accesso all'ambiente
• Credenziali di accesso all'interfaccia utente

4. Monitoraggio tramite Slack: gli aggiornamenti di stato in tempo reale vengono inviati su Slack, tenendo informati gli sviluppatori su:

• Stato di avanzamento dell'implementazione
• Controlli dello stato dei servizi
• Preparazione ambientale

5. Gestione delle versioni tramite Kargo: è qui che gli E-Pod danno il meglio di sé. Abbiamo integrato Kargo, uno strumento di distribuzione continua che offre un'interfaccia visiva per la gestione delle versioni. Gli sviluppatori accedono a un URL Kargo dedicato dove possono:

• Visualizza tutte le versioni del servizio disponibili nel “magazzino”
• Aggiorna o torna a una versione precedente del servizio con un solo clic
• Monitorare le fasi della promozione su tutti i servizi
• Visualizza la cronologia delle distribuzioni ed esegui il rollback se necessario

Kargo si sincronizza con il nostro sistema di integrazione continua (nel nostro caso Travis CI), importando automaticamente le immagini dei container appena create. Quando la compilazione di un nuovo ramo di funzionalità viene completata, gli sviluppatori la vedono immediatamente disponibile nell'interfaccia di E-Pods Kargo.

6. Pulizia automatica: E-Pods è progettato per ottimizzare i costi. Ogni ambiente ha una durata prestabilita. Prima dello spegnimento:

• Gli sviluppatori ricevono un'e-mail di avviso che li informa dell'imminente cancellazione
• Possono prolungare la durata dell'ambiente
• Oppure eliminarlo manualmente tramite una pull request su GitHub una volta completati i test

Il vantaggio di GitOps

La nostra scelta di implementazione, GitOps, offre una serie di vantaggi sinergici.

Configurazione dichiarativa. Le definizioni dell'ambiente sono memorizzate in Git e forniscono:

• Cronologia delle versioni e registri di controllo
• Facile ripristino delle configurazioni precedenti
• Revisione tra pari attraverso i flussi di lavoro di PR
• Documentazione che non può allontanarsi dalla realtà

Self-service senza complicazioni. Gli sviluppatori non devono conoscere Kubernetes, i chart Helm o l'infrastruttura come codice. Lavorano con flussi di lavoro Git a loro familiari e file di configurazione YAML.

Riconciliazione e rilevamento delle discrepanze. Il controller GitOps effettua una riconciliazione continua tra lo stato desiderato (in Git) e lo stato effettivo (nel cluster). Se qualcuno modifica manualmente un E-Pod, il controller lo corregge automaticamente.

Integrazione con i flussi di lavoro esistenti. Poiché i team di sviluppo utilizzano già GitHub per la revisione del codice, l'aggiunta della configurazione dell'ambiente allo stesso flusso di lavoro non comporta alcun sovraccarico cognitivo.

Impatto concreto: la trasformazione dell'esperienza degli sviluppatori

Da quando abbiamo introdotto gli E-Pod, abbiamo riscontrato notevoli miglioramenti sotto diversi aspetti:

Miglioramenti in termini di velocità

Prima degli E-Pod:

• Tempo medio necessario per ottenere un ambiente di test: 2-3 giorni (comprese la richiesta, la configurazione e l'attesa della disponibilità dell'ambiente condiviso)
• Conflitti relativi all'ambiente: 3-5 alla settimana che richiedono una risoluzione manuale
• Distribuzioni non riuscite a causa dell'instabilità dell'ambiente: circa il 30% dei tentativi iniziali

Dopo gli E-Pod:

• Tempo medio necessario per ottenere un ambiente di test: 3-5 minuti (dal merge del PR alla messa a disposizione)
• Conflitti di ambiente: Zero (isolamento totale)
• Failed deployments due to environment issues: <5%

Efficienza in termini di costi

Grazie all'implementazione della pulizia automatica e all'allocazione delle risorse in base alle effettive esigenze, abbiamo ottenuto:

• Riduzione dei costi delle infrastrutture di sviluppo
• Riduzione del consumo delle risorse inattive
• Eliminazione degli ambienti di sviluppo obsoleti e in disuso

Soddisfazione degli sviluppatori

I riscontri qualitativi sono stati estremamente positivi:

• Gli sviluppatori riferiscono di dedicare meno tempo alla gestione dell'ambiente e più tempo alla programmazione
• Minore attrito nella collaborazione tra team (niente più conflitti di programmazione)
• Convalida più rapida delle funzionalità e dimostrazioni per gli stakeholder
• Meno preoccupazioni riguardo alla rottura degli ambienti condivisi

Gli ambienti effimeri come vantaggio competitivo

Nella corsa verso cicli di innovazione più rapidi e una distribuzione del software più affidabile, gli ambienti effimeri sono diventati una necessità competitiva. E-Pods dimostra che, grazie a scelte architetturali adeguate, all’adozione del GitOps, all’attenzione ai costi, all’isolamento dei rischi e a flussi di lavoro incentrati sugli sviluppatori, le organizzazioni possono fornire agli sviluppatori potenti funzionalità di test senza incorrere in costi elevati né introdurre complessità operative.

Il futuro degli ambienti di sviluppo è caratterizzato da transitorietà, isolamento e disponibilità su richiesta. Considerando la creazione degli ambienti come codice, integrandosi con i flussi di lavoro esistenti degli sviluppatori e incorporando la consapevolezza dei costi fin dalle fondamenta, E-Pods consente ai nostri team di agire con maggiore rapidità, mantenendo al contempo la stabilità e l'affidabilità richieste dalla nostra azienda.