Quali gate delle pull request degli agenti devono bloccare un merge?

Un agente può produrre un diff pulito, una descrizione convincente e codice che supera una revisione rapida, lasciando comunque un'applicazione esposta o impossibile da ripristinare. La decisione di merge deve quindi dipendere da prove che il repository può misurare, non da quanto l'agente sembri sicuro di sé o da quanto piccola appaia la patch.

Uso sette gate bloccanti: test, CodeQL, revisione delle dipendenze, scansione dei segreti, controlli di autorizzazione, prova della migrazione e verifica del rollback. Ognuno risponde a una diversa domanda sul possibile fallimento. Una suite di test verde non può dimostrare che un nuovo pacchetto sia sicuro, e un'analisi statica pulita non dice nulla sul fatto che una migrazione del database blocchi la tabella più usata.

Questi gate si applicano allo stesso modo alle modifiche umane e a quelle degli agenti. L'autore agente cambia volume, velocità e forma degli errori, ma non giustifica un percorso separato e più debole. Se una modifica proposta non può fornire le stesse prove di qualsiasi altra pull request, non è pronta per il merge.

Un gate deve produrre prove, non consigli

Un gate di merge deve restituire un risultato riproducibile di superamento o fallimento per l'esatto commit che entrerà nel branch protetto. Un commento che dice "controlla questa dipendenza" è un consiglio. Un controllo obbligatorio che identifica pacchetto, versione, avviso e soglia di gravità è una prova.

La distinzione conta perché molte funzionalità di sicurezza, per impostazione predefinita, segnalano il problema dopo il momento utile per decidere. Uno scanner può creare un avviso, inviare un'email o aprire un ticket mentre il pulsante di merge resta disponibile. I team finiscono per dire che la scansione è “attiva” anche se non può fermare la modifica. Per ogni gate, verifica quattro proprietà:

• Viene eseguito sul commit di testa corrente della pull request.
• La protezione del branch richiede il suo risultato nominato.
• Un job saltato, scaduto o arrestato non conta come superato.
• Il risultato registra dettagli sufficienti a riprodurre la decisione.

Conserva la policy nel repository. Un piccolo manifest rende la revisione più semplice di una raccolta di impostazioni note solo agli amministratori:

merge_gates:
  tests: required
  codeql: required
  dependency_review: required
  secret_scan: required
  authorization: required
  migration_rehearsal: required_when_changed
  rollback_verification: required

Il valore required_when_changed non è una scappatoia. Significa che il gate prima rileva i file pertinenti e poi esegue la prova oppure registra un risultato pulito “non applicabile”. Non lasciare che i filtri sui percorsi mantengano un controllo obbligatorio permanentemente in attesa e non permettere a un agente di decidere che la propria modifica rischiosa sia esente.

Limita i permessi del workflow al minimo necessario per ogni job. Il codice delle pull request è input non attendibile, anche quando il branch appartiene alla tua organizzazione. Un gate che espone un token di scrittura o un segreto di produzione al codice che esamina può creare un problema peggiore di quello che doveva intercettare.

Proteggi l'identità del controllo con la stessa cura della sua logica. Le regole del branch richiedono di solito un nome di stato, quindi due workflow che possono segnalare lo stesso nome potrebbero consentire a un job più debole di soddisfare la regola. Dai al job di policy un nome univoco, limita chi può modificarne il workflow e richiedi la revisione da parte dei proprietari di quel file. Quando una coda di merge crea un nuovo commit di merge, esegui di nuovo i gate su quel commit oppure usa una funzionalità della piattaforma che colleghi i risultati alla revisione in coda. Le prove per la testa di ieri non sono prove per il merge di oggi.

Tratta la configurazione dei gate come codice sensibile. Una pull request che modifica una soglia, rimuove un percorso, declassa un pacchetto di query o aggiunge un'eccezione cambia il significato di ogni futuro risultato verde. Mostra chiaramente i diff della policy e richiedi un manutentore che conosca il controllo coinvolto. Un agente può proporre una modifica simile, ma non dovrebbe ottenere un passaggio più facile solo perché modifica il meccanismo che la giudica.

