Salesforce-DevOps-Lektionen vom Web Summit Lissabon 2025

Der Web Summit Lissabon 2025 war keine Salesforce-Veranstaltung, aber Salesforce kam in fast jedem ernsthaften Gesprach vor, das ich mit Gruendern und RevOps-Leads fuhrte, die ihr Geschaeft auf der Plattform betreiben. Das Muster war immer gleich: Teams deployen Metadaten noch immer von Hand, fuerchten noch immer den Freitagsrelease und haben noch immer keinen echten Rollback-Plan. Genau diese Luecke soll Serpent schliessen.

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 geloest 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 primares CRM oder als Ruckgrat eines Partner-ISV-Produkts. Sobald das Gesprach uber "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 Gruender und Teams?

Ein paar konkrete Beschwerden wiederholten sich bei nicht verwandten Unternehmen:

• Keine zuverlassige Moeglichkeit, 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 Verfuegbarkeit einer einzelnen Person abhaengen, weil nur sie die Deploymentreihenfolge versteht.
• Rollbacks, die bedeuten, ein Backup wiederherzustellen, statt eine einzelne Aenderung ruckgangig 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 loesten statt mit einer Plattform.

Wie bestatigt 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 abfaengt, bevor sie die Produktion erreichen, nicht danach. Jedes Gesprach in Lissabon bestatigte, dass das immer noch die Luecke ist, kein geloestes 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 fur ihren Webstack bereits betreiben, und stellten fest, dass Salesforce deutlich hinterherhinkt. Das ist ein nuetzlicher Rahmen, wenn man jemandem zeigt, was Serpent tatsachlich tut, denn man erklart DevOps nicht von Grund auf, sondern erklart, warum Salesforce zuruckliegt.

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 Loesung 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 vollstandige 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 schluesselt 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 ausserhalb Salesforce-spezifischer Veranstaltungen relevant?

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

Was war der haeufigste Salesforce-Deploymentfehler, den Gruender 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-Metadatenabhaengigkeiten 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 fur Salesforce-Metadaten gebaut ist.