DevOps-Werkzeuge für Salesforce im Vergleich

Für Salesforce DevOps gibt es drei Wege: den Standard von Salesforce mit Change Sets, Salesforce CLI und Lifecycle Center (bis Oktober 2026 DevOps Center), Open Source mit sfdx-hardis und kommerzielle Plattformen wie Gearset, Copado und Flosum. Change Sets reichen für ein Programm mit mehreren Partnern nicht, weil sie keine Versionskontrolle kennen. Lifecycle Center passt zu kleinen Admin-Teams auf GitHub.com oder Bitbucket Cloud. sfdx-hardis passt, wenn Sie die Pipeline selbst besitzen und betreiben wollen. Die kommerziellen Plattformen lohnen sich, wenn Sie Oberfläche, Zusatzmodule und Herstellersupport einkaufen wollen. Entscheiden sollten Git-Plattform, Team, Partner, Eigentum, Kosten und Support, in dieser Reihenfolge.

Was bringt Salesforce selbst mit?

Salesforce liefert drei Werkzeuge ohne zusätzliche Lizenz. Sie bauen aufeinander auf, lösen aber sehr unterschiedliche Probleme.

Change Sets

Ein Change Set überträgt Anpassungen von einer Org in eine andere, typischerweise aus einer Sandbox in die Produktion. Laut Salesforce-Hilfe zu Change Sets (öffnet in einem neuen Tab) gelten drei Grenzen: Change Sets enthalten nur Änderungen, die man über das Setup-Menü machen kann, sie enthalten keine Daten, und sie funktionieren nur zwischen Orgs, die zur selben Produktion gehören und über eine Deployment-Verbindung verknüpft sind. Ein eingehendes Change Set wird immer als Ganzes deployt.

Salesforce CLI

Die Salesforce CLI (öffnet in einem neuen Tab) ist das Kommandozeilenwerkzeug von Salesforce für Entwicklung und Build-Automatisierung. Sie legt Orgs an, synchronisiert Quellcode in beide Richtungen zwischen Projekt und Org und läuft auf dem Rechner des Entwicklers oder in einer CI-Pipeline. Befehle wie sf project deploy validate (öffnet in einem neuen Tab) prüfen ein Deployment, ohne etwas zu ändern, standardmäßig mit RunLocalTests.

Die CLI ist das Fundament, den Prozess darüber liefert sie nicht. Wer nur sie nutzt, baut Branch-Regeln, Delta-Deployments, Benachrichtigungen und Tests selbst. Die CLI lässt sich über Plugins erweitern, und genau darauf setzt sfdx-hardis auf.

Lifecycle Center, früher DevOps Center

Seit Oktober 2026 heißt das Next Generation DevOps Center Lifecycle Center (öffnet in einem neuen Tab). Es ist in die Plattform eingebaut, ein Paket wird nicht installiert. In einer Hub-Org legen Sie Projekte, Pipelines und Work Items an; ein Work Item wandert per Klick von Stufe zu Stufe, im Hintergrund entstehen Branches, Pull Requests und Deployments. Tests mit Test-Suites und Quality Gates sind standardmäßig dabei, eine Governance-Funktion für Entwickler und Coding-Agenten ist in Beta. Salesforce beschreibt Lifecycle Center ausdrücklich als Alternative zu Change Sets.

Die Hinweise zur Einrichtung (öffnet in einem neuen Tab) enthalten die Punkte, die in der Fertigung oft den Ausschlag geben:

Wie Lifecycle Center im Detail gegen sfdx-hardis steht, habe ich im Vergleich sfdx-hardis oder DevOps Center beschrieben. Kurz: Bei Lifecycle Center ist Salesforce die Steuerzentrale und Git der Speicher.

sfdx-hardis: der Open-Source-Weg

sfdx-hardis (öffnet in einem neuen Tab) ist ein kostenloses Open-Source-Toolkit von Cloudity und einer großen Community. Es besteht aus einem Plugin für die Salesforce CLI, einer VS-Code-Erweiterung und Docker-Images für die Pipeline. Die Pipeline läuft auf der Git-Plattform des Kunden: GitHub, GitLab, Azure DevOps, Bitbucket oder Jenkins. Neben CI/CD bringt es Org-Monitoring, Metadaten-Backup und generierte Dokumentation mit.

Ich setze sfdx-hardis seit rund zwei Jahren in Kundenprojekten ein. Für Programme mit mehreren Implementierungspartnern zählt für mich, dass der ganze Prozess als Konfiguration im Repository des Kunden liegt. Mit Branch-Schutz ändert ihn ein Partner nur per Pull Request, den der Kunde freigibt.

