Beispiele für die Implementierung von PR-Governance mit Vorlagen, Überprüfungen, CODEOWNERS, Regeln und Umgebungsschranken

In dieser Lektion lernen Sie Folgendes:

• Funktionsweise von Pullanforderungen als Architektursteuerungspunkte für die Agentausführung

• So wird Planvalidierung mit erforderlichen Statusprüfungen erzwungen

• Verwendung von CODEOWNERS und Reviews zum Zuordnen und Genehmigen von Änderungen

Pull-Anforderungen sind architektonische Kontrollpunkte

Pullanforderungen sind der primäre Kontrollmechanismus für die Agentausführung in GitHub. Anstatt direkte Änderungen an geschützten Verzweigungen zuzulassen, leiten gut gestaltete Architekturen Agent-Änderungen über Pull-Anfragen weiter und erzwingen Zusammenführungsanforderungen durch Richtlinien.

Ein allgemeiner sicherer Workflow sieht wie folgt aus:

Agent erstellt Branch

↓

Agent öffnet Pull-Request (einschließlich Plan)

↓

Erforderliche Überprüfungen validieren den Ansatz

↓

GitHub Actions erforderliche Prüfungen ausführen

↓

Alle Prüfungen bestehen + Genehmigungen abgeschlossen

↓

Pull-Anforderung kann zusammengeführt werden

Diese Struktur stellt sicher, dass die Ausführung sowohl durch automatisierte als auch durch menschliche Überprüfung gesteuert wird.

Implementierung: PR-Vorlage, die einen strukturierten Plan erfordert

Eine Pull-Anforderungsvorlage stellt sicher, dass jede Agent-PR konsistente Plan- und Nachweisabschnitte bereitstellt.

<!-- 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

So wird Planvalidierung mit erforderlichen Statusprüfungen erzwungen

Zusätzlich zu Vorlagen kann Plan-Gating als erforderliche Statusüberprüfung erzwungen werden. Dies wandelt eine Prozesserwartungen ("Einen Plan einschließen") in eine Systemgarantie um.

# 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."

Implementierungshinweis:

Ein/eine Repositoryadministrator(in) kann Plan Gate als erforderliche Statusüberprüfung mithilfe von Regelsätzen/Verzweigungsschutz markieren, um sicherzustellen, dass PRs nicht zusammengeführt werden können, es sei denn, ein Plan ist vorhanden.

GitHub kann explizite Genehmigungen erfordern, bevor Workflows bei von einem Agenten generierten Änderungen ausgeführt werden.

Verwenden von CODEOWNERS zur Gewährleistung der Sicherheit

CODEOWNERS stellt sicher, dass Änderungen an sensiblen Bereichen automatisch an die richtigen Prüfer gehen.

# File: CODEOWNERS

/security/ @security-team
/.github/workflows/ @platform-team
/infra/ @platform-team
* @core-team

Dadurch wird sichergestellt, dass ein Plan und eine Änderung, die sich auf risikoreiche Pfade auswirkt, nicht zusammengeführt werden kann, ohne dass die richtigen Experten (in Kombination mit den erforderlichen Überprüfungsrichtlinien) sichtbar sind.

Seien Sie vorsichtig bei der Ausführung ohne Validierung

Wenn ein Agent erforderliche Prüfungen umgehen oder ohne Überprüfungen zusammenführen kann, verliert die Architektur ihre primären Sicherheitsmechanismen. Dies ist weniger ein Modellproblem und mehr ein Workflowentwurfsfehler.

Wichtige Erkenntnis: Pull-Anforderungen sind nicht nur Tools für die Zusammenarbeit– sie sind Erzwingungsmechanismen.

Als Nächstes definieren Sie, wie viel Autonomie der Agent auf der Grundlage des Risikos der Aufgabe haben soll.