Warum DevOps über Salesforce-Großprojekte entscheidet

Der Einstieg in Salesforce ist leicht. Ein paar Klicks im Setup, ein Change Set, fertig. Genau diese Leichtigkeit ist der Grund, warum viele Enterprise-Programme ein Jahr später in Schwierigkeiten geraten. Sobald mehrere Teams, Partner und Länder an derselben Org arbeiten, lautet die Frage nicht mehr, wie man etwas baut. Sie lautet, wie man es sicher, wiederholbar und nachvollziehbar in Produktion bringt. Darum geht es bei DevOps, und in Großprojekten entscheidet es darüber, ob ein Programm beherrschbar bleibt.

Was geht schief, wenn ein Salesforce-Programm wächst?

In einer kleinen Org kennt ein Admin jede Änderung. In einem Enterprise-Programm ist dieses Bild verschwunden. Ich habe Programme mit bis zu acht Projektteams und mehr als 30 Entwicklern auf einer Plattform gesteuert. In so einem Umfeld passieren ohne sauberes DevOps-Setup einige Dinge sehr zuverlässig:

• Änderungen überschreiben sich gegenseitig. Team A deployt ein Page Layout, Team B deployt einen Tag später dasselbe Objekt mit einem älteren Stand. Es fällt erst auf, wenn sich Anwender beschweren.
• Niemand weiß, was in Produktion ist. Wenn die Org selbst die einzige Quelle der Wahrheit ist, gibt es keine Historie, kein Review und keinen einfachen Weg zurück.
• Releases werden zu Ereignissen. Deployments finden spät abends statt, mit manuellen Vor- und Nacharbeiten aus einer Excel-Liste, und das ganze Team hält die Luft an.
• Partner werden schwer austauschbar. Liegt das Wissen über Deployments in den Köpfen und Tools eines Implementierungspartners, hängt der Kunde von diesem Partner ab.

Nichts davon ist zuerst ein Tool-Problem. Es ist ein Governance-Problem, das sich mit Tools lösen lässt.

Warum skalieren Change Sets nicht?

Change Sets sind für kleine, isolierte Änderungen in Ordnung. Für Enterprise-Arbeit fehlt ihnen fast alles, was man braucht:

• keine Versionshistorie und kein Rollback
• kein Code-Review, bevor eine Änderung die nächste Umgebung erreicht
• keine automatisierten Tests oder Qualitätsprüfungen als Schranke
• manuelles Zusammenklicken, bei dem leicht etwas fehlt
• keine Möglichkeit, dasselbe Deployment wiederholbar über mehrere Umgebungen zu fahren

Dazu kommen drei große Salesforce-Releases pro Jahr, Sandboxes auf unterschiedlichen Release-Ständen während der Preview-Phasen und globale Rollouts mit länderspezifischen Anforderungen. Mit manuellen Deployments ist das nicht mehr zu schaffen.

Wie sieht gutes Salesforce-DevOps aus?

Ein solides Setup muss nicht kompliziert sein. In meinen Projekten sind diese Bausteine am wichtigsten:

1. Git als Quelle der Wahrheit. Alle Metadaten liegen in einem Repository. Jede Änderung ist ein Commit mit Autor, Begründung und Verweis auf die User Story.
2. Eine klare Branch- und Umgebungsstrategie. Zum Beispiel Entwickler-Sandboxes, Integration, UAT, Produktion und ein schneller Weg für Hotfixes. Jedes Team weiß, wohin seine Arbeit als Nächstes geht.
3. Pull Requests mit Review. Änderungen werden geprüft, bevor sie weiterwandern, mit einer klaren Verantwortung für Architekturentscheidungen.
4. Automatisierte Qualitätsschranken. Validierungs-Deployments, Apex-Tests und statische Code-Analyse laufen bei jedem Pull Request. Eine grüne Pipeline ist Voraussetzung für den Merge, keine Kür.
5. Delta-Deployments. Es wird nur deployt, was sich geändert hat. Das hält Deployments schnell und verringert Nebenwirkungen.
6. Monitoring und Backup. Regelmäßige Metadaten-Backups und Prüfungen zeigen Änderungen direkt in Produktion, veraltete API-Versionen oder ungenutzte Komponenten.

Die Pipeline gehört dem Kunden, nicht dem Partner. Wer den Release-Prozess besitzt, besitzt die Plattform.

Dieser letzte Punkt ist mir als Architekt auf Kundenseite besonders wichtig. Ein Repository und eine Pipeline unter Kontrolle des Kunden machen Partner vergleichbar und austauschbar. Das ist die Grundlage für Partnersteuerung und Governance. Außerdem wird das Onboarding eines neuen Partners deutlich leichter, weil die Standards aufgeschrieben sind und automatisch durchgesetzt werden.

Wie sah das in einem echten Programm aus?

In einem Programm, in das ich eingestiegen bin, betrieb ein großes Unternehmen Salesforce mit mehreren Implementierungspartnern und internen Teams. Niemand hatte klar festgelegt, wer für welche Prozesse, Objekte und Metadaten die Führung hat. Das Ergebnis war absehbar:

