sfdx-hardis und der Open-Source-Stack für Salesforce DevOps: ehrlich betrachtet

Der Open-Source-Stack für Salesforce DevOps ist real, ausgereift und kostenlos, und er deckt mehr ab, als die meisten annehmen. sfdx-hardis macht aus der Salesforce CLI eine echte Pipeline, sfdx-git-delta berechnet Deltas, Code Analyzer übernimmt die statische Analyse, und deine CI-Plattform führt das Ganze aus. Was er nicht liefert: einen Verantwortlichen, ein System of Record und jemanden, den du um zwei Uhr nachts anrufen kannst. Genau diese Hälfte bauen Teams am Ende selbst.

Was ist der Open-Source-Stack für Salesforce DevOps?

Grob fünf Schichten, jede eigenständig gepflegt:

• Orchestrierung. sfdx-hardis, eine freie Open-Source-Schicht über der Salesforce CLI, geführt von Nicolas Vuillamy und Cloudity. Sie definiert CI/CD-Pipelines, tägliche Metadaten-Backups und Org-Monitoring sowie KI-generierte Projektdokumentation. Sie läuft auf GitHub, GitLab, Azure DevOps und Bitbucket und installiert sich als sf-Plugin, VS-Code-Erweiterung oder Docker-Image.
• Delta-Berechnung. sfdx-git-delta, das Community-Plugin, das aus einem Git-Diff eine package.xml und eine destructiveChanges.xml macht.
• Qualitätstore. Salesforce Code Analyzer, quelloffen und CLI-nativ, vereint PMD, ESLint, CPD, RetireJS, eine Regex-Engine und einen Flow-Scanner hinter einer YAML-Konfiguration.
• Modulare Builds. sfp von flxbl, Nachfolger von sfpowerscripts aus DxAtScale, für Teams, die ihre Org als Pakete modellieren.
• Der Runner. GitHub Actions, GitLab CI, Azure Pipelines oder Jenkins, die tatsächlich ausführen.

Gut zusammengesetzt ist das eine ernstzunehmende Pipeline. Wer behauptet, Salesforce DevOps gehe nicht ohne Lizenz, hat länger nicht hingesehen.

Was deckt sfdx-hardis wirklich ab?

Mehr als eine CLI-Hülle. Drei Dinge stechen hervor.

Erstens nimmt es das Admin-Problem ernst. Die VS-Code-Erweiterung lässt Nicht-Entwickler per Klick einen Pull Request erzeugen, eine bewusste Antwort darauf, dass die meisten Salesforce-Teams keine Entwicklerteams sind.

Zweitens behandelt es Monitoring als eigenständige Aufgabe und nicht als Nebenprodukt: geplante Metadaten-Backups und Org-Überwachung laufen in einem eigenen Repository, getrennt von der Auslieferung.

Drittens war es früh bei KI-Agenten. Über 130 seiner Befehle akzeptieren ein --agent-Flag für nicht-interaktive Ausführung durch Coding-Agenten, eine wirklich vorausschauende Designentscheidung für ein kostenloses Werkzeug.

Was deckt Open Source gut ab?

• Metadaten zwischen Orgs deployen, mit sauber behandelten Deltas und Löschungen.
• Statische Analyse und Qualitätstore in der CI.
• Geplante Backups und Drift-Überwachung.
• Paket-Builds für Teams, die ohnehin in Paketen denken.
• Kosten. Es gibt keine Lizenz, und für ein Team mit einem motivierten Engineer zählt das.

Liegt dein Engpass bei einem dieser fünf Punkte, lautet die ehrliche Antwort: Du musst vermutlich nichts kaufen.

Wo bauen Teams die fehlende Hälfte doch selbst?

Hier wird das Gespräch üblicherweise in beide Richtungen unehrlich. Also konkret:

Ein Verantwortlicher

Jede Schicht oben ist eine Abhängigkeit, die du pflegst. Node-Upgrades, Breaking Changes der CLI, Plugin-Versionen, ein abgedriftetes Docker-Image. In keinem einzelnen Monat ist das viel Arbeit, und es ist immer dieselbe Person. Geht sie, wird die Pipeline zum Spukhaus.

Ein System of Record

CI-Logs sagen, was ein Job getan hat. Sie sagen nicht, welche Änderung gerade in UAT liegt, wann sie dort ankam, wer sie freigegeben hat oder was im letzten Release ausgeliefert wurde. Teams bauen das in einer Tabelle, einem Jira-Board oder einer kleinen internen App nach. Das ist das am häufigsten nachgebaute Stück.