Der Preis dafür ist Know-how. Lizenzgebühren fallen nicht an, wohl aber CI-Minuten, die Einrichtung und eine Person beim Kunden, die die Pipeline versteht. Unterstützung bietet Cloudity als Dienstleister an, nötig ist sie nicht. Was das Toolkit alles abdeckt, steht in meiner Einführung in sfdx-hardis.

Was können Gearset, Copado und Flosum besser?

Die drei großen kommerziellen Plattformen verkaufen das, was Open Source nicht liefert: eine fertige Oberfläche, Zusatzmodule aus einer Hand und einen Hersteller, der für den Betrieb geradesteht. Die DevOps-Kurse aller drei Anbieter habe ich durchgearbeitet. Die folgenden Angaben stammen von den Seiten der Hersteller, Stand Oktober 2026.

Gearset läuft als Dienst außerhalb Ihrer Org, laut Gearset (öffnet in einem neuen Tab) muss in den Orgs nichts installiert werden. Gearset unterstützt GitHub, GitLab, Bitbucket, Azure DevOps, AWS CodeCommit und generisches Git. Die Stärke ist der visuelle Vergleich von Metadaten zwischen Orgs, dazu Pipelines, Backup, Sandbox Seeding mit maskierten Daten, Observability und Code Reviews als eigene Produkte. Gearset ist der einzige der drei mit öffentlicher Preisliste (öffnet in einem neuen Tab):

215 USD

Starter-Paket für Vergleich und Deployment, pro Gearset-Nutzer und Monat

ab 550 USD

Automatisierungspaket mit Pipelines und CI/CD, pro Team und Monat

30 Tage

Testzeitraum ohne Kreditkarte

Copado beschreibt sich auf seiner Website (öffnet in einem neuen Tab) als Salesforce-native DevOps-Lösung und bietet seit April 2026 die Editionen Agentia Advanced und Agentia Pro an. Laut Copado-Dokumentation (öffnet in einem neuen Tab) richtet sich die Edition Agentia Advanced an Teams mit einer Produktions-Org und 3 bis 10 Personen, Agentia Pro an Unternehmen mit mehreren Orgs, mit Quality Gates, Governance und dem Orchestrate Agent. Dazu kommen Robotic Testing und ein Context Hub für die KI-Agenten. Als Git-Plattformen nennt die Dokumentation der Advanced-Edition GitHub, GitLab, Bitbucket und Azure (öffnet in einem neuen Tab), jeweils auch selbst gehostet. Eine öffentliche Preisliste habe ich bei Copado nicht gefunden.

Flosum ist laut Hersteller (öffnet in einem neuen Tab) ebenfalls Salesforce-native und hat eine eigene, metadatenbewusste Versionskontrolle. Git ist dort ausdrücklich optional; angebunden werden können GitHub, GitLab, Bitbucket und Azure DevOps. Flosum betont Nachweise für Audits, die direkt in der Pipeline entstehen, und nennt Regelwerke wie SOX und GxP. Das ist für Hersteller von Medizintechnik oder Laborgeräten interessant. Neben DevOps gibt es Backup and Archive, einen Data Migrator und ein Trust Center. Die Preise sind laut Flosum angebotsbasiert.

Weitere Anbieter wie AutoRABIT oder Blue Canvas habe ich für dieses Kapitel nicht geprüft. Wie Copado und Gearset gerade KI-Agenten einbauen und was Sie vorher fragen sollten, steht in Copado, Gearset und Provar mit KI-Agenten.

Nach welchen Kriterien wählen Sie aus?

Ich gehe die Kriterien in dieser Reihenfolge durch, weil die ersten am meisten ausschließen.

1. Git-Plattform. Welche Plattform betreibt Ihre IT schon? Auf Azure DevOps oder einem selbst gehosteten GitLab fällt Lifecycle Center heute weg. Die Git-Plattform wechselt man nicht für ein Release-Werkzeug.
2. Team. Wer arbeitet täglich mit dem Werkzeug: Admins, die klicken, oder Entwickler, die mit VS Code und Branches umgehen? Und gibt es beim Kunden jemanden, der eine Pipeline verantworten kann?
3. Partner. Wie viele Teams und Implementierungspartner arbeiten an derselben Org? Ab dem zweiten Partner brauchen Sie Pull Requests mit Pflicht-Review und einen Prozess, den alle gleich nutzen.
4. Eigentum. Läuft der Vertrag auf Sie, haben Ihre Mitarbeitenden Admin-Rechte, liegt das Repository in Ihrer Organisation? Warum das zählt, steht in warum Kunden ihre DevOps-Tools selbst besitzen sollten.
5. Kosten. Lizenz, CI-Minuten, Einrichtung und vor allem die Release-Rolle. Nach meiner Einschätzung kostet diese Rolle in einem Programm mit mehreren Partnern mehr als die Lizenz des Werkzeugs.
6. Support. Brauchen Sie einen Vertrag mit Reaktionszeiten, oder reichen Community und ein Dienstleister bei Bedarf?