• Änderungen überschrieben sich, weil niemand abstimmte, wer was wann deployt.
• Die technischen Ansätze der Teams lagen weit auseinander, ähnliche Probleme wurden sehr unterschiedlich gelöst.
• Jedes Release war ein Risiko, und Fehler fielen oft erst auf, wenn Anwender darauf stießen.

Wir haben das in wenigen Schritten geändert. Erstens lief jede Änderung über einen Pull Request mit Review, und eine Zeit lang ging jeder einzelne über meinen Schreibtisch. Zweitens haben wir Entwicklungs- und Architekturstandards aufgeschrieben und in diesen Reviews durchgesetzt. Drittens wurde die Pipeline der einzige Weg, Änderungen von einer Org in die nächste zu bringen. Als der Prozess stabil lief, habe ich ihn an einen internen Kollegen übergeben, der ihn heute verantwortet.

Die Wirkung war deutlich. Ergebnisse wurden planbar, und Validierungsläufe in der Pipeline haben fehlende Abhängigkeiten und Fehler erkannt, bevor ein Anwender sie gesehen hat. Dazu kamen die klassischen DevOps-Vorteile: Wir konnten zurückrollen, jede Änderung nachvollziehen, und es ging keine Arbeit mehr verloren.

sfdx-hardis als Open-Source-Beispiel

Um dorthin zu kommen, muss man keine kommerzielle Plattform kaufen. Ein gutes Beispiel ist sfdx-hardis (öffnet in einem neuen Tab), ein Open-Source-Toolkit, das Cloudity gemeinsam mit einer aktiven Community pflegt. Es bündelt viele der Bausteine von oben:

• Eine fertige CI/CD-Pipeline für GitHub, GitLab, Azure DevOps, Bitbucket und Jenkins, damit die Pipeline dort läuft, wo die IT des Kunden ohnehin arbeitet.
• Delta- und Smart-Deployments auf Basis von sfdx-git-delta, die nur geänderte Metadaten deployen.
• Org-Monitoring und Metadaten-Backup mit Benachrichtigungen an Slack, Microsoft Teams oder andere Kanäle.
• Generierte Dokumentation des Projekts, einschließlich Flows, direkt aus dem Repository.
• Eine VS-Code-Erweiterung, die Admins und Beratern einen visuellen Zugang zum Git-Workflow gibt. So ist DevOps nicht nur etwas für Entwickler.

Das DevOps Center von Salesforce selbst ist eine weitere kostenlose Option. Es bringt Versionsverwaltung auch zu Teams, die vor allem mit Klicks arbeiten, deckt aber weniger von Pipeline, Monitoring und Dokumentation ab. Kommerzielle Tools wie Gearset oder Copado haben ebenfalls ihre Berechtigung, vor allem wenn ein Team eine komplett verwaltete Oberfläche möchte. Die Wahl hängt vom Team, der vorhandenen Toolchain und dem Budget ab. Entscheidend ist, dass früh entschieden und für alle verbindlich durchgesetzt wird, auch für jeden Partner.

Was gewinnt der Fachbereich?

DevOps klingt nach einem Thema für Entwickler. In der Praxis profitiert oft der Fachbereich am meisten:

• Planbare Releases. Ein fester Release-Kalender ersetzt „wir deployen, wenn es fertig ist“. Fachbereiche können Schulungen und Kommunikation darauf ausrichten.
• Schnellere Korrekturen. Tritt ein Fehler in Produktion auf, läuft ein Hotfix in Stunden durch dieselbe getestete Pipeline, statt auf das nächste große Release zu warten.
• Weniger Überraschungen beim Go-live. Jede Änderung wurde in Integration und UAT bereits genau so deployt und getestet, wie sie in Produktion ankommt.
• Nachvollziehbarkeit für Audits. Für jedes Feld, jeden Flow und jede Berechtigung lässt sich zeigen, wer es wann und warum geändert und wer es freigegeben hat.
• Weniger Abhängigkeit von Einzelnen. Das Wissen liegt im Repository und in der Pipeline, nicht im Kopf eines Admins oder des Lead-Entwicklers eines Partners.

Für einen Lenkungsausschuss läuft das auf eine einfache Frage hinaus: Wie sicher sind wir, dass das nächste Release Vertrieb oder Service nicht stört? Ohne DevOps ist die ehrliche Antwort oft eine Schätzung.

Wo fängt man an?

Wenn Ihr Salesforce-Programm noch mit Change Sets oder manuellen Deployments arbeitet, brauchen Sie keine Big-Bang-Umstellung. Eine pragmatische Reihenfolge:

1. Die aktuellen Produktions-Metadaten in ein Git-Repository bringen.
2. Validierungs-Deployments und Tests für jeden Pull Request einführen.
3. Branch- und Umgebungsstrategie festlegen und für alle Partner verbindlich machen.
4. Produktions-Deployments auf die Pipeline umstellen.
5. Monitoring, Backups und generierte Dokumentation ergänzen.

DevOps ist keine zusätzliche Schicht für später. In Enterprise-Projekten ist es Teil der Architektur, und es sollte stehen, bevor der zweite Partner an der Org arbeitet. Wenn Sie eine zweite Meinung zu Ihrem Release-Prozess möchten, schreiben Sie mir.