Salesforce DevOps einführen: Fahrplan und Messung

Der Weg von Change Sets zu einer Salesforce-DevOps-Pipeline gelingt in Phasen statt in einem großen Umstieg. Ich empfehle sieben Phasen in der Reihenfolge dieser Masterclass: Eigentum und Werkzeug klären, Git als einzige Quelle einführen, eine Validierungspipeline bauen, Quality Gates scharf schalten, Daten und Konfiguration mitnehmen, einen Release-Kalender festlegen und den Betrieb absichern. Jede Phase endet mit einem prüfbaren Ergebnis. Ein Stream geht als Pilot voran, die anderen Partner folgen zu festen Terminen. Parallel bauen Sie Wissen im eigenen Haus auf, etwa mit dem kostenlosen sfdx-hardis-Training, und messen den Fortschritt gegen eine Basislinie. Coding-Agenten kommen erst, wenn diese Pipeline steht.

Wie sieht der Fahrplan von Change Sets zur Pipeline aus?

Die neun Kapitel davor beschreiben jeweils einen Baustein. Für die Einführung zählt die Reihenfolge, denn jede Phase setzt die vorige voraus:

Phase	Was entsteht	Abschlusskriterium	Kapitel
1. Eigentum und Werkzeug	Repository, Pipeline und Werkzeuge gehören Ihnen, Rollen und Freigaben sind benannt	Release Manager benannt, Werkzeugentscheidung schriftlich, Regeln in allen Partnerverträgen	1, 2, 4
2. Git als Quelle	Metadaten der Produktion im Repository, Sandbox-Strategie, Branch-Modell	Jede Änderung beginnt auf einem Feature-Branch	3
3. Validierungspipeline	Pull Requests, Validierungsdeployments, Delta-Deployments, Anmeldung ohne Passwort	UAT und Produktion nehmen keine Change Sets mehr an	5
4. Quality Gates	Pflicht-Reviews, Apex- und Flow-Tests, statische Analyse mit Schwellenwert	Merge nur bei grüner Pipeline und Freigabe	6
5. Daten und Konfiguration	Referenz- und Konfigurationsdaten aus dem Repository, maskierte Sandboxes	Kein manueller Datenschritt mehr im Release-Plan	7
6. Release-Rhythmus	Release-Kalender, Freeze-Fenster, Plan für die drei Salesforce-Releases	Kalender für zwölf Monate veröffentlicht	8
7. Betrieb	Monitoring, Backup, Hotfix-Weg, Kennzahlen	Restore einmal geprobt, Hotfix läuft über die Pipeline	9

Phase 1 braucht kaum Technik und entscheidet am meisten. Wer das Werkzeug wählt, setzt den Standard. Fällt die Wahl spät oder überlässt ein Kunde sie dem ersten Partner, bauen zwei Partner zwei Prozesse, und der Kunde bezahlt die Zusammenführung. Ich empfehle deshalb, die Werkzeugentscheidung früh zu treffen und für jeden Partner verbindlich zu machen, wie in warum Kunden ihre DevOps-Tools selbst besitzen sollten begründet.

Phase 2 beginnt mit der Produktion als Wahrheit. Bis das Repository steht, ist die Produktiv-Org die einzige vollständige Quelle. Den Ausgangsstand holen Sie mit sf project retrieve start und einer package.xml über --manifest, so die CLI-Referenz (öffnet in einem neuen Tab). Ab diesem Tag gilt: Wer in Produktion im Setup etwas ändert, erzeugt Drift, und Drift wird zurück ins Repository geholt, bevor das nächste Release läuft.

Phase 3 und 4 laufen zeitversetzt. Eine Pipeline, die vom ersten Tag an alles blockiert, trifft in einer gewachsenen Org auf Hunderte Altfunde. Partner schalten dann Regeln ab, statt Code zu korrigieren. Ich würde zuerst nur schwere Funde blockieren und den Rest berichten, wie in Quality Gates für KI-Code beschrieben, und die Schwelle mit jedem Quartal anziehen.

Ein Pilot geht voran. Wählen Sie einen Stream mit vielen kleinen Änderungen und überschaubarem Risiko, etwa das Händlerportal, nicht die SAP-Schnittstelle. Nach zwei oder drei Releases im Pilot sehen Sie, wo Ihre Pipeline hakt, bevor alle Partner davon abhängen. Die übrigen Streams folgen zu Terminen, die im Vertrag stehen. Ein Stichtag beendet Change Sets für UAT und Produktion; danach gibt es keine Ausnahme für „nur dieses eine Feld“.

Wie befähigen Sie Ihr Team und Ihre Partner?

Dazu kommt Training, und zwar praxisnah. Ich setze sfdx-hardis seit rund zwei Jahren in Kundenprojekten ein und habe im Oktober 2026 alle drei Level des kostenlosen sfdx-hardis-Trainings (öffnet in einem neuen Tab) abgeschlossen. In 27 Labs entsteht auf kostenlosen Developer Edition Orgs und einem GitHub-Account eine komplette Pipeline, und ein Badge gibt es erst, wenn ein Job die Arbeit im eigenen Repository geprüft hat. Trotz Vorerfahrung habe ich fast einen Tag gebraucht. Meine Eindrücke stehen in was ich aus dem sfdx-hardis-Training lernte.