Die Entscheidungsmatrix

Die Fakten in der Tabelle stammen von den oben verlinkten Herstellerseiten. Die Zeile „Passt zu“ ist meine Einschätzung.

Kriterium	Change Sets	Lifecycle Center	sfdx-hardis	Gearset	Copado	Flosum
Git-Plattformen	keine	GitHub.com inkl. Enterprise Cloud, Bitbucket Cloud	GitHub, GitLab, Azure DevOps, Bitbucket, Jenkins	GitHub, GitLab, Bitbucket, Azure DevOps, AWS CodeCommit, generisches Git	GitHub, GitLab, Bitbucket, Azure, auch selbst gehostet	eigene Versionskontrolle, Git optional
Wo der Prozess lebt	Setup der Orgs	Hub-Org	Repository und CI des Kunden	Gearset-Dienst	laut Copado Salesforce-nativ	laut Flosum Salesforce-nativ
Bedienung	Klicks im Setup	Klicks in Salesforce	VS Code und CLI	Weboberfläche	Oberfläche des Herstellers	Oberfläche des Herstellers
Zusatzmodule	keine	Tests, Quality Gates, Governance (Beta)	Monitoring, Metadaten-Backup, Dokumentation	Backup, Seeding, Observability, Code Reviews	Robotic Testing, KI-Agenten	Backup, Data Migrator, Trust Center
Lizenzkosten	keine	keine	keine	öffentlich, ab 215 USD pro Nutzer und Monat	keine öffentliche Preisliste gefunden	auf Anfrage
Support	Salesforce	Salesforce	Community, Cloudity als Dienstleister	Hersteller	Hersteller	Hersteller
Passt zu	wenigen Admins, kleinen Änderungen	einem Admin-Team ohne Partner auf GitHub oder Bitbucket Cloud	mehreren Partnern, wenn eine Release-Rolle beim Kunden existiert	gemischten Teams, die Vergleich und Module aus einer Hand wollen	großen Programmen mit mehreren Orgs und Governance-Bedarf	regulierten Umgebungen mit Audit-Pflichten

Beispiel: zwei Partner, Azure DevOps, bisher Change Sets

Ein Maschinenbauer betreibt Sales Cloud für den Händlervertrieb, Service Cloud und Field Service für den Außendienst und eine SAP-Schnittstelle für Ersatzteile. Zwei Implementierungspartner arbeiten an derselben Org, einer davon mit einem Nearshore-Team. Die IT hat Azure DevOps für alle anderen Anwendungen. Bisher wird mit Change Sets deployt.

Die Git-Plattform schließt Lifecycle Center aus. Change Sets scheiden wegen der zwei Partner aus. Es bleiben sfdx-hardis, Gearset, Copado und Flosum. Hat der Hersteller jemanden, der eine Pipeline auf Azure DevOps verantworten kann oder diese Rolle aufbauen will, würde ich mit sfdx-hardis starten und die gesparten Lizenzkosten in genau diese interne Release-Rolle stecken. Fehlt diese Person und soll sie auch nicht entstehen, ist eine kommerzielle Plattform mit Herstellersupport die ehrlichere Wahl. Dann zählt, dass der Vertrag auf den Hersteller läuft und nicht auf einen der Partner.

Wie machen Sie die Entscheidung verbindlich?

Die Werkzeugwahl gehört an den Anfang eines Programms und gilt für jeden Partner. Wer später dazukommt, arbeitet im bestehenden Setup und bringt kein eigenes mit. Das gehört in den Vertrag, wie in Kapitel 2 zu Eigentum und Rollen beschrieben.

Drei Regeln halte ich für nicht verhandelbar:

• Ein Werkzeug pro Repository entscheidet über Merges und Promotions. Zwei Werkzeuge auf denselben Stage-Branches ergeben zwei Release-Prozesse.
• Lizenzen und Admin-Rechte liegen beim Kunden. Das gilt für Gearset, Copado und Flosum genauso wie für die Git-Plattform unter sfdx-hardis.
• Die Historie bleibt portabel. Bei Flosum, wo Git optional ist, würde ich die Git-Anbindung trotzdem einschalten, damit die Versionsgeschichte auch ohne das Werkzeug lesbar bleibt.

Die Sandboxes und Branches, auf denen jedes dieser Werkzeuge aufsetzt, beschreibt Kapitel 3. Wie daraus eine Pipeline mit Pull Requests, Validierungen und Delta-Deployments wird, folgt in Kapitel 5. Bei der Auswahl und dem Aufbau unterstütze ich im Rahmen von DevOps und Release-Management und, wenn mehrere Partner beteiligt sind, in der Partnersteuerung.