Release-Prozess: Eigentum, Rollen und Freigaben

Im Salesforce-Release-Prozess gehören Repository, Pipeline, DevOps-Werkzeug, Sandboxes und Zugangsdaten Ihnen als Auftraggeber. Partner arbeiten darin mit persönlichen Benutzern. Vier Rollen tragen den Prozess: ein Release Manager und ein Architekt auf Kundenseite, ein technischer Lead pro Partner und Product Owner im Fachbereich. Wer was freigibt, steht in einer Matrix und wird in der Git-Plattform technisch durchgesetzt, nicht nur in einem Konzept. Die Regeln für alle Partner stehen gleichlautend im Vertrag. Dann ist ein Partnerwechsel ein geplanter Vorgang: Benutzer entziehen, Zertifikate erneuern, weiterarbeiten.

Was sollte Ihnen als Auftraggeber gehören?

Kapitel 1 hat die Grundannahme gesetzt: Der Release-Prozess gehört Ihnen. Konkret heißt das, dass Verträge, Lizenzen und Admin-Rechte der folgenden Bausteine auf Ihren Namen laufen. Besitzen heißt dabei nicht, eigene Server zu betreiben. Eine GitHub-Organisation in der Cloud reicht, solange sie Ihnen gehört.

Baustein	Gehört	Partner erhalten
Git-Repository und Organisation auf der Git-Plattform	Ihnen, mit mindestens zwei internen Admins	Schreibrechte auf Feature-Branches, keine Admin-Rechte
Pipeline-Konfiguration und CI-Variablen	Ihnen	Lesezugriff, Änderungen nur per Pull Request
DevOps-Werkzeug (sfdx-hardis-Konfiguration, Gearset-Team, Copado- oder Flosum-Org)	Ihnen	persönliche Lizenz oder Benutzer, zugewiesen von Ihnen
Produktion, Sandboxes, Dev Hub	Ihnen	Benutzer pro Person, Rechte passend zur Stufe
Zertifikate, technische Benutzer, Integrationszugänge zu SAP	Ihnen, im eigenen Tresor	keinen direkten Zugriff
Backlog, Wiki, Standards	Ihnen	Bearbeitungsrechte im Projekt

Wie das bei den Werkzeugen aussieht, hängt vom Produkt ab. Bei sfdx-hardis liegt die Konfiguration als Dateien im Repository, wer das Repository besitzt, besitzt also den Prozess. Bei Gearset verwalten laut Gearset-Dokumentation (öffnet in einem neuen Tab) nur Team Owner die Zuweisung der Lizenzen, und wer aus dem Team entfernt wird, verliert sofort den Zugriff auf die gemeinsame Historie, während die Historie beim Team bleibt. Das ist genau das Verhalten, das Sie wollen, aber nur, wenn das Team Ihnen gehört. Flosum ist laut Hersteller (öffnet in einem neuen Tab) Salesforce-nativ, läuft also auf der Salesforce-Plattform selbst. Achten Sie dort darauf, dass die Org, in der Flosum läuft, Ihnen gehört. Welches Werkzeug zu Ihnen passt, vergleicht Kapitel 4. Für dieses Kapitel zählt nur: Wer den Vertrag des Werkzeugs hält, entscheidet, wer Zugriff hat.

Warum das auch für Jira, Confluence und Miro gilt und wie Sie einen Umzug planen, wenn ein Partner heute Teile davon besitzt, beschreibe ich in warum Kunden ihre DevOps-Tools selbst besitzen sollten.

Welche Rollen braucht ein Release-Prozess?

In Programmen mit mehreren Partnern entsteht leicht dieselbe Lücke: Jeder Partner verantwortet seinen Stream, niemand das Ganze. Vier Rollen schließen sie. Eine Person kann in kleinen Programmen zwei Rollen tragen, die Verantwortung muss trotzdem benannt sein.