Die kommerziellen Anbieter haben eigene Angebote, und ich habe Kurse von Gearset, Flosum und Copado gemacht. Gearset betreibt mit DevOps Launchpad (öffnet in einem neuen Tab) eine kostenlose Plattform mit Kursen, Quizzes und Zertifikaten, deren Inhalte größtenteils nicht an Gearset gebunden sind. Copado bietet laut seiner Trainingsseite (öffnet in einem neuen Tab) die Copado Academy und kostenlose Workshops mit Prüfungsgutschein an. Flosum führt mit Flosum Certified Learning (öffnet in einem neuen Tab) zwei Kurse, Professional und Expert. Nutzen Sie das Training des Werkzeugs, das Sie gewählt haben; für die Grundlagen von Git und Pull Requests taugen alle.

Rolle	Was sie können muss	Passendes Training
Admins und Berater	Branch, Pull Request, Merge-Konflikt ohne Angst	sfdx-hardis Level 1 und 2, DevOps Launchpad
Entwickler und Tech Leads	Deployment-Schritte, Quality Gates, Testabdeckung	sfdx-hardis Level 2, Training des Werkzeuganbieters
Release Manager	Reviews, UAT, Produktion, Hotfix, Kennzahlen	sfdx-hardis Level 3, Training des Werkzeuganbieters
Product Owner, Fachbereich	Release-Kalender lesen, UAT abnehmen	kein Kurs, eine Stunde mit dem Release Manager

Partner würde ich wie interne Teams behandeln und im Vertrag verlangen, dass jeder Entwickler vor dem ersten Pull Request das Basistraining nachweist und das Onboarding-Dokument aus Ihrem Repository gelesen hat. Das kostet einen Tag pro Person und spart die Diskussion im dritten Sprint, warum der Partner doch wieder per Change Set deployen möchte. Wie das in die Steuerung mehrerer Partner passt, beschreibe ich in der Partnersteuerung.

Diese Fehler bremsen die Einführung

Die folgenden Muster folgen aus der Struktur eines Programms mit mehreren Partnern und tauchen deshalb immer wieder auf:

• Das Werkzeug kommt vor dem Prozess. Eine Lizenz ersetzt kein Branch-Modell, keine Freigaberegel und keinen Release Manager.
• Der erste Partner richtet alles ein. Dann liegen Repository und Pipeline in seiner Organisation, und ein Partnerwechsel wird zum Migrationsprojekt.
• Alle Streams wechseln gleichzeitig. Ein Fehler in der Pipeline stoppt dann das ganze Programm statt eines Piloten.
• Produktion bleibt offen. Ein Schnellfix im Setup der Produktion erzeugt Drift, das nächste Deployment überschreibt ihn oder scheitert.
• Gates blockieren vom ersten Tag an alles. Die Folge sind abgeschaltete Regeln und // NOPMD-Kommentare statt besseren Codes.
• Nur Entwickler werden geschult. Admins bauen weiter im Setup, weil ihnen niemand Pull Requests gezeigt hat.
• Niemand misst. Ohne Basislinie lässt sich dem Lenkungsausschuss nicht zeigen, was die Umstellung gebracht hat.

Fortschritt gegen eine Basislinie messen

DORA beschreibt heute fünf Kennzahlen (öffnet in einem neuen Tab) für die Auslieferung von Software: Durchlaufzeit von Änderungen, Deployment-Häufigkeit, Wiederherstellungszeit nach einem fehlgeschlagenen Deployment, Änderungsfehlerrate und die Rate der ungeplanten Deployments nach einem Produktionsvorfall (Deployment Rework Rate). Die ersten drei messen Durchsatz, die letzten zwei Instabilität.

Die Werkzeuge liefern einen Teil davon mit. Der DORA-Bericht von sfdx-hardis (öffnet in einem neuen Tab) berechnet laut Dokumentation alle fünf pro Hauptbranch, wie in Kapitel 9 beschrieben, und die Übersicht (öffnet in einem neuen Tab) ordnet die klassischen vier gegen Branchenwerte ein. Gearset hat ein DevOps-Performance-Dashboard (öffnet in einem neuen Tab) mit denselben vier, das eine Lizenz für Teams oder Enterprise Automation Platform und Pipelines mit Promotion-Branch-Strategie voraussetzt; Änderungsfehlerrate und Wiederherstellungszeit beruhen dort auf Fehlern, die Ihr Team in den Promotions meldet. Beide Zahlen stimmen also nur, wenn Störungen konsequent gemeldet werden.

Für ein Programm in der Einführung würde ich vier eigene Werte ergänzen, weil sie den Fortschritt früher zeigen als DORA:

1. Anteil der Deployments über die Pipeline an allen Deployments nach UAT und Produktion. Ziel ist 100 Prozent zum Stichtag.
2. Manuelle Schritte im Release-Plan. Jede Zeile, die jemand von Hand im Setup ausführt, ist ein Risiko am Release-Abend.
3. Wartezeit bis zum ersten Review pro Pull Request. Steigt sie, fehlt Review-Kapazität, nicht Entwicklerkapazität.
4. Drift-Funde pro Monat aus dem Monitoring, also Änderungen in Produktion, die nicht aus dem Repository kamen.

