Von Copado zu Serpent migrieren: ein Schritt-für-Schritt-Playbook

Kurze Antwort: Sie brauchen keinen Code-Freeze, und Sie migrieren keine Daten. Ihre Metadaten liegen bereits in Git, der Wechsel von Copado zu Serpent ist also ein Tausch der Steuerungsebene: Sie bauen die Pipeline-Definition neu, lassen beide Werkzeuge einen vollständigen Release-Zyklus nebeneinander laufen und übergeben dann die Produktionsfreigabe an die neue Pipeline, während die alte als Rückfallebene installiert bleibt. Planen Sie in Release-Zyklen, nicht in Kalendertagen.

Was bewegt sich wirklich, und was nicht?

Hier präzise zu sein nimmt den meisten Druck aus dem Raum:

• Nichts muss migriert werden. Ihre Wahrheitsquelle ist Ihr Git-Repository, und das bleibt genau dort, wo es ist, samt Historie.
• Zurück bleiben die Datensätze, die nur in einem Managed Package existieren: User Stories, Promotions, Deployment-Datensätze und alle darauf gebaute Automatisierung. Copado ist in Ihrer Org installiert, diese Objekte gehen also mit dem Package.
• Neu aufgebaut wird die Pipeline-Definition: Umgebungen und ihre Zugangsdaten, Reihenfolge der Stufen, Freigaberegeln, Qualitätstore, geplante Jobs und die Ticketing-Anbindung.

Diese letzte Liste ist das gesamte Projekt. Es ist Konfigurationsarbeit, und deshalb liest sich das als Zuordnungsübung und nicht als Migration.

Wie übersetzen sich Copado-Begriffe in eine Git-native Pipeline?

Copado modelliert das Release in Salesforce-Datensätzen. Eine Git-native Pipeline modelliert es im Repository. Die Übersetzung ist fast eins zu eins:

• User Story wird zu einem Work Item mit einem Branch daran.
• Der Feature-Branch je User Story bleibt ein Feature-Branch. Die Namenskonvention können Sie behalten, dann liest sich die Historie durchgehend.
• Promotion und der Promotion-Branch werden zu einem Pull Request in den nächsten Umgebungs-Branch.
• Der Deployment-Datensatz wird zu einem Pipelinelauf mit eigenem Log, Ergebnis und Rückfallpunkt.
• Umgebung oder Stufe wird zu einer Umgebung, die auf einen Branch zeigt.
• Back-Promotion wird zu einem Merge zurück nach unten aus dem höheren Branch.
• Compliance- und Qualitätstore werden zu Pull-Request-Prüfungen: Tests, statische Analyse, KI-Code-Review.

Wie lautet das Schritt-für-Schritt-Runbook?

1. Inventur, ein bis zwei Tage. Listen Sie jede Umgebung, jeden Branch, jede Stufe, jeden Freigebenden, jeden geplanten Job, jedes Qualitätstor und jede Integration mit einer verantwortlichen Person. Hat eine Stufe niemanden, ist das Ihr erster Befund.
2. Spiegeln Sie die Pipeline, nur lesend. Verbinden Sie dieselben Orgs und dasselbe Repository mit Serpent, ohne etwas zu deployen. Das Verbinden dauert Minuten. Dann vergleichen Sie: Sind beide Werkzeuge sich einig, was aktuell in jeder Umgebung liegt? Jede Abweichung ist Drift, die Sie vorher schon hatten.
3. Schatten Sie ein Release. Jede Änderung läuft wie gewohnt durch Copado und zusätzlich durch die neue Pipeline in eine freie Sandbox. Vergleichen Sie die Deploy-Pläne. Die Unterschiede werden Ihre Befundliste und betreffen meist Profiles, Permission Sets und Flows.
4. Fahren Sie ein echtes Release parallel. Die neue Pipeline befördert nach UAT, die bestehende übernimmt noch die Produktion. Das ist der risikokontrollierte Mittelpunkt, und hier gewinnen die Freigebenden Vertrauen.
5. Schalten Sie um. Die neue Pipeline führt die Produktionsfreigabe aus. Lassen Sie Copado installiert und unberührt, denn das ist Ihre Rückfallebene: Scheitert die Freigabe, läuft das nächste Release wieder darüber.
6. Bauen Sie nach zwei sauberen Releases ab. Historie exportieren, zuerst die alten geplanten Jobs abschalten, dann das Managed Package in einer Sandbox deinstallieren, bevor Sie die Produktion anfassen.

