Il nuovo numero di GRC Engineer di Ayoub Fandi riguarda i controlli di change management che continuano a registrare schermate di approvazione delle PR mentre il significato dell'approvazione stessa diminuisce. La produttività degli agenti è aumentata. Il tempo di revisione no. Il segno di spunta verde sembra ancora quello del 2020. Quello che attesta non è più lo stesso.
Ha ragione. Noi aggiungeremmo questo: la mossa che la maggior parte dei team farà è rimettere un essere umano sulla PR. Questo produce comunque la stessa schermata. Non specifica cosa la persona ha dovuto esaminare. E la regola scritta che stabilisce chi deve revisionare fatturazione, pagamenti o qualsiasi cosa con impatto critico può essere commentata in una hotfix che tutti sono felici di unire.
La schermata non distingue i due anni
Un'approvazione su una pull request registra che il flusso di lavoro ha raggiunto un passaggio di approvazione prima del merge. La schermata non registra cosa il revisore ha esaminato, quanta attenzione ha dedicato o quali regole scritte ha verificato. È comunque l'artefatto che la maggior parte dei controlli di change management chiede all'auditor di campionare, perché è l'artefatto che la definizione del controllo nomina ancora.
Ayoub descrive il degrado partendo dai report dell'ingegneria stessa: maggiore produttività, PR più grandi, la revisione come nuovo collo di bottiglia. Cita un articolo del blog di GitHub che riassume uno studio esterno: le modifiche create dagli agenti mostravano più ridondanze e debiti tecnici, mentre il sentiment dei revisori era più neutro o positivo. La schermata che il tuo catalogo continua a raccogliere non distingue questi due anni. Il segno di spunta è ancora verde. L'attenzione dietro di esso non è la stessa.
Rimettere un essere umano registra comunque la stessa prova
La riscrittura allettante è quella di recuperare tempo: richiedere una persona, ridurre il diff, aggiungere un altro approvatore. Per alcune modifiche è la scelta giusta. È anche la riscrittura che lascia intatta la definizione del controllo. Continui a raccogliere una schermata di un'approvazione. Non hai ancora scritto cosa quell'approvazione è autorizzata ad attestare.
Il tempo di revisione residuo, quando lo ottieni, va alle domande che la code review già conosce. La hotfix è corretta? È sicura? Sono domande reali. Non sono la domanda 'questa modifica ha appena eliminato la regola che una PR di fatturazione richiede un proprietario di dominio'. Un revisore che fissa lo sguardo sui calcoli delle fatture approverà la modifica a CODEOWNERS come rumore.
Il tipo di modifica
Considera questo come illustrativo: il tipo di modifica che solleva la domanda, non un incidente del cliente. La hotfix nel resto della PR può essere pulita. Questa riga è la regola di change management che diventa falsa.
# domain owners/infra/ @platform-owners-/billing/ @billing-owners+# /billing/ @billing-owners # unblocking the invoice hotfix/docs/ @docs-ownersNon è un bug e non è una vulnerabilità. CC8.1 riguarda il change management: le modifiche devono essere autorizzate, revisionate e approvate tramite il processo che hai documentato. Questa riga rappresentava la revisione indipendente per la fatturazione. Commentarla significa che la prossima PR di fatturazione può essere unita con un'approvazione generica. La schermata esisterà comunque. La regola scritta che le modifiche di fatturazione richiedono un proprietario di dominio no.
Riscrivi il controllo, non solo il numero di persone
Il numero di Ayoub è un avvertimento: non difendere il rituale delle PR più duramente solo perché la schermata sembra ancora ufficiale. Siamo d'accordo. L'errore aggiuntivo è che la riscrittura che la maggior parte dei team pubblicherà questo trimestre chiede comunque quella schermata, e la regola che definiva la revisione può essere modificata in una PR che nessuno ha letto come una modifica al controllo.
Se stai riscrivendo il change management per la velocità degli agenti, scrivi cosa 'revisionato' è autorizzato a significare e tratta le modifiche a quella definizione come in ambito per lo stesso controllo. Un percorso in CODEOWNERS, un controllo obbligatorio, un'esenzione in CODEOWNERS, un'eccezione nella protezione del branch: questi sono il controllo. Non sono commenti di routine su una hotfix.
Dove si posiziona heygrc
heygrc non è la newsletter, il workshop o un sostituto delle revisioni di bug e sicurezza che già esegui. È lo strato che legge ogni pull request rispetto ai framework che hai scelto e al contesto che gli hai fornito. Quando una modifica renderebbe difficile difendere una regola di change management o di percorso di revisione, lo segnalerà sul diff. Non unisce nulla. Pone la domanda sulla pull request, prima che l'audit campioni una schermata che non significa più quello che il controllo afferma.
Leggi il numero di Ayoub. Il degrado della schermata è suo. La domanda aggiuntiva è: cosa succede quando riscrivi il controllo e continui a raccogliere solo la schermata.