Von Gearset zu Serpent migrieren ohne Ausfallzeit

Kurz gesagt: Ein Release-Freeze ist nicht noetig. Ihr Git-Repository ist das portable Gut, beide Tools koennen also gleichzeitig daran haengen, waehrend Sie Pipeline fuer Pipeline umziehen, die niedrigste Umgebung zuerst und die Produktion zuletzt. Uebernommen werden das Repo, seine Branches und seine Historie. Neu gebaut wird alles, was beim Anbieter lag: CI- und Monitoring-Jobs, Org-Verbindungen, Freigabe-Gates, Backup-Zeitplaene und Deployment-Historie.

Was wird beim Wechsel wirklich uebernommen?

Das Denkmodell, das die Sache einfach macht: Metadaten liegen in Git, die Orchestrierung liegt beim Anbieter. Die Dokumentation von Gearset beschreibt Ihr Repository als den Ort, an dem die Metadaten liegen, waehrend das Tool sie zwischen Orgs und diesem Repo bewegt. Das Gut, das Sie jahrelang aufgebaut haben, also Commit-Historie, Branch-Modell und Dateistruktur, gehoert Ihnen und bleibt genau dort.

Wird unveraendert uebernommen:

• Das Git-Repository mit jedem Branch, Tag und Commit.
• Ihre Verzeichnisstruktur und Ihr Metadatenformat, solange das neue Tool es liest.
• Branch-Protection-Regeln und Reviewer-Listen, denn die liegen in GitHub, GitLab oder Bitbucket.
• Alles, was bereits Code ist: Skripte, Apex-Tests, Konfiguration der statischen Analyse.

Muss neu gebaut werden:

• CI/CD-Job-Definitionen und ihre Zeitplaene.
• Change-Monitoring-Jobs und ihre Benachrichtigungsregeln.
• Org-Verbindungen und authentifizierte Nutzer, je Umgebung.
• Freigabe-Gates und die Regeln, wer in die Produktion befoerdern darf.
• Backup-Zeitplaene und aufbewahrte Backup-Daten, die zwischen Anbietern nicht portabel sind.
• Deployment-Historie und Audit-Eintraege im alten Tool.

Was pruefen Sie, bevor Sie irgendetwas verbinden?

Klaeren Sie zuerst Ihr Metadatenformat. Gearset committet im SFDX-Source-Format, wenn es ein leeres Repository initialisiert, und unterstuetzt daneben das Metadata-API-Format, ein geerbtes Repo kann also legitim in beidem vorliegen. Ein Formatkonflikt ist genau das, was einen ruhigen Parallelbetrieb in eine Wand aus falschen Diffs verwandelt.

Liegt das Repo im Metadata-API-Format und Sie wollen konvertieren, machen Sie daraus eine eigene Aenderung: konvertieren, reviewen, mergen, ein Deployment daraus verifizieren. Konvertieren Sie niemals das Format und wechseln Sie in derselben Woche das Werkzeug. Sonst laesst sich nicht mehr sagen, welche Aenderung welche Ueberraschung verursacht hat.

Wie releasen Sie weiter, waehrend beide Tools verbunden sind?

1. Inventarisieren Sie, was das alte Tool fuer Sie tut. Deployments, CI-Jobs, Change Monitoring, Backup, Code Review, Sandbox Seeding. Diese Liste ist Ihr Migrations-Backlog und sie ist meist laenger, als irgendjemand erinnert.
2. Verbinden Sie das neue Tool nur lesend. Richten Sie es auf dasselbe Repository und dieselben Orgs und lassen Sie Vergleiche laufen, ohne zu deployen. Am ersten Tag aendert sich fuer das Team nichts.
3. Bauen Sie die niedrigste Umgebung zuerst neu. Dev oder Integration. Lassen Sie ein Team einen Sprint lang ueber die neue Pipeline liefern, alle anderen bleiben auf dem alten Weg.
4. Lassen Sie beide einen vollen Release-Zyklus laufen. Die neue Pipeline validiert jede Aenderung, die alte deployt weiter. Jeder Unterschied zwischen den Ergebnissen ist eine Konfigurationsluecke, die Sie kostenlos finden.
5. Ziehen Sie UAT und Staging um. Jetzt ist die Pipeline-Form bewiesen, das Freigabemodell abgestimmt und die Audit-Ausgabe so, wie Ihre Pruefer sie erwarten.
6. Ziehen Sie die Produktion zuletzt um, in einem normalen Change-Fenster. Es gibt kein Cutover-Ereignis, nur die letzte Umgebung, die umzieht.
7. Stilllegen mit Verzoegerung. Behalten Sie das alte Abo mindestens eine Backup-Aufbewahrungsfrist lang, widerrufen Sie dann Org-Verbindungen und entfernen Sie Deploy Keys und Webhooks.

