Die Geschwindigkeit von Deployments: von Change Sets zu CI/CD

Euer Wettbewerber hat gerade ein Feature gelauncht, um das euer Sales-Team seit Monaten bettelt. Eure Version? Hängt immer noch im UAT, weil jemand vergessen hat, eine Validierungsregel ins Change Set zu packen. Schon wieder.

In modernen Revenue Operations ist Geschwindigkeit kein Luxus, sondern Überleben. Jede Woche, die euer Feature in einer Deployment-Queue liegt, ist eine Woche, in der euer Wettbewerber Deals abschließt, die ihr nicht abschließen könnt.

Was Handarbeit kostet

Change Sets sind das eingebaute Deployment-Werkzeug von Salesforce. Sie sind kostenlos, sie sind vertraut, und sie bringen eure Velocity um.

So sieht ein typisches Change-Set-Deployment aus:

1. Entwickler baut das Feature in der Sandbox
2. QA testet und fordert Änderungen an
3. Entwickler ändert, erstellt ein Change Set
4. Change Set schlägt fehl, weil eine Abhängigkeit fehlt
5. Entwickler ergänzt die fehlenden Komponenten, versucht es erneut
6. Change Set läuft durch, zerlegt aber eine Validierungsregel in der Produktion
7. Notfall-Hotfix wird von Hand deployed
8. Post-Mortem wird für nächste Woche angesetzt

Gesamtdauer: 12 Tage. Tatsächliche Entwicklungszeit: 4 Stunden.

Der Rest ist Prozess-Overhead.

„Wenn euer Deployment-Prozess einen War Room und ein Stoßgebet braucht, braucht ihr CI/CD.“

Die CI/CD-Revolution

Continuous Integration / Continuous Deployment macht aus der Salesforce-Entwicklung einen Fluss statt eines Batch-Prozesses:

• Jeder Commit stößt automatisierte Tests an, in einer isolierten Scratch Org
• Bestandene Tests deployen automatisch nach Staging, zur manuellen QA
• Freigegebene Änderungen gehen mit einem einzigen Klick in die Produktion
• Rollbacks dauern Minuten, nicht Stunden

Ein Kunde ist von monatlichen „Release-Wochenenden“ auf 47 Deployments pro Monat umgestiegen. Sein CRO hat aufgehört zu fragen „Wann ist es endlich fertig?“ und angefangen zu fragen „Was können wir sonst noch ausliefern?“

Der Weg zur Umsetzung

Ihr braucht keinen Doktortitel in DevOps, um CI/CD für Salesforce einzuführen. Fangt einfach an:

Phase 1: Source Control (Woche 1)

Bringt eure Metadaten nach Git. Zieht eure Org mit Salesforce DX in die Versionskontrolle. Ab da habt ihr Historie, Branching und Code Review.

Phase 2: Automatisierte Tests (Woche 2-3)

Schreibt Tests für die kritischen Automatisierungen. Fangt mit den Strecken an, die den Umsatz berühren: Lead Routing, Opportunity-Validierung, CPQ-Regeln.

Phase 3: Pipeline-Automatisierung (Woche 4-6)

Richtet GitHub Actions oder GitLab CI so ein, dass bei jedem Commit die Tests laufen. Wenn sie durchlaufen, geht das Deployment automatisch in eine QA-Sandbox.

Phase 4: Produktions-Pipeline (ab Woche 7)

Ergänzt manuelle Freigabe-Gates und deployt dann über dieselbe Pipeline in die Produktion. Ab da ist jedes Release wiederholbar und prüfbar.

ROI messen

Erfasst diese Kennzahlen vor und nach der CI/CD-Einführung:

• Mittlere Zeit bis zum Deployment (Ziel: unter 2 Stunden)
• Fehlerquote bei Deployments (Ziel: unter 5 %)
• Ausgelieferte Features pro Monat (rechnet mit dem 2- bis 3-Fachen)
• Notfall-Hotfixes (sollten praktisch auf null fallen)

Der ROI ist nicht nur Geschwindigkeit. Er ist Planbarkeit. Sales kann sich darauf verlassen, dass Features dann landen, wenn sie versprochen wurden. Marketing kann Launches koordinieren. Kunden bekommen ihre Fixes, bevor sie churnen.