Pubblichi una correzione alle quattro di un venerdì. Sabato mattina, gli avvisi iniziano a suonare. Risali all'incidente fino a una pull request unificata diciotto ore prima. Il branch è stato compilato, i test sono passati, ma la descrizione della PR è vuota. Nessun work item è collegato. La cronologia delle approvazioni non mostra nulla. Stai guardando un ghost merge, e ora ti stai passando il fine settimana a rimediare a un disastro che avrebbe dovuto essere intercettato prima di toccare il main.

I piccoli team vivono con questo rischio ogni giorno. Non hai un release manager che sorveglia ogni merge. Non hai un team di piattaforma che costruisce motori di policy su misura. Quello che hai è Azure DevOps, e le sue branch policy integrate sono uno strumento rudimentale. O chiudono la porta a chiave o la lasciano spalancata. Richiedi due revisori e blocchi le hotfix urgenti. Allenta le regole e descrizioni vuote finiscono in produzione insieme a modifiche senza ticket. Raramente esiste una via di mezzo.

Quel divario è esattamente il motivo per cui abbiamo creato Gatekeeper. È un desk di revisione PR basato sull'IA, progettato specificamente per Azure DevOps, ma dimentica tutto ciò che presupponi sugli strumenti di sviluppo moderni. Non c'è un container Docker, non c'è un piano di abbonamento e non c'è una pipeline di deployment cloud. Gatekeeper è un singolo file HTML. Lo apri nel browser, inserisci quattro valori e premi un pulsante. Lo strumento risponde quindi a tre semplici domande: Questa PR è collegata a un ticket? Un essere umano l'ha effettivamente revisionata? E la qualità del codice è buona?

La decisione di impacchettare tutto in un unico file autonomo non è stata un espediente pubblicitario. Risolve veri e propri mal di testa operativi. Primo, non c'è alcuna infrastruttura da ospitare o pagare. Non stai configurando un App Service o preoccupandoti dei costi di uscita dati. Secondo, le credenziali non lasciano mai la tua macchina. Il tuo personal access token di Azure DevOps risiede solo nella memoria del browser e svanisce nel momento in cui rinfreschi la pagina. Non c'è un database di segreti da esporre e nessun server OAuth di cui fidarsi. Terzo, l'adozione diventa senza attriti. Non devi inserire nessuno tramite un wiki. Alleghi il file a un'e-mail o lo inserisci in una chat di Slack. Il destinatario lo apre e inizia subito la revisione.

Il Fact Layer: prima il determinismo

Gatekeeper divide la sua revisione in due livelli distinti, e questa separazione è la spina dorsale della sua affidabilità.

Il primo livello è puro JavaScript che comunica direttamente con l'API REST di Azure DevOps. Controlla fatti che non cambiano. O una pull request è collegata a un work item, o non lo è. O un revisore ha espresso un voto di approvazione, o non lo ha fatto. La descrizione è vuota, o contiene frasi reali. Le discussioni attive sono risolte, o sono ancora aperte.

Nello specifico, il Fact Layer cerca quattro cose:

  • Ticket mapping: La PR è collegata ad almeno un work item?
  • Reviewer sign-off: Qualcuno ha votato per approvare, o il conteggio è ancora zero?
  • Description quality: La descrizione è vuota o è solo un segnaposto minimo?
  • Open discussions: Ci sono thread di commenti non risolti in attesa di una risposta?

Questi controlli producono timbri visivi su tutta la pagina. Un grande timbro rosso NOT MAPPED è difficile da ignorare. Una sottile spunta verde nascosta in una cella di una tabella è facile da perdere. Abbiamo imparato presto che i fallimenti dei processi devono essere rumorosi. Quando uno sviluppatore ha fretta di fare il merge, la sottigliezza non funziona. Il Fact Layer esiste per eliminare completamente ogni ambiguità.

Poiché questo livello si affida a risposte API deterministiche, la sua precisione è assoluta. Se il timbro dice NO APPROVAL, puoi scommettere che nessuno ha cliccato sul pulsante di approvazione. Se dice UNRESOLVED THREADS, la conversazione è ancora in corso. Questo livello non