Esempi di implementazione della governance delle PR con modelli, controlli, CODEOWNERS, regole e gate di ambiente

Completato

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à.