• Release Manager (Kundenseite). Verantwortet Pipeline, Release-Kalender und jede Promotion von Integration über UAT bis Produktion. Die Release-Manager-Anleitung von sfdx-hardis (öffnet in einem neuen Tab) beschreibt die Aufgaben gut: Validierungsjobs prüfen, Konflikte lösen, in die Stufen-Branches mergen, Hotfixes ausliefern und danach zurück in die Entwicklungs-Branches bringen, Release Notes und DORA-Kennzahlen erzeugen. Laut derselben Seite übernehmen das ein oder zwei Teammitglieder, in kleinen Projekten ein Tech Lead oder erfahrener Admin in Teilzeit.
• Architekt (Kundenseite). Schreibt die Entwicklungs- und Architekturstandards, gibt architekturrelevante Änderungen frei (neue Objekte, Schnittstellen, Sharing, Rechtekonzept) und entscheidet, wenn zwei Streams dasselbe Objekt brauchen. Welcher Stream welches Objekt verantwortet, steht in einer Object Ownership Matrix.
• Technischer Lead pro Partner. Sorgt dafür, dass die Pull Requests seines Teams vollständig, klein und geprüft ankommen, macht das erste Review im eigenen Stream und liefert die Angaben für die Release Notes. Er hat keine Freigaberechte für Stufen, die andere Partner betreffen.
• Product Owner im Fachbereich. Etwa die Serviceleitung für Field Service oder die Vertriebsleitung für das Händlerportal. Nimmt Stories in UAT ab und entscheidet fachlich, ob eine Funktion mit dem nächsten Release für Anwender freigeschaltet wird.

Die Release-Rolle ist die, an der am häufigsten gespart wird. Meine Position dazu steht in mehreren Artikeln: Wer mit einem Open-Source-Werkzeug wie sfdx-hardis Lizenzkosten spart, investiert das Geld am besten in eine interne Release-Rolle. Bei kommerziellen Plattformen wie Gearset, Copado oder Flosum gilt dasselbe. Ihr Vorteil ist, dass sich Rollen und Freigaben in einer Oberfläche einrichten lassen und der Hersteller Support leistet; verantworten muss die Freigaben trotzdem ein Mensch auf Ihrer Seite. Mehr dazu steht in warum DevOps über Salesforce-Großprojekte entscheidet.

Freigaben in einer Matrix und in der Git-Plattform

Eine Freigabematrix beantwortet für jede Art von Änderung zwei Fragen: Wer prüft, und wer entscheidet? So sieht ein Ausgangspunkt aus, den ich mit Ihnen an Ihre Streams anpassen würde:

Änderung	Prüft	Gibt frei
Pull Request innerhalb eines Streams	zweiter Entwickler oder Lead des Partners	Lead des Partners, bei grüner Pipeline
Änderung an einem Objekt, das ein anderer Stream verantwortet	Lead des verantwortlichen Streams	Architekt
Neues Objekt, neue Schnittstelle, Sharing oder Permission-Konzept	Architekt	Architekt
Promotion nach UAT	Release Manager	Release Manager
Release nach Produktion	Release Manager, Product Owner	Product Owner fachlich, Release Manager technisch
Hotfix	Architekt oder Lead	Release Manager und betroffener Product Owner
Pipeline, Branch-Schutz, Werkzeugkonfiguration	Release Manager	nur Kundenseite

Was ein gutes Review prüft und wie es schnell bleibt, beschreibe ich in warum Pull-Request-Reviews Pflicht sind. Hier geht es um die Durchsetzung, denn eine Matrix im Wiki hält niemanden auf.

In der Git-Plattform

