Selbstgebaute GitHub Actions für Salesforce: Was passiert, wenn der Erbauer geht?

Kurze Antwort: Etwa zwei Wochen lang passiert gar nichts. Dann ändert ein Salesforce-Release eine API-Version, ein Zertifikat läuft ab, ein Runner-Image entfernt eine Abhängigkeit, und das Deployment scheitert an einem Fehler, zu dem niemand eine Notiz hinterlassen hat. Eine selbstgebaute Salesforce-Pipeline ist selten Infrastruktur. Sie ist ein persönliches Projekt mit einem Bus-Faktor von eins, und die Rechnung kommt nach etwa achtzehn Monaten.

Warum fühlt sich eine selbstgebaute Pipeline am Anfang kostenlos an?

Weil der Bau tatsächlich billig ist. Die öffentlichen Tutorials sind gut: JWT-Authentifizierung gegen eine Connected App, Secrets im Repository, eine Workflow-Datei pro Branch, sfdx-git-delta für Delta-Deployments, ein Testlauf mit Coverage-Schwelle (Salesforce Ben hat eine solide Anleitung). Eine fähige Person hat das in zwei Wochen laufen, und im ersten Jahr funktioniert es.

Was die Tutorials nicht behandeln, ist die Frage, wem es danach gehört. Lesen Sie die Kommentare darunter, und Sie finden die eigentliche Geschichte: veraltete Befehle, abgelaufene Authentifizierung, eine verschwundene Java-Version. Diese Kommentare sind die Wartungsrechnung im Kleinen.

Warum bricht die Pipeline nach rund achtzehn Monaten?

Weil sich alles darunter bewegt und das YAML nicht.

• Drei Salesforce-Releases pro Jahr. API-Versionen rücken vor, Metadatenformen ändern sich, und festgepinnte Versionen im Workflow fallen still zurück.
• Die CLI bewegt sich. Befehle werden umbenannt und abgekündigt. Skripte auf den alten Namen laufen weiter, bis sie es nicht mehr tun.
• Zertifikate und Secrets laufen ab. Das selbstsignierte Zertifikat hinter der JWT-Connected-App hat ein Ablaufdatum, das niemand in einen Kalender eingetragen hat.
• Runner-Images ändern sich. Gehostete Runner aktualisieren Betriebssystem, Node und Java nach ihrem Zeitplan, nicht nach Ihrem.
• Fremde Actions driften. Delta-Tool, Scanner und auf ein Tag gepinnte Community-Actions haben eigene Release-Zyklen und Breaking Changes.
• Die Org wächst. Die Pipeline war für zwei Sandboxes und vier Beteiligte gedacht. Jetzt bedient sie fünf Umgebungen, ein Package und Menschen, die nie ein Terminal geöffnet haben.

Keines dieser Themen ist für sich schwer. Schwer werden sie, weil sie an einem Dienstagnachmittag auftauchen, im Release-Fenster, in einem Repository, dessen Autor im März gegangen ist.

Was kostet die Wartung wirklich?

Die ehrliche Antwort: Sie ist eine dauerhafte, nicht budgetierte Teilzeitstelle. Die Anbieterliteratur ist sich über die Form einig, auch wenn die Zahlen aus unterschiedlichen Quellen stammen: Gearset beziffert unter Verweis auf die Harvard Business Review die Überschreitungsquote bei Eigenentwicklungen mit 70% (build or buy), und Copado gibt an, dass etablierte DevOps-Anbieter 10 bis 15% ihrer Entwicklungskapazität allein dafür aufwenden, mit Änderungen der Salesforce-Plattform Schritt zu halten (the hidden costs of building your own). Zusammengelesen ist der Punkt unbequem, aber einfach: Ein spezialisierter Anbieter behandelt Plattformkompatibilität als Vollzeit-Engineering-Programm. Ihre Pipeline bekommt, was vom Freitag einer Person übrig bleibt.

Die Kosten, die es nie in einen Business Case schaffen:

• Das blockierte Release, während jemand eine Workflow-Datei seziert, die er nicht geschrieben hat.
• Die Administratorin, die keine Deployments mehr anfordert, weil die Pipeline sie einschüchtert, und zu Change Sets zurückkehrt.
• Die zweite Pipeline neben der ersten, weil niemand die erste anfassen wollte.
• Die Einarbeitungssteuer für jede neue Fachkraft, die ein Sondersystem lernen muss, das es nirgends sonst gibt.

Wie testet man den eigenen Bus-Faktor?

Fünf Fragen. Beantworten Sie sie diese Woche ehrlich, nicht während einer Kündigung.

