Ingegneria
Dal sorgente a un rilascio sano: cosa fa davvero una distribuzione
Un comando di distribuzione attraversa diversi confini: preparazione del pacchetto sorgente, compilazione, avvio dell'ambiente di esecuzione, readiness, promozione e instradamento pubblico. Ognuno può fallire in modo diverso.
Una compilazione riuscita non è un'applicazione attiva. Tra il sorgente sul computer dello sviluppatore e un URL pubblico ci sono verifiche indipendenti, ciascuna con evidenze e un percorso di recupero propri.
Il confine del sorgente: acquisire ciò che verrà compilato
La prima domanda sembra semplice: quali file rappresenta questa distribuzione? Una directory locale, una revisione Git e uno spazio di lavoro aperto possono avere contenuti diversi. Se la piattaforma non identifica il sorgente esatto che ha compilato, il debug successivo diventa una serie di ipotesi. Adios registra il sorgente come artefatto, così una distribuzione può essere ricondotta a codice riapribile in uno spazio di lavoro.
Il pacchetto deve escludere output eliminabili come node_modules e directory locali di compilazione, conservando lockfile, manifest e file necessari alla compilazione. Un caricamento riuscito dimostra soltanto che il pacchetto è arrivato. Non dimostra che il codice si compili o che l'ambiente di esecuzione possa avviarsi.
Il confine della compilazione: produrre un output versionato
La fase di compilazione installa le dipendenze, esegue il comando dichiarato e produce l'output che il carico di lavoro avvierà. Una compilazione non riuscita deve lasciare log e un esito di errore, anziché un rilascio promosso a metà. Adios espone separatamente i log della compilazione e dell'ambiente di esecuzione perché gli errori di risoluzione dei pacchetti e compilazione hanno responsabili diversi da quelli di avvio dell'applicazione.
Per un'API Go, l'output della compilazione può essere un binario. Per Next.js, comprende output del server e risorse. Per un servizio Python, il lavoro importante può consistere nell'installare dipendenze con versioni fissate e preparare l'ambiente. La forma varia, ma la regola rimane: l'ambiente di esecuzione avvia un output identificato, derivato da un sorgente identificato secondo un contratto di compilazione esplicito.
- —Registra l'artefatto sorgente e l'identificatore della compilazione.
- —Mantieni il comando di compilazione in adios.yaml e negli script del progetto.
- —Esamina i log della compilazione quando l'installazione delle dipendenze o la compilazione non riesce.
- —Non dedurre il corretto stato dell'ambiente di esecuzione dal successo della compilazione.
Il confine dell'ambiente di esecuzione: avviare il processo corretto
Una volta disponibile la compilazione, il worker deve avviare il processo di produzione dichiarato con ambiente, limiti di risorse e impostazioni di rete. Un errore comune è un processo che ascolta su una porta diversa da quella del manifest. Un altro è ascoltare solo su localhost quando il gateway deve raggiungere il listener del carico di lavoro. Segreti mancanti e risorse gestite necessarie possono anche far terminare subito il processo o farlo apparire attivo senza servire richieste.
Adios crea una versione dell'ambiente di esecuzione con una o più repliche. Il manifest descrive regione, numero di repliche, comando di avvio, porta e percorso di verifica dello stato. Queste informazioni bastano a chi esamina il rilascio per valutarne l'esecuzione sicura senza dipendere da un'impostazione della dashboard mai salvata nei commit.
A small API deploy contract
name: api
region: de
replicas: 2
build_cmd: go build -o /app/api ./cmd/api
start_cmd: /app/api
runtime:
name: go@1.25
port: 8080
health_path: /healthzIl confine della readiness: dimostrare che questa versione può servire richieste
Un processo può essere in esecuzione mentre le sue route restituiscono errori. La readiness verifica se questa versione può gestire una richiesta reale. Un percorso di controllo dello stato utile deve fallire entro una scadenza quando una dipendenza necessaria è indisponibile e riprendersi quando torna disponibile. Deve evitare lavoro costoso che trasformi il controllo stesso in una fonte di carico.
La guida rapida di Adios descrive la promozione dopo che una distribuzione risulta sana. La CLI verifica anche un percorso pubblico di controllo dello stato configurato e può indicare che la route corrente è sana. Sono osservazioni diverse: la readiness delle repliche protegge la versione candidata; un controllo pubblico verifica ciò che il client può raggiungere attraverso l'ingresso. Una verifica completa richiede entrambi, più una richiesta a una route applicativa rappresentativa.
Il confine della promozione: rendere corrente la nuova versione
Una versione di distribuzione e il rilascio corrente sono concetti distinti. Questa distinzione permette a un operatore di esaminare una versione non riuscita o superata senza presentarla come quella che serve gli utenti. La route deve puntare alla versione che ha superato le verifiche richieste e una candidata non riuscita deve lasciare disponibile il rilascio corrente precedente.
Qui il rollback assume un significato concreto: seleziona una versione precedente nota come sana, verifica risorse e compatibilità dello schema e riporta la route a quella versione. Una migrazione del database applicativo può rendere l'operazione più difficile anche se la piattaforma conserva il vecchio output dell'ambiente di esecuzione. Esamina la compatibilità con le versioni precedenti prima di considerare automatico il rollback.
Il confine della route pubblica: verificare ciò che vedono gli utenti
La richiesta finale attraversa DNS, TLS, un gateway di ingresso, la ricerca della route e il carico di lavoro selezionato. Un errore in uno qualsiasi di questi punti può apparire all'utente come una distribuzione non funzionante anche se il container è sano. Richiedi hostname e percorso reali, verifica reindirizzamenti e certificati e confronta la risposta con la versione che intendevi promuovere.
Per un dominio personalizzato, verifica DNS ed emissione del certificato sono passaggi aggiuntivi. Per un indirizzo Anycast, il nodo edge che riceve la richiesta può trovarsi in una città diversa dal carico di lavoro. Lo smoke test pubblico serve a verificare l'intero percorso, senza fermarsi a un controllo di stato locale.
- —Usa i log della compilazione per gli errori di preparazione del pacchetto e compilazione.
- —Usa i log dell'ambiente di esecuzione per errori di avvio, dipendenze e controlli di stato.
- —Usa una richiesta HTTPS pubblica per gli errori di TLS, route e selezione del rilascio.
- —Registra l'artefatto sorgente e la versione accanto alla risposta pubblica.
Una distribuzione è completa quando le evidenze concordano
Il risultato utile di una distribuzione va oltre un URL. È una catena che collega sorgente, compilazione, versione dell'ambiente di esecuzione, esito della readiness, rilascio promosso e risposta pubblica. Quando gli identificatori concordano, lo sviluppatore può sapere cosa è in produzione e come recuperare. Quando divergono, il confine in cui si interrompono le evidenze indica dove indagare.