I test bloccano le regressioni osservabili

Il gate dei test deve bloccare qualsiasi modifica che rompa un comportamento specificato sulle versioni supportate di runtime e database. Deve eseguire gli stessi input di build che userà il commit di merge, comprese dipendenze bloccate, file generati, flag delle funzionalità e stato dello schema.

Gli agenti sono particolarmente bravi a soddisfare l'asserzione più vicina. Possono aggiungere un fallback che rende verde un test, rompendo però la gestione degli errori, l'impaginazione, la concorrenza o un contratto API adiacente. Richiedi alla pull request di aggiungere o modificare test quando cambia il comportamento, ma non misurare la qualità dal numero di nuove righe di test. Verifica se il test fallirebbe rimuovendo o ripristinando l'implementazione.

Un gate di test utile ha livelli con nomi distinti:

• Test unitari per la logica locale e i casi limite.
• Test di integrazione per contratti con database, code, cache e servizi esterni.
• Test di contratto per le forme pubbliche di richieste e risposte.
• Un piccolo smoke test sull'artefatto compilato.

Esegui fino in fondo i test instabili invece di concedere ritentativi automatici finché non diventano verdi. Un ritentativo può raccogliere prove diagnostiche, ma lo stato finale deve mostrare il fallimento iniziale. Altrimenti un agente può fondere codice la cui unica proprietà dimostrata è che a volte funziona.

Lo smoke test deve avviare l'artefatto, esercitare un endpoint di salute e un percorso di scrittura significativo, poi arrestarlo correttamente. Testare il codice sorgente senza avviare l'applicazione pacchettizzata non rileva file mancanti, valori predefiniti dell'ambiente errati, migrazioni rotte e crash all'avvio. Per un servizio web, il risultato può essere registrato in una forma compatta:

{"commit":"abc123","build":"pass","startup_ms":842,"health":200,"write_read_cycle":"pass"}

Non impostare una percentuale di copertura universale come gate principale. La copertura può rivelare una modifica non testata, ma un repository può raggiungere una percentuale alta con asserzioni deboli. Blocca in base alle suite obbligatorie e al comportamento modificato, poi usa la variazione della copertura come prova per la revisione.

Proteggi i test dall'implementazione che giudicano. Se una pull request cambia una regola e riscrive le asserzioni per accettare il nuovo risultato, la suite può superare i controlli mentre il contratto cambia silenziosamente. Richiedi a un revisore di confrontare i test modificati con l'API pubblica, il ticket o la regola di accettazione. Per parser, validatori, logica di fatturazione e controlli di accesso, aggiungi mutation testing o un piccolo insieme di input deliberatamente errati. La domanda utile è se la suite rifiuta una plausibile implementazione sbagliata, non se l'agente riesce a far soddisfare alla propria implementazione le asserzioni che ha scritto anch'esso.

Conserva gli artefatti dei test quando il gate fallisce. Memorizza il seed che fallisce per i test casuali, l'esatta immagine del database, i log del servizio privati dei segreti e il comando che riproduce l'esecuzione. Uno stato privo di dati di riproduzione rimanda l'agente o l'ingegnere successivo alle supposizioni. Limita la conservazione degli artefatti secondo le regole sui dati del repository e non caricare mai uno snapshot di produzione solo perché rende facile riprodurre un fallimento.

CodeQL blocca percorsi di codice noti verso vulnerabilità

Il gate CodeQL deve bloccare nuovi risultati ad alta attendibilità nei linguaggi e negli artefatti generati che CodeQL analizza davvero. Non deve far credere che un risultato pulito dimostri la sicurezza dell'intera applicazione.

GitHub descrive CodeQL come uno strumento che compila il codice in un database interrogabile ed esegue query su di esso. Questo modello è utile perché segue i dati attraverso il codice invece di cercare solo testo sospetto. È anche limitato dal supporto linguistico, dal successo della build, dalla selezione delle query e dal codice presente durante l'analisi. Se la build del database esclude silenziosamente un servizio, il risultato verde copre meno di quanto pensino i revisori.

