Salesforce DevOps für Admins: deployen, ohne Git anzufassen

Kurze Antwort: Ein Salesforce-Admin muss Git nicht lernen, um sicher zu deployen. Was Sie brauchen, ist eine versionierte Pipeline, und ein ticketbasiertes DevOps-Werkzeug betreibt sie für Sie: Sie wählen Ihre Änderungen in einer Oberfläche aus, das Werkzeug committet sie, öffnet den Pull Request, führt die Tests aus und promotet die Arbeit durch Ihre Umgebungen. Git läuft weiterhin darunter. Es ist nur nicht mehr Ihre Oberfläche.

Braucht man Git für Salesforce DevOps?

Nein. Sie brauchen das, was Git liefert, und das ist nicht dasselbe. Drei Begriffe tragen fast den gesamten Nutzen, und keiner davon verlangt ein Terminal.

• Versionskontrolle: ein dauerhafter Nachweis jeder Metadatenänderung, wer sie gemacht hat und wann, damit Sie später vergleichen oder zurücknehmen können.
• Pipeline: ein fester Weg, den Ihre Änderungen nehmen, etwa Dev-Sandbox nach UAT nach Produktion, mit denselben Prüfungen bei jedem Schritt.
• Work Item: das Ticket, zu dem eine Änderung gehört, damit ein Release eine Liste freigegebener Tickets ist und nicht eine Liste von Komponenten, an die sich jemand erinnert hat.

Ein Workflow ohne Git ist kein Workflow ohne Versionskontrolle. Es ist ein Workflow, in dem die Versionskontrolle für Sie automatisiert wird.

Warum skalieren Change Sets im Admin-Team nicht?

Change Sets sind der eigentliche Platzhirsch, und sie halten problemlos, bis eine zweite Person Änderungen vornimmt. Zwei Grenzen richten den meisten Schaden an. Erstens braucht ein Change Set eine Deployment Connection und wandert nur zwischen Orgs, die derselben Produktions-Org zugeordnet sind, nicht verbundene Orgs sind also schlicht unerreichbar (Salesforce Help). Zweitens ist ein Change Set ein Einwegpaket: keine Historie, kein Rückgängig, und nach dem Hochladen nicht mehr änderbar. Ein abgelehnter Release bedeutet daher, die Komponentenliste von Hand neu zu bauen.

Der teuerste Fehler ist nicht das Deployment, das scheitert. Es ist das stille Überschreiben: Zwei Personen bearbeiten denselben Flow oder dasselbe Page Layout in verschiedenen Sandboxes, und wer als Zweiter deployt, gewinnt lautlos.

Wie sieht ein ticketbasiertes Deployment von Anfang bis Ende aus?

Genau diesen Ablauf bekommen Admins fast nie gezeigt, deshalb hier vollständig. Nichts davon verlangt eine Kommandozeile.

1. Orgs einmalig verbinden. Produktion und jede Sandbox über OAuth autorisieren. Eine Plattform, die nur Standard-APIs von Salesforce nutzt, installiert kein Package in Ihrer Org, es gibt später also nichts zu deinstallieren.
2. Pipeline definieren. Benennen Sie Ihre Umgebungen und die Reihenfolge der Promotion. Das richten Sie einmal ein, danach ist es der einzige Weg in die Produktion.
3. Ticket öffnen. Ein Ticket pro Änderung, idealerweise pro User Story. Nicht die Sandbox, sondern das Ticket ist jetzt die Release-Einheit.
4. In der Sandbox bauen wie bisher. Klicken, Flow Builder, Page Layouts. An Ihrer Art, Salesforce zu konfigurieren, ändert sich nichts.
5. Änderungen auswählen. Das Werkzeug listet auf, was sich in dieser Sandbox seit der letzten Synchronisierung geändert hat. Sie haken die Komponenten an, schreiben eine kurze Beschreibung und hängen sie an das Ticket.
6. Review, bevor sich etwas bewegt. Apex-Tests und Coverage laufen automatisch, und ein KI-Review liest den Diff auf Governance-Abweichungen, Sicherheitsprobleme und Verstöße gegen Best Practices. Eine Kollegin gibt das Ticket frei.
7. Dieselbe Auswahl promoten. Das freigegebene Ticket wandert nach UAT und dann in die Produktion. Sie bauen die Liste nie neu, und genau dort verlieren Change-Set-Releases Komponenten.
8. Releasen und den Rückwärtsgang behalten. Das Produktions-Deployment wird aufgezeichnet. Läuft der Release schief, kehren Sie mit einer Aktion zum letzten guten Stand zurück, statt zu rekonstruieren, was ausgeliefert wurde.