1. Wenn die Pipeline jetzt ausfiele, wie viele Menschen könnten das Log lesen und die Ursache benennen?
2. Wo ist das Runbook, und wann stimmte es zuletzt?
3. Wer rotiert die Zugangsdaten, und wann läuft das aktuelle Zertifikat ab?
4. Kann jemand ohne Entwicklerhintergrund ein Deployment auslösen und das Ergebnis verstehen?
5. Wie lange bräuchte ein externer Dienstleister ab morgen, um produktiv zu sein?

Wenn vier dieser Antworten der Name einer Person sind, haben Sie keine Pipeline. Sie haben eine Abhängigkeit.

Wann ist Selbstbauen weiterhin richtig?

Wenn die Pipeline als Produkt behandelt wird und nicht als Gefallen. Das heißt: ein benannter Verantwortlicher, der nicht der Einzige ist, eine zweite Person, die sie tatsächlich schon repariert hat, eine Dokumentation, die jemand durch Nachvollziehen geprüft hat, gepinnte und geprüfte Abhängigkeiten und eine Zeile im Budget. Viele Teams erreichen diese Latte, besonders mit echter Platform-Engineering-Funktion und Anforderungen, die kein Anbieter abdeckt. Mit tiefer interner DevOps-Kompetenz und der Bereitschaft, sie zu finanzieren, ist Eigenbau vertretbar.

Was nicht funktioniert, ist die Mitte: ein Sondersystem ohne Verantwortlichen in einem Team, dessen eigentliche Aufgabe das Ausliefern von Salesforce-Features ist.

Was tun Sie in der Woche der Kündigung?

1. Setzen Sie sich dazu und zerbrechen Sie die Pipeline absichtlich in einer Sandbox. Beobachten und protokollieren Sie die Diagnose.
2. Inventarisieren Sie jedes Secret, jedes Zertifikat und jedes Servicekonto samt Ablaufdatum.
3. Lassen Sie eine zweite Person ein vollständiges Deployment ohne Hilfe durchführen, während die Autorin zusieht und die Tastatur nicht anfasst.
4. Schreiben Sie die drei häufigsten Störungen mit ihrer jeweiligen Behebung auf.
5. Entscheiden Sie bewusst, ob Sie behalten oder ersetzen. Ins Ergebnis hineinzurutschen ist der teure Weg.

Genau dort verdient sich eine unterstützte Plattform ihr Geld. Serpent gibt es, damit eine Salesforce-Pipeline nicht das Nebenprojekt einer Person ist: Deployments laufen ticketbasiert mit Git darunter, Admins und Berater können Releases also ohne CLI anstoßen und verfolgen, und Plattformkompatibilität ist unser Problem statt das Ihres scheidenden Kollegen. Serpent installiert nichts in Ihrer Org und arbeitet über Standard-APIs, die Preise sind pauschal pro Unternehmen mit unbegrenzten Nutzern, und ein kostenloser Essentials-Plan erlaubt den Test in der eigenen Org. Die Einrichtung dauert unter 15 Minuten, und unser Team führt die Onboarding-Session mit Ihnen durch.

FAQ

Sind GitHub Actions eine schlechte Wahl für Salesforce-CI/CD?

Nein. Es ist ein starkes CI-System, und viele Teams fahren gut damit. Das Risiko ist nicht das Werkzeug, sondern eine Sonderpipeline mit einem einzigen Verantwortlichen und ohne Wartungsbudget.

Wie lange hält eine handgebaute Salesforce-Pipeline?

Im ersten Jahr läuft sie meist gut, danach kostet sie echte Zeit, weil sich Salesforce-Releases, CLI-Änderungen, ablaufende Zugangsdaten und Runner-Updates häufen.

Was bricht zuerst, wenn der Autor geht?

Meist die Authentifizierung. Abgelaufene Zertifikate und rotierte Secrets fallen laut aus, und zwar in dem Teil des Aufbaus, der einmal konfiguriert und nie dokumentiert wurde.

Wie senken wir den Bus-Faktor, ohne die Pipeline zu ersetzen?

Benennen Sie Verantwortlichen und Stellvertretung, legen Sie ein geprüftes Runbook ins Repository, tragen Sie jedes Ablaufdatum in den Kalender ein, und lassen Sie mindestens monatlich eine zweite Person ein echtes Deployment allein fahren.

Ist Kaufen immer günstiger als Bauen?

Nicht immer. Bauen ist vertretbar mit echter Platform-Engineering-Kapazität und einem finanzierten Verantwortlichen. Teuer wird es, wenn die Pipeline ein Gefallen von jemandem ist, dessen eigentliche Aufgabe das Ausliefern von Features ist.