Usa un workflow con linguaggi espliciti e una policy di query fissa:

name: codeql
on: [pull_request]
permissions:
  contents: read
  security-events: write
jobs:
  analyze:
    strategy:
      matrix:
        language: [javascript-typescript, go]
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: ${{ matrix.language }}
          queries: security-extended
      - uses: github/codeql-action/autobuild@v3
      - uses: github/codeql-action/analyze@v3

In un repository reale, fissa le azioni di terze parti a digest di commit revisionati. I tag rendono leggibile l'esempio, ma un tag modificabile amplia il perimetro di fiducia di un job di sicurezza obbligatorio.

Decidi cosa blocca prima che arrivi il primo avviso. Normalmente blocco i nuovi risultati alla soglia di gravità e precisione concordata dal repository, mentre il debito esistente rimane visibile in una baseline. Bloccare ogni risultato storico dal primo giorno incoraggia archiviazioni di massa. Ignorare tutti i risultati esistenti per sempre crea un punto cieco permanente. Assegna invece proprietari e scadenze alla baseline.

Ispeziona l'insieme dei file analizzati quando cambiano servizi, linguaggi o comandi di build. Una pull request che introduce un nuovo client mobile, un resolver generato o un backend separato può richiedere un altro analizzatore o un altro passaggio di build. “CodeQL superato” ha significato solo quando i revisori sanno dire cosa ha esaminato CodeQL.

Tieni distinti i fallimenti dell'analisi dalle analisi pulite. Se autobuild non riesce a compilare un pacchetto, il job deve segnalare un fallimento dell'infrastruttura o della configurazione, non zero risultati. Salva il log della creazione del database e il conteggio dei file sorgente analizzati per linguaggio. Confronta tali conteggi con il branch base e segnala una forte riduzione senza spiegazione. Così intercetti un fallimento comune: una modifica alla build esclude il modulo vulnerabile, l'analisi diventa più rapida e il controllo di sicurezza diventa verde perché ha visto meno codice.

Esamina le archiviazioni come modifiche di policy, non come pulizia. Un falso positivo richiede una spiegazione concreta collegata al percorso del codice e alla query. I commenti di soppressione devono essere circoscritti, avere un proprietario ed essere visibili nel diff della pull request. Un'esclusione valida per tutto il repository dei file generati può essere appropriata, ma prima accertati che in quella directory non ci siano template gestiti manualmente o input del generatore.

La revisione delle dipendenze ferma il rischio prima dell'installazione

La revisione delle dipendenze deve bloccare una pull request quando il suo diff di dipendenze introduce un pacchetto o una versione che viola una policy esplicita. Tale policy può includere gravità degli avvisi noti, licenze negate, fonti di pacchetti inattese e dipendenze dirette aggiunte senza proprietario.

Questo gate è diverso da un avviso di vulnerabilità del repository. Un avviso comunica che nel branch esiste una dipendenza vulnerabile. La revisione delle dipendenze chiede se questa pull request peggiora il grafo delle dipendenze. GitHub confronta manifest e lockfile nella pull request, rendendo la decisione tempestiva e attribuibile.

Richiedi coerenza del lockfile. Se un agente modifica package.json ma non il lockfile, oppure modifica il lockfile senza una modifica corrispondente al manifest, il job deve fallire. I comandi di installazione che risolvono versioni nuove durante la CI rendono il risultato non deterministico e possono testare un grafo diverso da quello visto dai revisori.

Una policy compatta potrebbe essere:

dependency_policy:
  fail_on_severity: high
  deny_licenses:
    - AGPL-3.0
  allow_sources:
    - registry.npmjs.org
    - proxy.golang.org
  require_owner_for_direct_additions: true

L'elenco esatto delle licenze è una decisione legale e di prodotto, non un valore da copiare alla cieca. La parte utile è che il repository lo dichiari e che il controllo stampi il pacchetto che lo ha attivato.

