Esempi di implementazione della governance delle PR con modelli, controlli, CODEOWNERS, regole e gate di ambiente
In questa unità si apprenderà quanto segue:
Come le richieste di pull agiscono come punti di controllo architetturali per l'esecuzione degli agenti.
Come applicare la validazione del piano con i controlli di stato richiesti
Come usare CODEOWNERS e le revisioni per instradare e approvare le modifiche
Le richieste pull sono punti di controllo architetturali
Le richieste pull sono il meccanismo di controllo principale per l'esecuzione dell'agente in GitHub. Anziché consentire modifiche dirette ai rami protetti, le architetture ben progettate instradano le modifiche dell'agente tramite pull request e applicano i requisiti di merge attraverso politiche.
Un flusso di lavoro sicuro comune è simile al seguente:
Agent crea un ramo
↓
Agent apre il pull request (include pianificazione)
↓
Le revisioni necessarie convalidano l'approccio
↓
GitHub Actions eseguire i controlli necessari
↓
Tutti i controlli sono superati e le approvazioni sono completate.
↓
La richiesta pull può essere unita
Questa struttura garantisce che l'esecuzione venga controllata sia dall'automazione che dalla revisione umana.
Implementazione: template di PR che richiede un piano strutturato
Ogni modello di richiesta pull garantisce che ogni richiesta pull di un agente fornisca sezioni coerenti di piano e di prova.
<!-- File: .github/pull_request_template.md -->
## Plan (required)
- **Goal:**
- **Scope (paths/files):**
- **Steps:**
1.
2.
3.
- **Success criteria (verifiable):**
- [ ] Required checks pass
- [ ] Security signals reviewed (as applicable)
- **Risks + mitigations:**
- **Rollback / escalation plan:**
## Evidence
- Workflow run(s):
- Scan results (if applicable):
## Review checklist
- [ ] Plan reviewed and approved
- [ ] Required reviews satisfied
- [ ] Required checks satisfied
Applicazione della convalida del piano con le verifiche di stato richieste
Oltre ai modelli, è possibile applicare il controllo del piano come controllo di stato obbligatorio. Ciò trasforma un'aspettativa di processo ("includere un piano") in una garanzia di sistema.
# File: .github/workflows/plan-gate.yml
name: Plan Gate
on:
pull_request:
branches: [ main ]
jobs:
require-plan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Require plan artifact
run: |
if [ ! -f "Github/pull_request_template.md" ]; then
echo "Github/pull_request_template.md is required for this pull request."
exit 1
fi
echo "Github/pull_request_template.md found."
Nota di implementazione:
Un amministratore del repository può contrassegnare Plan Gate come controllo di stato obbligatorio utilizzando i set di regole e la protezione dei rami, garantendo che le richieste di pull non possano essere unite a meno che il piano non esista.
GitHub può richiedere l'approvazione esplicita prima dell'esecuzione dei flussi di lavoro sulle modifiche generate dall'agente.
Uso di CODEOWNERS per garantire la sicurezza
CODEOWNERS garantisce che le modifiche alle aree sensibili vengano automaticamente apportate ai revisori corretti.
# File: CODEOWNERS
/security/ @security-team
/.github/workflows/ @platform-team
/infra/ @platform-team
* @core-team
Ciò garantisce che un piano e un set di modifiche che interessano i percorsi ad alto rischio non possano essere uniti senza visibilità dagli esperti giusti (se combinati con i criteri di revisione necessari).
Fare attenzione all'esecuzione senza convalida
Se un agente può ignorare i controlli necessari o eseguire l'unione senza revisioni, l'architettura perde i meccanismi di sicurezza principali. Questo è meno un problema del modello e più un errore di progettazione del flusso di lavoro.
Conclusione principale: Le richieste di pull non sono solo strumenti di collaborazione, ma sono meccanismi di applicazione.
Successivamente, si definirà la quantità di autonomia che l'agente deve avere in base al rischio dell'attività.