Was macht Git, während Sie klicken?

Jeder Schritt oben hat eine Git-Entsprechung, die die Plattform für Sie ausführt:

• Ein Ticket zu öffnen erzeugt einen Branch.
• Komponenten auszuwählen schreibt einen Commit mit Ihrer Beschreibung als Nachricht.
• Ein Review anzufordern öffnet einen Pull Request und startet dort die automatisierten Prüfungen.
• Freigeben und Promoten merged diesen Pull Request und löst ein Deployment über die Metadata API aus.
• Ein Rollback nimmt den Commit zurück und deployt den vorherigen Stand erneut.

Das ist aus einem praktischen Grund wichtig: Ihre Entwickler behalten Repository, Branches und die CLI, die sie ohnehin nutzen, und die Admins arbeiten in einer Oberfläche auf derselben Historie. Es gibt keine zweite Wahrheit, die abgeglichen werden muss.

Reicht DevOps Center allein?

Salesforce liefert eine eigene kostenlose Option, und für ein kleines Team, das Change Sets hinter sich lässt, ist das ein echter Fortschritt. Kennen Sie die Grenzen, bevor Sie sich festlegen. DevOps Center funktioniert nur mit cloudbasierten GitHub.com-Plänen einschließlich GitHub Enterprise Cloud, lokal gehostetes GitHub Enterprise Server wird nicht unterstützt. Jede Person braucht ein eigenes GitHub.com-Konto, und jedes Projekt-Repository muss ein Salesforce-DX-Projekt enthalten (Salesforce Help).

Der Admin tippt also nie ein Git-Kommando, aber jemand administriert weiterhin GitHub, und Backup, Rollback und Testautomatisierung liegen außerhalb des Produkts. Wenn das Ihr Team beschreibt, ist eine Plattform, die den ganzen Weg abdeckt, die leichtere Wahl.

Was richtet ein Admin in der ersten Woche ein?

1. Eine Pipeline und eine Produktions-Org wählen. Modellieren Sie nicht am ersten Tag jede Umgebung.
2. Einen risikoarmen Release komplett durchschieben, bevor Sie das Backlog migrieren.
3. Eine Review-Regel schriftlich festhalten, etwa: kein Ticket in die Produktion ohne eine Freigabe.
4. Automatische Apex-Tests im UAT-Schritt aktivieren, nicht erst im Produktionsschritt, damit Fehler früh auffallen.
5. Einen Rollback bewusst in einer Sandbox üben, damit das Team ihn kennt, bevor es ihn braucht.

Serpent fährt genau diesen Ablauf mit Git im Hintergrund, installiert nichts in Ihrer Salesforce-Org und enthält KI-Code-Review in jedem Plan, auch im kostenlosen. Die Einrichtung dauert unter 15 Minuten, und unser Team macht sie gemeinsam mit Ihnen.

FAQ

Kann ein Salesforce-Admin DevOps ohne Entwickler betreiben?

Ja. Metadaten auswählen, einen Diff prüfen und einen Release freigeben sind Admin-Fähigkeiten. Nicht überspringen lässt sich der Prozess: eine Pipeline, ein Ticket pro Änderung, eine Freigabe.

Gibt es im Workflow ohne Git trotzdem ein Rollback?

Nur wenn das Werkzeug Versionshistorie führt. Zurückrollen geht, weil jedes Deployment vorher committet wurde, und genau das tun Change Sets nie.

Bremst eine Admin-Oberfläche meine Entwickler aus?

Nein, wenn beide Seiten ein Repository teilen. Entwickler behalten CLI und Branches, die Oberfläche ist nur eine andere Tür zur selben Historie.

Was mache ich mit meinen bestehenden Change Sets?

Behalten Sie sie für einen Release, während die neue Pipeline parallel läuft, und legen Sie sie dann still. Migrieren Sie nie einen laufenden Release auf halbem Weg.

Weitere Schritt-für-Schritt-Anleitungen zu Salesforce DevOps finden Sie in unserer SF-Guides-Bibliothek.