Non approvare automaticamente un pacchetto perché il suo nome assomiglia a una libreria suggerita. Gli agenti possono inventare nomi di pacchetti, scegliere fork abbandonati o aggiungere un client molto grande per un singolo aiuto banale. L'output della revisione deve mostrare i nuovi pacchetti diretti e transitivi, il registry di origine, la versione risolta, la licenza e lo stato degli avvisi. Un revisore può quindi chiedersi se il codice esistente o una dipendenza più piccola risolva già il problema.

In caso di impossibilità di produrre un diff da parte del servizio delle dipendenze, chiudi in sicurezza. Un feed di avvisi indisponibile può giustificare il blocco del merge, non la trasformazione dell'incertezza in un controllo verde. Le procedure di emergenza possono consentire un override documentato da parte di un manutentore nominato, con la motivazione allegata al commit.

Controlla il comportamento dell'installazione in un job isolato con accesso di rete limitato ai registry approvati. Gli script del ciclo di vita e i plugin di build eseguono codice durante l'installazione, quindi un pacchetto può essere pericoloso anche quando l'applicazione non lo importa mai. Registra se una nuova dipendenza aggiunge script di installazione, binari nativi o un registry sconosciuto. Non eseguire quel job con credenziali di pubblicazione, token cloud o una cache dei pacchetti scrivibile condivisa con build affidabili.

Il codice fornito dal fornitore e le immagini dei container fanno parte della stessa decisione, anche se l'ordinaria revisione del manifest può non rilevarli. Confronta digest delle immagini, nomi delle immagini base, sottomoduli Git e archivi inclusi nel repository. Richiedi digest immutabili per gli input di rilascio. Un tag amichevole come latest rende una pull request impossibile da riprodurre in seguito perché i byte possono cambiare senza un altro diff.

La scansione dei segreti deve ispezionare il diff e la sua cronologia

La scansione dei segreti deve bloccare quando una pull request introduce un modello di credenziale o un segreto attivo verificato, anche se la stringa compare in un fixture di test, in un file eliminato, in un bundle generato o in un commit precedente della pull request.

La protezione al push e la scansione delle pull request risolvono problemi correlati ma diversi. La protezione al push può fermare un segreto riconosciuto prima che raggiunga il remoto. Un gate della pull request esamina ciò che è già arrivato e può coprire contributori o tipi di token che la protezione al push ha mancato. Un avviso privo di protezione del branch non blocca il merge.

Scansiona l'intero intervallo di commit rispetto al branch base, non solo il filesystem finale. Un agente può aggiungere un token in un commit e rimuoverlo nel successivo: il token resta nella cronologia Git e può essere già arrivato a log o cache. Tratta il risultato come un'esposizione. Revoca o ruota la credenziale, rimuovila dalla cronologia proposta e riesegui il controllo.

Usa fixture sintetici che non possano autenticarsi. Un fixture deve identificarsi chiaramente e corrispondere a un modello di test definito localmente, invece di copiare la forma di una vera chiave cloud. Le allowlist ampie sono pericolose perché aggressori e incidenti trovano prima o poi la directory ignorata. Mantieni le eccezioni precise, revisionate e vicine alla configurazione del rilevatore.

Combina rilevatori basati su modelli con controlli di entropia e, dove il provider lo supporta in sicurezza, verifica delle credenziali. La corrispondenza per modello presenta meno rischi di rete e divulgazione, ma non intercetta token personalizzati. La verifica può ridurre l'incertezza, ma invia parte di un possibile segreto a un altro servizio e non deve mai essere eseguita contro un endpoint non attendibile fornito dalla pull request. Documenta quali rilevatori verificano, quali restano locali e quali dati escono dalla CI.

Scansiona le comuni forme codificate e gli output generati senza fingere che ogni stringa casuale sia una credenziale. Base64, codifica URL e bundle minimizzati possono nascondere un segreto apparso in chiaro in un passaggio del sorgente. Imposta la soglia bloccante usando fixture testati, poi esamina gli aggiornamenti dei rilevatori come le altre modifiche di policy. Uno scanner rumoroso abitua i manutentori a ignorare i risultati, mentre uno scanner silenzioso crea falsa fiducia.

L'output del gate deve indicare la posizione senza divulgare il segreto:

