Von Gearset zu Serpent migrieren ohne Ausfallzeit

Kurz gesagt: Ein Release-Freeze ist nicht nötig. Ihr Git-Repository ist das portable Gut, beide Tools können also gleichzeitig daran hängen, während Sie Pipeline für Pipeline umziehen, die niedrigste Umgebung zuerst und die Produktion zuletzt. Übernommen 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-Zeitpläne und Deployment-Historie.

Was wird beim Wechsel wirklich übernommen?

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, während das Tool sie zwischen Orgs und diesem Repo bewegt. Das Gut, das Sie jahrelang aufgebaut haben, also Commit-Historie, Branch-Modell und Dateistruktur, gehört Ihnen und bleibt genau dort.

Wird unverändert übernommen:

• 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 Zeitpläne.
• Change-Monitoring-Jobs und ihre Benachrichtigungsregeln.
• Org-Verbindungen und authentifizierte Nutzer, je Umgebung.
• Freigabe-Gates und die Regeln, wer in die Produktion befördern darf.
• Backup-Zeitpläne und aufbewahrte Backup-Daten, die zwischen Anbietern nicht portabel sind.
• Deployment-Historie und Audit-Einträge im alten Tool.

Was prüfen Sie, bevor Sie irgendetwas verbinden?

Klären Sie zuerst Ihr Metadatenformat. Gearset committet im SFDX-Source-Format, wenn es ein leeres Repository initialisiert, und unterstützt 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 Änderung: konvertieren, reviewen, mergen, ein Deployment daraus verifizieren. Konvertieren Sie niemals das Format und wechseln Sie in derselben Woche das Werkzeug. Sonst lässt sich nicht mehr sagen, welche Änderung welche Überraschung verursacht hat.

Wie releasen Sie weiter, während beide Tools verbunden sind?

1. Inventarisieren Sie, was das alte Tool für Sie tut. Deployments, CI-Jobs, Change Monitoring, Backup, Code Review, Sandbox Seeding. Diese Liste ist Ihr Migrations-Backlog und sie ist meist länger, 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 ändert sich für das Team nichts.
3. Bauen Sie die niedrigste Umgebung zuerst neu. Dev oder Integration. Lassen Sie ein Team einen Sprint lang über 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 Änderung, die alte deployt weiter. Jeder Unterschied zwischen den Ergebnissen ist eine Konfigurationslücke, 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 Prüfer 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 Verzögerung. 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 häufigste selbst zugefügte 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 später.
• Backups. Backup-Daten lassen sich in der Regel nicht in wiederherstellbarer Form zu einem anderen Anbieter exportieren. Klären Sie Ihre Aufbewahrung, bevor Sie kündigen.
• Audit-Lücken. In regulierten Umgebungen exportieren Sie die aufbewahrungspflichtige Deployment-Historie, solange der alte Vertrag läuft.

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 überhaupt?

Drei Gründe 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-Hälfte 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 enthält 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 für 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.

Können zwei DevOps-Tools gleichzeitig am selben Repository hängen?

Ja, genau das macht einen Wechsel ohne Ausfallzeit möglich. Die Regel, die es sicher hält: 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 Überlappung für Ihre Aufbewahrungsfrist.

Was passiert mit unserer Deployment-Historie?

Sie bleibt beim alten Tool. Exportieren Sie, was Ihre Prüfer brauchen, solange der Vertrag noch läuft.

Installiert Serpent etwas in unseren Salesforce-Orgs?

Nein. Es verbindet sich ausschließlich über Standard-APIs, es gibt also kein Paket zur Freigabe und später nichts zu deinstallieren.