Salesforce-DevOps-Lektionen vom Web Summit Lissabon 2025

Der Web Summit Lissabon 2025 war keine Salesforce-Veranstaltung, aber Salesforce kam in fast jedem ernsthaften Gespräch vor, das ich mit Gründern und RevOps-Leads führte, die ihr Geschäft auf der Plattform betreiben. Das Muster war immer gleich: Teams deployen Metadaten noch immer von Hand, fürchten noch immer den Freitagsrelease und haben noch immer keinen echten Rollback-Plan. Genau diese Lücke soll Serpent schließen.

Ich war nicht dort, um einen Standspruch aufzusagen. Ich habe zwischen den Talks, in der Investorenlounge und beim Night Summit mit Leuten gesprochen, und Salesforce DevOps tauchte immer wieder als Problem auf, das niemand sauber gelöst hatte.

Warum kam Salesforce-Releasemanagement auf einer allgemeinen Techkonferenz zur Sprache?

Der Web Summit ist breit aufgestellt: Startups, Investoren, Fintech, KI. Aber auffallend viele der Menschen, die ich traf, betrieben wachsende Unternehmen auf Salesforce, entweder als ihr primäres CRM oder als Rückgrat eines Partner-ISV-Produkts. Sobald das Gespräch über "was baut ihr" hinausging, kam Releaseschmerz fast immer zur Sprache, meist ungefragt.

Der rote Faden: Salesforce-Admins und -Entwickler waren Change Sets schon vor Jahren entwachsen, klebten aber noch immer Sandboxes, Tabellen und Slack-Threads zusammen, um einen Release zu koordinieren. Niemand, mit dem ich sprach, beschrieb den eigenen Deploymentprozess als etwas, dem er vertraute.

Welchen Deploymentschmerz beschrieben Gründer und Teams?

Ein paar konkrete Beschwerden wiederholten sich bei nicht verwandten Unternehmen:

• Keine zuverlässige Möglichkeit, vor dem Deployment zu sehen, was sich zwischen einer Sandbox und der Produktion wirklich unterscheidet.
• Merge-Konflikte in Metadaten, die erst nach einem gescheiterten Deployment auftauchen, nicht davor.
• Manuelle Profil- und Permission-Set-Updates, die zwischen Umgebungen vergessen werden.
• Releasefenster, die von der Verfügbarkeit einer einzelnen Person abhängen, weil nur sie die Deploymentreihenfolge versteht.
• Rollbacks, die bedeuten, ein Backup wiederherzustellen, statt eine einzelne Änderung rückgängig zu machen.

Nichts davon ist exotisch. Es ist dieselbe kurze Liste an Problemen, an denen sich Salesforce-DevOps-Tooling seit einem Jahrzehnt abarbeitet. Auffallend war, wie viele Teams, manche weit nach ihrer Series A, das noch immer mit Disziplin und weitergegebenem Wissen lösten statt mit einer Plattform.

Wie bestätigt das Serpents Richtung?

Serpent wurde um die Idee herum gebaut, dass Salesforce-Releasemanagement wie moderne Softwarelieferung aussehen sollte: versionierte Metadaten, ein Umgebungsvergleich, dem man vertrauen kann, und eine Deploymentpipeline, die Konflikte abfängt, bevor sie die Produktion erreichen, nicht danach. Jedes Gespräch in Lissabon bestätigte, dass das immer noch die Lücke ist, kein gelöstes Problem.

Was meine Sicht leicht verschoben hat: wie viele dieser Teams keine reinen Salesforce-Shops waren. Sie verglichen Salesforce-Releasedisziplin mit der CI/CD, die sie für ihren Webstack bereits betreiben, und stellten fest, dass Salesforce deutlich hinterherhinkt. Das ist ein nützlicher Rahmen, wenn man jemandem zeigt, was Serpent tatsächlich tut, denn man erklärt DevOps nicht von Grund auf, sondern erklärt, warum Salesforce zurückliegt.

Ein paar Leute fragten direkt, wie sich Serpent von Tools unterscheidet, die sie schon kannten, besonders Gearset. Lesenswert ist unser Vergleich Serpent gegen Gearset, wenn Sie dort mit Ihrer Bewertung beginnen.

Was sollten Sie mitnehmen, wenn Sie ein Salesforce-DevOps-Tool bewerten?

Wenn Ihnen einer der oben genannten Schmerzpunkte bekannt vorkommt, ist die Lösung selten mehr Prozess. Es ist Tooling, das die manuellen Schritte entfernt: automatischer Vergleich, eine Pipeline, die schlechte Merges blockiert, und ein Rollback-Pfad, der keine vollständige Backup-Wiederherstellung braucht. Salesforces eigene Anleitung zum Application Lifecycle Management macht denselben Punkt: ALM funktioniert nur, wenn das Tooling es konsequent durchsetzt.

Wenn Sie sehen wollen, wie das in der Praxis aussieht: Unsere Preisseite schlüsselt auf, was es braucht, um ein Team von manuellen Deployments wegzubringen, und in unseren Salesforce-DevOps-Guides steht mehr Detail zur Einrichtung.

FAQ

Warum ist Salesforce DevOps auch außerhalb Salesforce-spezifischer Veranstaltungen relevant?

Weil die meisten wachsenden Unternehmen Salesforce heute neben einem modernen Software-Stack betreiben, und Gründer zunehmend dieselbe Lieferdisziplin von beiden erwarten.

Was war der häufigste Salesforce-Deploymentfehler, den Gründer beschrieben?

Sich auf das weitergegebene Wissen einer einzelnen Person zur Deploymentreihenfolge zu verlassen statt auf eine wiederholbare, versionierte Pipeline.

Unterscheidet sich Salesforce-Releasemanagement von allgemeinem CI/CD?

Die Prinzipien sind dieselben, aber Salesforce-Metadatenabhängigkeiten und orgspezifische Konfiguration machen generische CI/CD-Tools ohne Salesforce-bewusstes Tooling zu einer schlechten Wahl.

Wie unterscheidet sich Serpent von manuellen Change Sets?

Serpent ersetzt das manuelle Zusammenstellen von Change Sets durch automatischen Vergleich, Konflikterkennung und eine Pipeline, die speziell für Salesforce-Metadaten gebaut ist.