Gestione delle Release: Traccia Ogni Deployment nella Tua Architettura

Due mesi fa ho assistito a un post-mortem in cui la domanda centrale era ingannevolmente semplice: "Quale versione del Servizio Pagamenti sta girando in produzione adesso?"

Quattro persone hanno dato tre risposte diverse. Una ha controllato la pagina release di GitHub. Un'altra ha aperto ArgoCD. Una terza ha scrollato il canale Slack dei deploy. La quarta — quella che l'aveva effettivamente deployato — era in vacanza.

Non era una startup. Era un team con una pipeline CI/CD matura, buone pratiche di tagging e un diagramma di architettura ben mantenuto in Archyl. Il diagramma diceva esattamente quali sistemi esistevano, come si collegavano, quali protocolli parlavano. Semplicemente non poteva dire quale versione di qualsiasi cosa stesse effettivamente girando. Da nessuna parte.

Quel divario mi disturba da un po'. La documentazione dell'architettura dice la struttura di un sistema. Lo storico dei deployment dice lo stato di un sistema. Queste due cose dovrebbero vivere insieme. Oggi, è così.

Release, Collegate all'Architettura

La Gestione delle Release di Archyl traccia i deployment come oggetti di prima classe nel tuo workspace architetturale. Una release ha una versione, uno stato, un ambiente, un changelog e — fondamentalmente — un link all'elemento C4 a cui appartiene.

Quest'ultima parte è ciò che lo rende diverso dalla tua dashboard CI/CD. Un'esecuzione di GitHub Actions ti dice che v2.4.0 è stata deployata. Ma deployata dove, nel contesto della tua architettura? Quale sistema? Quale container? Le release di Archyl rispondono collegando gli eventi di deployment direttamente ai sistemi e container sul tuo diagramma C4.

Quando apri il pannello dettaglio di un sistema, vedi le sue release recenti accanto alle relazioni, ADR e API contract. Il diagramma di architettura diventa una mappa viva — non solo di cosa esiste, ma di cosa è stato rilasciato e quando.

Tre Modi per Acquisire

Non volevamo che il tracciamento delle release significasse più lavoro manuale. Se stai già deployando attraverso una pipeline, le release dovrebbero fluire in Archyl automaticamente.

GitHub Actions — Pubblichiamo una GitHub Action ufficiale che inserisci nel tuo workflow di deployment. Un setup minimo sono due righe nel tuo YAML.

- uses: archyl/release-action@v1
  with:
    api-key: ${{ secrets.ARCHYL_API_KEY }}
    version: ${{ github.ref_name }}

Tutto qui. Ogni release taggata ora appare nel tuo workspace architetturale.

Webhook — Configura un endpoint webhook nelle impostazioni del tuo progetto, poi punta i webhook release di GitHub o GitLab su di esso. Quando una nuova release viene pubblicata o un tag viene pushato, Archyl riceve l'evento e crea una voce di release automaticamente.

API REST — Per i team che usano Jenkins, CircleCI, Bitbucket Pipelines o qualsiasi altro strumento CI/CD, l'endpoint di ingestione accetta un semplice payload JSON. Autenticati con una chiave API, invia versione e metadati, e la release appare in Archyl.

Ambienti

Non tutti i deploy sono uguali. Pushare in staging è routine. Pushare in produzione è un evento. La Gestione delle Release traccia entrambi, separatamente.

Gli ambienti sono definiti dall'utente e codificati per colore. Crea "Sviluppo", "Staging", "Produzione" — o quello che il tuo team usa. Ogni release è taggata con il suo ambiente target.

La Timeline

La timeline delle release è la vista principale. Le release sono raggruppate per mese, mostrate in ordine cronologico inverso, con badge di versione, tag di ambiente e indicatori di stato.

Ogni voce di release mostra: Versione, Stato (Deployata, In Corso, Pianificata, Fallita, Rollback), Ambiente, Elemento collegato, Fonte e Changelog.

La Matrice di Deployment

Per i team che gestiscono più servizi su più ambienti, abbiamo costruito una seconda vista: la Matrice di Deployment.

È una griglia dove le righe sono i tuoi sistemi e container, le colonne i tuoi ambienti, e ogni cella mostra l'ultima release deployata per quella combinazione. A colpo d'occhio puoi vedere che l'Account API è alla v3.1.0 in produzione ma alla v3.2.0-beta in staging.

La matrice rende visibile la divergenza degli ambienti. Quando le versioni di staging e produzione divergono, lo noti immediatamente.

Ciclo di Vita dello Stato

Le release non sono sempre pulite. I deploy falliscono. Le release vengono rollbackate. Tracciamo l'intero ciclo di vita: Pianificata, In Corso, Deployata, Fallita, Rollback.

Le transizioni di stato sono automatiche quando si usano le integrazioni CI/CD, o manuali quando si creano release tramite l'interfaccia.

Collegamento agli Elementi Architetturali

Ogni release può essere collegata a un sistema, un container o entrambi. Questo è ciò che dà alle release il contesto architetturale.

Sul diagramma, gli elementi collegati mostrano il loro storico release nel pannello dettaglio. Clicca con il tasto destro su un container e vedi non solo le sue relazioni e contratti, ma la sua timeline di deployment. È dove la documentazione architetturale e la realtà operativa convergono.

Perché Questo È Importante

I diagrammi di architettura sono sempre stati un'istantanea nel tempo. Mostrano cosa è il sistema. Ma non mostrano cosa il sistema sta facendo. La Gestione delle Release mette lo storico dei deployment dove appartiene: sull'architettura stessa.

Per Iniziare

Naviga nelle Impostazioni del tuo progetto e apri la scheda Release. Scegli il metodo di integrazione e segui la guida di setup. Crea i tuoi ambienti, collega un sistema o container target e rilascia la tua prima release.

La tua architettura è più di struttura. Ora i tuoi strumenti lo riflettono.

Vuoi saperne di più su come collegare la tua architettura alla realtà? Scopri come gli API Contract collegano le tue specifiche al diagramma, o come le Richieste di Modifica dell'Architettura portano i workflow delle pull request al tuo modello C4.