{"result":"fail","detector":"generic-api-token","commit":"abc123","path":"config/dev.env","line":7,"fingerprint":"sha256:8f2c..."}

Non stampare mai la corrispondenza completa nei log CI o in un commento della pull request. Mascherarla dopo che lo scanner ha emesso l'output può essere troppo tardi, perché sistemi di log, notifiche e artefatti del job possono copiarla.

La scansione dei segreti non sostituisce la revisione dei permessi del repository. Un workflow può leggere una credenziale di produzione senza inserirla nel diff e un agente può modificare un job di deployment per esfiltrarla. Tieni i segreti lontani dai job delle pull request, limita i permessi dei workflow e richiedi revisione umana per le modifiche alle definizioni CI.

I controlli di autorizzazione dimostrano che le azioni vietate restano vietate

Il gate di autorizzazione deve dimostrare che ogni operazione protetta rifiuta l'attore sbagliato e consente quello previsto al confine del servizio. I soli test di login non testano l'autorizzazione.

I team confondono spesso autenticazione, autorizzazione e visibilità dell'interfaccia utente. L'autenticazione stabilisce chi ha inviato la richiesta. L'autorizzazione decide se quell'identità può eseguire questa azione su questo oggetto. Nascondere un pulsante di amministrazione in React non modifica nessuna delle due decisioni su una API Go. Se il backend accetta la richiesta, l'applicazione resta esposta.

Crea una matrice dei permessi per endpoint e azioni di business modificati. Mantienila abbastanza piccola da poterla esaminare, ma includi confini di proprietà e tenant:

read_private_project:
  anonymous: deny
  member: deny
  other_tenant: deny
  owner: allow
  admin: allow
update_project:
  anonymous: deny
  other_tenant: deny
  owner: allow

Genera test da questa matrice oppure codifica casi equivalenti guidati da tabelle nel linguaggio del servizio. Ogni caso di rifiuto deve chiamare l'handler reale con identificatori realistici. I mock che sostituiscono il middleware di autorizzazione possono dimostrare che la route funziona saltando il controllo oggetto del test.

Testa l'accesso a livello di oggetto, non solo i ruoli. Due utenti possono avere entrambi il ruolo member pur appartenendo a organizzazioni diverse. Modifica in modo indipendente l'identificatore della risorsa e quello del tenant per intercettare riferimenti diretti a oggetti non sicuri. Testa anche endpoint bulk, esportazioni, job in background e resolver GraphQL, che spesso aggirano i controlli scritti per gli handler REST ordinari.

Fai fallire il gate quando una nuova route protetta non ha una mappatura di policy. Così l'autorizzazione mancante passa da intuizione del revisore a difetto misurabile. Mantieni il valore predefinito sul server come rifiuto. Una regola di autorizzazione esplicita è più facile da verificare rispetto a codice disperso che rifiuta pochi casi negativi noti.

Gli agenti riutilizzano spesso un handler vicino e mantengono il suo percorso felice, eliminando però il controllo di proprietà. La matrice dei permessi rende visibile questa omissione. Offre anche ai revisori un contratto stabile quando ruoli o regole dei tenant cambiano in seguito.

Esercita l'autorizzazione dopo la normalizzazione dell'input. Normalizzazione delle maiuscole, formati alternativi degli identificatori, parametri di query duplicati e riferimenti a oggetti annidati possono inviare richieste equivalenti attraverso percorsi di codice diversi. Testa l'endpoint diretto e ogni route batch o di importazione che raggiunge la stessa operazione. Se un worker in background esegue la scrittura finale, propaga il contesto di attore e tenant nel job invece di trattare il worker come un utente attendibile onnipotente.

Registra la decisione prevista e la regola di policy che l'ha prodotta, evitando però di esporre dati di oggetti privati nei log. Un fallimento utile indica classe dell'attore, azione, classe dell'oggetto e stato previsto. Non scarica il token di accesso o il record completo. Queste prove consentono a un revisore di distinguere un fixture di test rotto da un vero cambiamento dei privilegi.

La prova della migrazione misura blocchi e reversibilità

