Dein Blog zum Thema digitales Business

Eine Datei, die einmal stimmte

Du legst eine CODEOWNERS-Datei an, ordnest Verzeichnisse Personen oder Teams zu, aktivierst in den Branch-Protection-Regeln die Pflicht zur Code-Owner-Freigabe — und hast damit, an dem Tag, eine nachvollziehbare Zuständigkeit für jeden Pfad im Repository. Das Problem ist nicht dieser Tag. Das Problem ist der 400. Tag danach, an dem zwei der fünf eingetragenen Personen das Unternehmen verlassen haben, ein Team umbesetzt wurde und niemand die Datei seither angefasst hat, weil sie ja „läuft“.

Sie läuft tatsächlich weiter — nur nicht mehr so, wie ihr Name es verspricht.

Was GitHub tut, wenn ein Owner nicht mehr gültig ist

GitHubs Dokumentation zu Code Owners beschreibt den Fall ausdrücklich: Ist eine in der Datei genannte Person oder ein Team nicht mehr auffindbar oder verfügt nicht mehr über ausreichenden Zugriff, wird für den betroffenen Pfad schlicht kein Code Owner zugewiesen (docs.github.com, Abschnitt „About code owners“). Konkret verlangt GitHub für Einzelpersonen wie für Teams explizit Schreibzugriff auf das Repository, damit ein Eintrag überhaupt als Owner zählt — auch wenn einzelne Teammitglieder diesen Zugriff über andere Wege bereits hätten.

Das heißt in der Praxis: Verliert eine ausgeschiedene Person ihren Zugriff auf das Repository — üblicherweise Teil des Offboardings —, bleibt ihr Name zwar in der CODEOWNERS-Datei stehen, zählt aber nicht mehr als Owner. Für den betroffenen Pfad greift die Pflichtprüfung dann nicht mehr, ohne Fehlermeldung, ohne Warnung im Pull Request. Ein Merge auf genau diesem Pfad braucht ab diesem Moment keine Code-Owner-Freigabe mehr, obwohl die Branch-Protection-Regel nach außen unverändert „Require review from Code Owners“ sagt.

Teams sind kein Sicherheitsnetz

Bei Teams liegt der Fehler andersherum. Ein Team-Eintrag zählt laut GitHub, solange das Team sichtbar ist und selbst über Schreibrechte verfügt — diese Berechtigung hängt am Team als Objekt, nicht an der Zahl seiner Mitglieder. Ein Team, aus dem im Lauf der Zeit jedes einzelne Mitglied ausgetreten oder entfernt worden ist, bleibt damit ein technisch gültiger Code Owner. Nur kann diesen Owner-Status niemand mehr ausfüllen: Es gibt keine Person mehr, die im Namen des Teams freigeben könnte. Eine Pflichtprüfung, die an ein leeres Team hängt, blockiert den Merge dauerhaft, bis jemand mit Admin-Rechten die Regel manuell umgeht oder das Team neu besetzt.

Damit stehen sich zwei entgegengesetzte, aber gleich unbemerkte Fehlerbilder gegenüber: Der einzelne ausgeschiedene Owner lässt eine Pflichtprüfung lautlos verschwinden, das leergelaufene Team lässt sie lautlos zur Sackgasse werden. Beides entsteht aus derselben Ursache — einer Datei, die seit ihrer Anlage nicht mehr gegen den tatsächlichen Personalstand geprüft wurde.

Syntax kurz zur Erinnerung

Eine CODEOWNERS-Datei folgt Gitignore-ähnlichen Pfadmustern, wobei bei mehreren passenden Zeilen die zuletzt passende Regel gewinnt:

# Fallback: ohne spezifischere Regel zuständig
*                       @org/platform-team
# Verzeichnis mit Einzelperson
/infrastructure/        @mmustermann
# Team-Zuständigkeit für einen Teilbaum
/services/payments/     @org/payments-team
# Einzelne Datei, mehrere Owner
/deploy/prod.yaml       @org/platform-team @org/security-team

Diese Syntax ist stabil und selten die Fehlerquelle. Der Fehler entsteht nicht beim Schreiben der Datei, sondern beim Nichtaktualisieren.

Pflege als eigener Prozess

Aus der Doku folgt unmittelbar, was zu tun ist: Die Gültigkeit jedes Eintrags hängt an Zugriffsrechten, die sich ändern, ohne dass die Datei sich mitändert. GitHub prüft das nicht von selbst und warnt auch im Pull Request nicht sichtbar davor, dass eine Regel gerade wirkungslos geworden ist. Ein regelmäßiger Abgleich ist deshalb kein Kür-Punkt, sondern die einzige Stelle, an der ein stiller Ausfall auffällt. Ein einfacher Baustein dafür ist eine Abfrage der aktuellen Team-Mitgliederzahl gegen jedes Team, das in der Datei als Owner auftaucht:

gh api orgs/ORG/teams/payments-team/members --jq 'length'

Liefert dieser Aufruf 0, ist der entsprechende Eintrag in der CODEOWNERS-Datei ab sofort ein blockierender Totpunkt, kein Reviewer. Für einzelne Personen ist die Vergleichsgröße nicht die Team-Mitgliederzahl, sondern der tatsächliche Collaborator-Status im Repository — beide Prüfungen gehören in denselben wiederkehrenden Rhythmus wie jede andere Zugriffsbereinigung, nicht in ein einmaliges Setup-Kapitel.

Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Alles Weitere richtet sich nach der Lage und läuft über drei Felder: Implementation, also Delivery und Nachweis modulweise in die Pipeline einziehen, AI Governance, also Nachvollziehbarkeit bei KI-gestützten Build- und Deployment-Schritten, und Maintenance, also die Frage, wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem mehr gehört. Ein festes Angebot daraus entsteht erst, wenn klar ist, was der Kunde wirklich braucht. Kontakt: mm@mhm-dl.de