Welche Fallen lauern im Parallelbetrieb?

• Zwei Schreiber, ein Branch. Vereinbaren Sie, dass immer nur ein Tool auf einen Branch committet. Konkurrierende Commits sind die haeufigste selbst zugefuegte Wunde einer Migration.
• Doppelte Status-Checks. Beide Tools wollen an Pull Requests melden. Machen Sie nur einen davon verpflichtend, sonst warten Merges auf eine Pipeline, die Sie gerade abschalten.
• Doppeltes Deployment. Haben beide Tools einen geplanten Job auf dieselbe Ziel-Org, deployen Sie zweimal. Deaktivieren Sie den alten Zeitplan in dem Moment, in dem der neue live geht, nicht eine Woche spaeter.
• Backups. Backup-Daten lassen sich in der Regel nicht in wiederherstellbarer Form zu einem anderen Anbieter exportieren. Klaeren Sie Ihre Aufbewahrung, bevor Sie kuendigen.
• Audit-Luecken. In regulierten Umgebungen exportieren Sie die aufbewahrungspflichtige Deployment-Historie, solange der alte Vertrag laeuft.

Wie lange dauert das Ganze?

Die Bremse ist Ihre Release-Kadenz, nicht das Werkzeug. Ein Team im Zweiwochenrhythmus ist meist nach zwei Zyklen durch: ein Parallelzyklus und ein Produktionszyklus. Serpent ist pro Workspace in unter 15 Minuten eingerichtet und Onboarding-Sitzungen mit unserem Team sind kostenlos, der Kalender besteht also vor allem aus dem Warten auf Ihre eigenen Change-Fenster.

Warum wechseln Teams ueberhaupt?

Drei Gruende kehren immer wieder. Preise, die mit Nutzern und mit der Zahl der CI/CD-Orgs wachsen. Ein Ablauf, der Git-Sicherheit voraussetzt, die die Admin-Haelfte des Teams nicht hat. Und Paketauslieferung als separater Kauf. Serpent rechnet pauschal pro Unternehmen ab, arbeitet ticketbasiert mit Git im Hintergrund, installiert nichts in Ihrer Org und enthaelt 1GP-, 2GP- und AppExchange-Release-Workflows in jedem Plan, auch im kostenlosen Essentials. Weitere Umstiegs-Playbooks finden Sie in unserer SF-Guides-Bibliothek.

FAQ

Brauchen wir fuer den Wechsel einen Release-Freeze?

Nein. Bauen Sie Umgebungen nacheinander neu und lassen Sie die alte Pipeline deployen, bis die neue einen vollen Release-Zyklus validiert hat.

Koennen zwei DevOps-Tools gleichzeitig am selben Repository haengen?

Ja, genau das macht einen Wechsel ohne Ausfallzeit moeglich. Die Regel, die es sicher haelt: immer nur ein Schreiber pro Branch.

Wandern unsere bestehenden Backups mit?

Nein. Backup-Daten sind zwischen Anbietern nicht in wiederherstellbarer Form portabel, planen Sie also eine Ueberlappung fuer Ihre Aufbewahrungsfrist.

Was passiert mit unserer Deployment-Historie?

Sie bleibt beim alten Tool. Exportieren Sie, was Ihre Pruefer brauchen, solange der Vertrag noch laeuft.

Installiert Serpent etwas in unseren Salesforce-Orgs?

Nein. Es verbindet sich ausschliesslich ueber Standard-APIs, es gibt also kein Paket zur Freigabe und spaeter nichts zu deinstallieren.