Il gate di migrazione deve applicare ogni modifica proposta allo schema a una copia simile alla produzione, eseguire verifiche di compatibilità e registrare durata, blocchi e comportamento di rollback prima del merge. Una migrazione che riesce su un database di test vuoto dimostra ben poco.

Usa uno snapshot anonimizzato o un set di dati generato con dimensioni di tabelle, indici, vincoli e distribuzione simili. I dati esatti di produzione non devono entrare nell'infrastruttura delle pull request. L'obiettivo è ricreare la pressione operativa senza copiare record personali o riservati.

Prova la sequenza di deployment reale. Se le vecchie istanze dell'applicazione restano attive mentre la migrazione viene eseguita, testa il vecchio codice con il nuovo schema e il nuovo codice con lo schema transitorio. Aggiungere una colonna nullable è di solito compatibile. Rinominare una colonna in un solo passaggio può rompere ogni vecchia istanza ancora in servizio.

Registra le prove in un risultato leggibile dalla macchina:

{"migration":"20260727_add_project_state","apply_ms":18420,"max_lock_ms":310,"old_app_probe":"pass","new_app_probe":"pass","down":"pass"}

Imposta soglie per database e classe di tabella. Un blocco di 300 millisecondi può essere innocuo per una tabella e dannoso per un'altra. I revisori devono vedere il limite scelto accanto al risultato misurato, oltre alla versione del database usata durante la prova.

Per PostgreSQL, ispeziona le operazioni che riscrivono una tabella, convalidano un vincolo o creano un indice bloccando le scritture. Preferisci modifiche di espansione e contrazione: aggiungi la nuova forma, distribuisci codice che possa usare entrambe le forme, esegui il backfill in batch controllati, sposta le letture, poi rimuovi la vecchia forma in una modifica successiva. Una pull request in più costa meno dell'improvvisazione durante un'interruzione.

Non tutte le migrazioni possono avere un'operazione down sicura. Eliminare una colonna perde dati e invertire una trasformazione può essere ambiguo. In questi casi, il gate deve richiedere una procedura di recupero in avanti e un punto di ripristino da backup testato. Definire “sicura per il rollback” una migrazione irreversibile perché esiste un file down non è onesto.

Testa ritentativi e fallimenti parziali. Un deployment può interrompersi dopo aver creato un indice ma prima di registrare la migrazione come completata, e il tentativo successivo non deve corrompere lo stato o fallire per sempre. Interrompi la prova a un confine controllato, rieseguila e verifica che schema e registro delle migrazioni concordino. Per un backfill lungo, dimostra che i batch riprendono da un cursore registrato e che eseguire due volte un batch non duplica né elimina dati.

Controlla gli effetti su disco e replica oltre al tempo trascorso. La riscrittura di una tabella può consumare spazio temporaneo, espandere i write ahead log e ritardare le repliche dopo che l'operazione primaria appare completata. Il gate non deve offrire una previsione perfetta della produzione, ma deve registrare tali quantità sul set di dati della prova e confrontarle con i limiti scelti dal proprietario del database. Senza queste prove, una migrazione locale veloce può comunque esaurire un volume di produzione.

La verifica del rollback deve eseguire il percorso di ripristino

Il gate di rollback deve distribuire il candidato in un ambiente isolato, creare uno stato rappresentativo, attivare il metodo di rollback supportato e dimostrare che la versione precedente continua a servire correttamente letture e scritture. Un piano di rollback scritto non è una verifica.

Separa il rollback dell'applicazione da quello dei dati. Reindirizzare il traffico al binario precedente può richiedere pochi secondi, mentre annullare una trasformazione distruttiva di schema o dati può essere impossibile. Il gate deve riferire entrambi. Se la vecchia applicazione non può funzionare con il nuovo schema, contrassegna il candidato come non reversibile e richiedi un piano di deployment graduale.

Una sequenza pratica è:

1. Distribuisci il commit principale corrente e crea record rappresentativi.
2. Aggiorna all'artefatto della pull request ed esercita i percorsi modificati.
3. Crea nuovi record nello stato aggiornato.
4. Ripristina l'artefatto o lo snapshot precedente usando il controllo documentato.
5. Esegui verifiche di lettura, scrittura, code e job in background.