Was macht man mit der User-Story-Historie?

An dieser Frage bleiben Migrationen hängen, und die ehrliche Antwort lautet: Versuchen Sie nicht, sie zu importieren.

• Historische Datensätze sind nur in dem Werkzeug sinnvoll, das sie erzeugt hat. Importierte User Stories ohne lebende Pipeline dahinter sind Dekoration und führen in einem Jahr jemanden in die Irre.
• Exportieren Sie stattdessen. User Stories, Promotions und Deployments als CSV, mit der Commit-Referenz, wo es sie gibt. Legen Sie das dort ab, wo Ihre übrigen Release-Nachweise liegen.
• Die dauerhafte Historie ist Git. Commits, Pull Requests, Merges und Tags sind der Nachweis, den Prüfer tatsächlich akzeptieren, und alles nach der Umstellung landet dort ohnehin.
• Für die Prüfkontinuität behalten Sie den Export und die Commit-Links. Ein datiertes Archiv und ein nachvollziehbarer Branch schlagen Screenshots aus einem abgeschalteten System.

Wie geht man mit der Branch-Strategie um?

Ändern Sie eines nach dem anderen. Zuerst das Werkzeug, später der Prozess.

Behalten Sie Ihr bestehendes Branch-Modell mindestens für die ersten beiden Releases, auch wenn Sie vereinfachen wollen. Langlebige Umgebungs-Branches funktionieren weiter, Promotion-Branches werden eins zu eins durch Pull Requests ersetzt, und wenn Sie Richtung Trunk-based wollen, machen Sie daraus ein eigenes Vorhaben nach der Umstellung. Der Punkt, auf den es während des Parallelbetriebs ankommt, ist die Kollision von Automatisierung: Schalten Sie geplante Jobs und automatische Merges des alten Werkzeugs ab, bevor die neue Pipeline auf dieselben Branches schreibt.

Wie vermeidet man Ausfall und Code-Freeze?

• Frieren Sie die Pipeline-Konfiguration ein, nicht die Arbeit. Während des Parallelbetriebs ändert niemand Stufen, Freigaben oder Branch-Regeln, in keinem der beiden Werkzeuge.
• Legen Sie die Umstellung an den Anfang eines Sprints, nie ans Ende und nie in ein Release-Wochenende.
• Schreiben Sie die Rückfallebene auf, bevor Sie sie brauchen. Ein Satz: Scheitert die Produktionsfreigabe auf der neuen Pipeline, läuft die nächste über das alte Werkzeug, und beide bleiben ein Release länger verbunden.
• Halten Sie beide Werkzeuge nur wenige Releases verbunden. Zwei Systeme, die dauerhaft auf dieselben Branches schreiben, sind kein Sicherheitsnetz, sondern ein Merge-Konflikt mit Terminplan.

Die Dauer bestimmen die Release-Zyklen, nicht die Einrichtung. Orgs und Repositories zu verbinden ist eine Aufgabe für denselben Tag, und zum Serpent-Onboarding gehört eine kostenlose Praxissitzung für das ganze Team, sodass die Pipeline-Zuordnung mit Ihnen gemacht und nicht als Aufgabe übergeben wird. Weitere Salesforce-DevOps-Leitfäden.

FAQ

Brauchen wir für den Wechsel einen Code-Freeze?

Nein. Das bestehende Werkzeug bleibt bis zum Umstellungsrelease installiert und maßgeblich, die Entwicklung läuft also durchgehend weiter.

Können wir Repository und Branch-Namen behalten?

Ja. Das Repository bleibt unberührt, und dieselbe Branch-Benennung lässt die Historie über den Wechsel hinweg durchlaufen.

Was passiert mit unseren User Stories beim Deinstallieren des Packages?

Sie gehen mit, deshalb exportieren Sie sie vorher als CSV. Commits, Pull Requests und Tags in Git bleiben, und das ist der dauerhafte Prüfpfad.

Wie lange dauert die gesamte Migration?

Denken Sie in Release-Zyklen: ein Schattenzyklus, ein Parallelzyklus, ein Umstellungszyklus. Für eine normale Org-zu-Org-Pipeline sind das Wochen, größtenteils Wartezeit auf Ihre eigenen Releases.

Lässt sich eine Package- oder ISV-Pipeline genauso umziehen?

Ja, mit einem zusätzlichen Zyklus. Paketversionen, Ancestry und Subscriber-Tracking brauchen ihr eigenes Schattenrelease, bevor Sie der Umstellung trauen.