Erheben Sie die Basislinie, bevor Phase 2 beginnt, notfalls aus den Release-Plänen des letzten Halbjahres. Dem Lenkungsausschuss würde ich diese Werte quartalsweise auf einer Seite berichten, nach Stream und Partner getrennt.

Rechenbeispiel: drei Partner, eine Org

Angenommen, ein Maschinenbauer betreibt Service Cloud, Field Service für den Außendienst, ein Händlerportal auf Experience Cloud und eine SAP-Schnittstelle für Aufträge und Ersatzteile. Drei Partner deployen per Change Set, alle vier Wochen gibt es ein Release mit einem Plan von 60 manuellen Zeilen. Alle Zahlen sind Annahmen.

1. 01

   Eigentum klären

   Monate 1 und 2 · Kunde

   Der Kunde benennt eine interne Release Managerin, entscheidet sich für ein Werkzeug und ergänzt die drei Verträge um eine Anlage mit Branch-Modell, Review-Pflicht und Stichtag.

2. 02

   Pilot starten

   Monat 3

   Das Repository entsteht aus Produktion, der Händlerportal-Stream startet als Pilot.

3. 03

   Validieren und schulen

   Monate 4 und 5

   Validierung bei jedem Pull Request, Gates blockieren schwere Funde. Die Release Managerin und zwei Admins machen das Training.

4. 04

   Alle Streams umstellen

   Monat 6

   Die Partner für Field Service und SAP wechseln, Stichtag für Change Sets.

5. 05

   Daten und Betrieb

   Monate 7 bis 9

   Preisbücher und Field-Service-Konfiguration kommen ins Repository, der Release-Kalender steht, das Monitoring meldet Drift.

Nach neun Monaten hat der Release-Plan zwölf manuelle Zeilen, vorher waren es 60, UAT bekommt wöchentlich statt monatlich neue Stände, und ein Partnerwechsel im Field-Service-Stream wäre eine Vertragsfrage, kein Technikprojekt. Diese Zahlen sind Planwerte für das Beispiel, keine Messung.

Was ändert sich, wenn Coding-Agenten in der Pipeline arbeiten?

Coding-Agenten schreiben Code schneller, als Menschen ihn prüfen. Eine Pipeline mit Pflicht-Reviews und blockierenden Gates fängt das ab, eine Pipeline ohne sie leitet es nur schneller in Produktion. DORA zählt kleine Batches (öffnet in einem neuen Tab) deshalb zu den Fähigkeiten, die das Risiko ausgleichen, wenn KI die Entwicklung beschleunigt. Für mich folgt daraus eine klare Reihenfolge: erst die Phasen 1 bis 4, dann Agenten.

Wenn es so weit ist, ändert sich Folgendes:

• Eine Regeldatei kommt ins Repository. CLAUDE.md, AGENTS.md oder .vibes/rules/ gehören Ihnen und haben eine verantwortliche Person auf Ihrer Seite, siehe die KI-Regeldatei im Salesforce-Repository.
• Die Gates bekommen Regeln für typische Agentenfehler, etwa eine Prüfung, ob ein Agent nebenbei die API-Version einer Apex-Klasse angehoben hat. Details in Quality Gates für KI-Code.
• Agentforce-Agenten werden selbst zu Release-Gegenständen. Ihr Agent Script liegt in Git und läuft durch Validierung, Publish und Aktivierung, siehe Agentforce-Agenten in der Release-Pipeline.
• Die DevOps-Werkzeuge bringen eigene Agenten mit. sfdx-hardis führt in seiner Übersicht ein Coding Agent Auto-Fix (Beta) für Deployment-Fehler, Copado und Gearset haben eigene Agenten angekündigt, die ich in Copado, Gearset und Provar im Kundencheck einordne. Jeder Vorschlag eines Agenten durchläuft dieselben Prüfungen und ein menschliches Review.

Am stärksten trifft das die Review-Kapazität, besonders bei Nearshore-Teams in anderen Zeitzonen. Ich habe mit Nearshore-Teams in Osteuropa und Indien gearbeitet, und was sich mit Agenten dort verschiebt, beschreibe ich in Nearshore-Salesforce-Teams mit KI-Agenten.

Ab hier übernimmt die KI-Masterclass. Welcher Coding-Agent zu Ihrem Team oder Partner passt und was dafür im Vertrag stehen muss, behandelt Kapitel 4 der KI-Masterclass. Wie sich Rollen, Review-Gates und Kennzahlen ändern, wenn Teams mit Agenten liefern, steht in Kapitel 9 der KI-Masterclass. Den Betrieb, auf dem diese Phase aufsetzt, beschreibt das vorige Kapitel 9 zu Betrieb und Monitoring, alle Kapitel dieser Masterclass finden Sie auf der Übersichtsseite. Die Einführung selbst begleite ich im DevOps- und Release-Management.