Bei GitHub verlangen geschützte Branches (öffnet in einem neuen Tab) eine Mindestzahl an Freigaben und grüne Statusprüfungen vor dem Merge. Zwei Details übersehen viele. Admins sind standardmäßig von den Regeln ausgenommen, bis Sie „Do not allow bypassing the above settings“ aktivieren. Und in privaten Repositories gibt es geschützte Branches erst ab GitHub Pro, Team oder Enterprise. Eine CODEOWNERS-Datei (öffnet in einem neuen Tab) fordert den verantwortlichen Stream automatisch als Reviewer an, wenn ein Pull Request seine Dateien ändert, mit „Require review from Code Owners“ wird das zur Pflicht. So bilden Sie die zweite Zeile der Matrix ab: Die Metadaten des Auftragsobjekts gehören dem Integrations-Stream, und kein anderer Partner merged daran vorbei.

GitLab bietet Code Owners (öffnet in einem neuen Tab) in Premium und Ultimate an; auf geschützten Branches lassen sich Freigaben durch Code Owners zur Pflicht machen. In Azure DevOps heißen die Bausteine Branch Policies (öffnet in einem neuen Tab): eine Mindestzahl an Reviewern und automatisch hinzugefügte Reviewer für bestimmte Ordner, die Sie als „Required“ markieren können.

In den DevOps-Werkzeugen

Die kommerziellen Plattformen bringen eigene Freigaben mit. Gearset erlaubt laut Dokumentation (öffnet in einem neuen Tab) ab „Deployment Teams and Automation Starter“ eigene Rollen mit Rechten auf Pipelines, CI-Jobs und Orgs und schlägt als Beispiel eine Rolle „Production Deployment“ vor, die nur bei Bedarf vergeben wird. Copado Essentials Plus hat einen Freigabeprozess (öffnet in einem neuen Tab), in dem Benutzer mit der Rolle Owner oder Team Lead Deployments aus einer Org freigeben. Bei sfdx-hardis laufen Freigaben über die Pull Requests der Git-Plattform, also über den Branch-Schutz oben.

In der Salesforce-Org

Die Pipeline nützt wenig, wenn jemand an ihr vorbei deployen kann.

Prüfen Sie also in Produktion, UAT und Staging, welche Partnerbenutzer eine dieser Berechtigungen tragen. Deployen sollte dort nur der technische Benutzer der Pipeline, wie Kapitel 5 beschreibt. Für befristete Rechte, etwa für eine Analyse in Produktion, können Permission-Set-Zuweisungen laut Salesforce Admins Blog (öffnet in einem neuen Tab) ein Ablaufdatum bekommen, nach dem die Rechte automatisch entfallen.

Eine Vertragsanlage, gleich für jeden Partner

Ich bin Architekt, kein Anwalt. Die folgenden Punkte beschreiben, was ich aus technischer Sicht schriftlich sehen möchte. Ihre Rechtsabteilung macht daraus Klauseln. Ich empfehle eine Anlage zum Rahmenvertrag, die für jeden Partner identisch gilt, statt Regeln in jeder Leistungsbeschreibung neu zu verhandeln.

1. Arbeiten in Ihren Werkzeugen. Code, Tickets und Dokumentation entstehen in Ihrem Repository und Ihrem Backlog, mit persönlichen, benannten Benutzern. Geteilte Logins sind ausgeschlossen.
2. Das Werkzeug steht fest. Die Wahl fällt am Anfang des Programms und gilt für jeden Partner. Wer später kommt, bringt kein eigenes Release-Werkzeug mit.
3. Jede Änderung per Pull Request. Auch Flows, Permission Sets und Layouts. In Integration, UAT, Staging und Produktion ändert niemand etwas direkt im Setup.
4. Standards und Review-Regeln gelten. Das Standarddokument des Kunden ist Teil des Vertrags, ebenso vereinbarte Reaktionszeiten für Reviews.
5. Definition of Done. Tests mit echten Asserts, Pull-Request-Beschreibung mit Bezug zur Story, dokumentierte Vor- und Nacharbeiten für das Deployment.
6. Release-Kalender und Freeze-Fenster. Der Partner plant gegen Ihren Kalender, nicht gegen seinen eigenen. Wie der Kalender entsteht, beschreibt Kapitel 8.
7. Hotfixes über dieselbe Pipeline. Ohne Ausnahme für „dringend“.
8. Regeln für KI-Coding. Welche Tools, welche Daten, welches Review. Die Prüfpunkte dafür stehen in Partner codet mit KI: Was in den Vertrag gehört.
9. Ausstieg. Übergabe ohne Arbeit außerhalb des Repositorys, Bestätigung, dass lokale Kopien mit Ihrem Code und Ihren Zugangsdaten gelöscht sind, aktive Mitarbeit an der Übergabe für einen vereinbarten Zeitraum.