Zugriffskontrolle, die nicht die der CI-Plattform ist

Wer darf in die Produktion deployen, wer genehmigt, wer sieht welches Projekt. Branch Protection und Environment Rules decken einen Teil ab. Projektbezogene Rechte, SSO und ein Audit-Log, das ein Prüfer akzeptiert, sind eine andere Baustelle.

Eine Eingangstür für Nicht-Entwickler

sfdx-hardis löst das besser als die meisten, und eine VS-Code-Erweiterung bleibt eine Installation, ein Update-Pfad und ein Denkmodell. Teams, die mehrheitlich aus Admins und Beratern bestehen, hüllen die Pipeline am Ende oft doch in etwas Ticketförmiges.

ISV- und Paketauslieferung jenseits des Builds

Ein 2GP-Paket zu bauen ist gelöst. Zu wissen, welche Version jede Subscriber-Org fährt, paketübergreifende Abhängigkeiten aufzulösen und ein AppExchange-Release abzusichern, ist nicht dasselbe Problem, und der Open-Source-Stack überlässt es weitgehend dir.

Jemand zum Anrufen

Open Source gibt dir eine Community und Quellcode, was in mancher Hinsicht mehr ist als ein Anbieter, und in einer weniger: Es gibt kein SLA an deinem Release-Abend.

Wenn Sie den Open-Source-Stack gegen kommerzielle Plattformen abwägen, stellt unser Vergleich der Salesforce DevOps-Plattformen selbst gebaute CLI-Pipelines neben neun weitere Optionen.

Wer sollte den Open-Source-Stack betreiben, und wer nicht?

Betreibe ihn, wenn du einen Engineer hast, der Auslieferungswerkzeuge besitzen will, dein Team mit Git und YAML vertraut ist und der Org-zu-Org-Fluss die ganze Aufgabe ist. Das beschreibt viele gute Teams, und die müssen sich dafür nicht rechtfertigen.

Kaufe stattdessen, wenn der Großteil deines Teams nie ein Terminal öffnet, wenn niemand die Pipeline als dauerhaften Nebenjob besitzen will, oder wenn du auditierbare Zugriffskontrolle und Versionsverfolgung je Subscriber brauchst. Nicht weil die Open-Source-Werkzeuge schwach wären, sondern weil du die fehlende Hälfte mit Leuten bauen würdest, deren Tagesgeschäft ein anderes ist.

Genau für diese Lücke ist Serpent gebaut: ticketbasierte Deployments mit Git im Hintergrund, KI-Code-Review bei Pull Requests, native 1GP-, 2GP- und AppExchange-Release-Workflows, Versionsverwaltung über Subscriber-Orgs, Backup & Restore ab Scale, Org-Vergleich gegen Drift und ein nativer MCP-Server, damit Agenten Deployments über Vorabprüfungen und menschliche Freigabe steuern. Pauschalpreis pro Unternehmen und ein kostenloser Tarif, falls du die Behauptung prüfen willst.

Open Source ist hier nicht der Gegner. Sie ist die Referenzimplementierung, und sie hält die ganze Kategorie ehrlich darüber, was selbstverständlich sein sollte.

FAQ

Ist sfdx-hardis kostenlos?

Ja. Es ist Open Source ohne Lizenzkosten, gepflegt von Cloudity und Community-Beitragenden, und Cloudity bietet kostenpflichtige Professional Services darum herum an.

Kann sfdx-hardis Copado oder Gearset ersetzen?

Für Org-zu-Org-Auslieferung mit technischem Verantwortlichen deckt es dasselbe Feld ab. Der Unterschied zeigt sich in Governance, Zugang für Nicht-Entwickler und Herstellersupport, nicht in der Deployment-Mechanik.

Brauche ich die Salesforce CLI dafür?

Ja. Es läuft auf Node.js und der Salesforce CLI und installiert sich als sf-Plugin, VS-Code-Erweiterung oder Docker-Image.

Ist Salesforce DevOps Center Open Source?

Nein. Es ist kostenlos und Salesforce-nativ, was etwas anderes ist. Open Source heißt, du kannst den Code lesen und ändern.

Was kostet der kostenlose Stack wirklich?

Wartungszeit und Schlüsselpersonenrisiko. Plane einen benannten Verantwortlichen und ein paar Stunden im Monat ein, dann ist der Tausch fair. Bleibt er ohne Verantwortlichen, ist er nicht mehr kostenlos.