Il controllo deve conservare identificatori degli artefatti, identificatori degli snapshot, timestamp e risultati delle verifiche. Non deve conservare credenziali o dati dei clienti copiati. Misura il tempo di recupero come prova per il tuo obiettivo operativo, non come promessa universale.

Gli snapshot aiutano solo se qualcuno dimostra che contengono tutto ciò di cui l'applicazione ha bisogno. File, object storage, stato delle code, modifiche dello schema ed effetti collaterali esterni possono risiedere fuori da uno snapshot del server. Elenca tali confini nel risultato. Un pagamento, un'email o un webhook già inviato non può essere ritirato ripristinando un database.

Rendi la verifica del rollback più robusta di un controllo di salute. Leggi un record creato prima dell'aggiornamento, uno creato dopo, aggiorna entrambi dove la compatibilità lo consente ed elabora un job in coda creato da ogni versione dell'applicazione. Confronta l'output visibile all'utente, non solo i codici di stato. Un server che restituisce 200 mentre elimina un nuovo campo o interpreta male un enum non è stato ripristinato.

Testa il controllo usato dalla persona reperibile. Se il rollback in produzione richiede la selezione di un artefatto, il ripristino di uno snapshot o la modifica del traffico, la prova isolata deve usare la stessa interfaccia e lo stesso percorso di permessi. Uno script privato sul portatile di un ingegnere non è un controllo operativo. Le prove devono mostrare che il ruolo operatore designato può completare il recupero senza ottenere accesso permanente da amministratore.

Koder.ai supporta l'esportazione del codice sorgente, il deployment e l'hosting, gli snapshot e il rollback, quindi le applicazioni create lì possono usare questi artefatti concreti in questo gate invece di trattare il ripristino come un paragrafo della pull request. La stessa regola vale su qualsiasi piattaforma: esegui il controllo di recupero e verifica l'applicazione ripristinata.

Un controllo obbligatorio dovrebbe riassumere tutti e sette

La decisione finale di merge deve richiedere un controllo di policy stabile che verifichi i sette risultati sottostanti per l'esatto commit di testa. I nomi dei singoli job cambiano, i job a matrice si moltiplicano e percorsi opzionali saltano il lavoro. Un piccolo aggregatore impedisce alla protezione del branch di allontanarsi dalla policy.

Fai emettere a ogni gate un risultato firmato o attestato dalla piattaforma, contenente commit, versione della policy, esito e posizione delle prove. L'aggregatore rifiuta risultati mancanti, obsoleti, neutri o annullati. Non deve mai dedurre il successo da un job che non ha riportato un risultato.

{
  "commit": "abc123",
  "policy": "merge-gates-v3",
  "results": {
    "tests": "pass",
    "codeql": "pass",
    "dependency_review": "pass",
    "secret_scan": "pass",
    "authorization": "pass",
    "migration_rehearsal": "not_applicable",
    "rollback_verification": "pass"
  },
  "decision": "allow"
}

Definisci un percorso di override ristretto perché le emergenze accadono. Richiedi un manutentore nominato, una seconda approvazione, una motivazione scritta, una scadenza e un ticket di follow-up. Non lasciare che l'agente richieda o approvi la propria eccezione. Riporta gli override nello stesso punto dei risultati ordinari dei gate, così restano visibili anche dopo l'incidente.

Questi controlli aggiungeranno minuti ad alcune pull request e molto più tempo alle modifiche di migrazione. Va bene quando quel tempo acquista prove specifiche. Esegui presto i gate economici, annulla i commit superati, metti in cache gli input di build affidabili e riserva la prova completa dell'ambiente ai percorsi pertinenti. Non indebolire un gate solo per rendere più rapidamente verde la dashboard.

Inizia rendendo osservabile il comportamento attuale. Inserisci tutti e sette i nomi in un file di policy, collega ciascuno a un risultato obbligatorio e costringi il lavoro saltato a spiegarsi. La prima pull request di un agente che non riesce a produrre quel record ha trovato un buco nel sistema di consegna prima di trovarne uno in produzione.