Wie übersteht der Release-Prozess einen Partnerwechsel?

Wenn Eigentum, Rollen und Vertragsregeln stehen, ist ein Partnerwechsel ein Vorgang mit Checkliste. Angenommen, ein Hersteller von Verpackungsmaschinen betreibt Service Cloud mit Field Service, ein Händlerportal und eine SAP-Schnittstelle. Drei Partner arbeiten auf der Org. Der Partner für den Service-Stream wird nach einer Ausschreibung durch einen neuen ersetzt, mit vier Wochen Überlappung.

1. 01

   Bestand aufnehmen, bevor der Ausstieg verkündet wird

   Ein Abgleich zwischen Produktion und Repository zeigt, was nie im Repository angekommen ist. Das Setup Audit Trail hilft dabei, es zeigt laut Salesforce-Objektreferenz (öffnet in einem neuen Tab) Setup-Änderungen der mindestens letzten 180 Tage. Ältere Abweichungen findet nur der Abgleich. Wie eine Analyse technischer Schulden vor dem Wechsel aussieht, beschreibe ich in KI-Org-Analyse: technische Schulden vor dem Partnerwechsel.

2. 02

   Den neuen Partner im bestehenden Setup einarbeiten

   Er bekommt Benutzer im Repository, im Werkzeug und in den Sandboxes, liest die Standards und reicht in der ersten Woche kleine Pull Requests ein, die der Release Manager eng begleitet.

3. 03

   CODEOWNERS umstellen

   Die Objekte des Service-Streams wechseln den Verantwortlichen, ohne dass sich der Prozess ändert.

4. 04

   Zugriffe entziehen

   Am letzten Tag verlieren alle Benutzer des alten Partners ihren Zugriff auf Git-Plattform, Werkzeug, Sandboxes und Produktion.

5. 05

   Geheimnisse erneuern

   Zertifikate der Pipeline, Passwörter technischer Benutzer, Zugänge zur SAP-Middleware. Alles, was der alte Partner je gesehen hat, wird ersetzt.

Der Release-Kalender läuft in diesem Szenario ohne Pause weiter, denn Pipeline, Historie und Standards gehören dem Hersteller. Der neue Partner arbeitet ab Tag eins nach denselben Regeln wie die beiden anderen, und die Partner bleiben vergleichbar. Dieselbe Situation mit einer Pipeline im Account des alten Partners hätte einen Umzug mitten im Wechsel bedeutet.

Erster Schritt: Werkzeuge mit Vertragsinhaber und Admins auflisten

1. Listen Sie jedes Werkzeug mit Vertragsinhaber, Admins und Partnerbenutzern auf.
2. Benennen Sie Release Manager und Architekt auf Kundenseite, auch wenn eine Person beides übernimmt.
3. Schreiben Sie die Freigabematrix auf eine Seite und bilden Sie sie in Branch-Schutz und CODEOWNERS ab.
4. Entziehen Sie Partnerbenutzern in Stufen-Orgs die Rechte für direkte Deployments.
5. Entwerfen Sie mit Ihrer Rechtsabteilung die Anlage für alle Partnerverträge.

Diese Steuerung über alle Partner hinweg ist der Kern meiner Arbeit in der Partnersteuerung. Welche Orgs und Branches die Rollen aus diesem Kapitel bespielen, folgt in Kapitel 3 zu Umgebungen und Branches.