Von Copado zu Serpent migrieren: ein Schritt-fuer-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 vollstaendigen Release-Zyklus nebeneinander laufen und uebergeben dann die Produktionsfreigabe an die neue Pipeline, waehrend die alte als Rueckfallebene installiert bleibt. Planen Sie in Release-Zyklen, nicht in Kalendertagen.

Was bewegt sich wirklich, und was nicht?

Hier praezise 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.
• Zurueck bleiben die Datensaetze, die nur in einem Managed Package existieren: User Stories, Promotions, Deployment-Datensaetze 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, Qualitaetstore, geplante Jobs und die Ticketing-Anbindung.

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

Wie uebersetzen sich Copado-Begriffe in eine Git-native Pipeline?

Copado modelliert das Release in Salesforce-Datensaetzen. Eine Git-native Pipeline modelliert es im Repository. Die Uebersetzung 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 koennen Sie behalten, dann liest sich die Historie durchgehend.
• Promotion und der Promotion-Branch werden zu einem Pull Request in den naechsten Umgebungs-Branch.
• Der Deployment-Datensatz wird zu einem Pipelinelauf mit eigenem Log, Ergebnis und Rueckfallpunkt.
• Umgebung oder Stufe wird zu einer Umgebung, die auf einen Branch zeigt.
• Back-Promotion wird zu einem Merge zurueck nach unten aus dem hoeheren Branch.
• Compliance- und Qualitaetstore werden zu Pull-Request-Pruefungen: Tests, statische Analyse, KI-Code-Review.

Wie lautet das Schritt-fuer-Schritt-Runbook?

1. Inventur, ein bis zwei Tage. Listen Sie jede Umgebung, jeden Branch, jede Stufe, jeden Freigebenden, jeden geplanten Job, jedes Qualitaetstor 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 Aenderung laeuft wie gewohnt durch Copado und zusaetzlich durch die neue Pipeline in eine freie Sandbox. Vergleichen Sie die Deploy-Plaene. Die Unterschiede werden Ihre Befundliste und betreffen meist Profiles, Permission Sets und Flows.
4. Fahren Sie ein echtes Release parallel. Die neue Pipeline befoerdert nach UAT, die bestehende uebernimmt noch die Produktion. Das ist der risikokontrollierte Mittelpunkt, und hier gewinnen die Freigebenden Vertrauen.
5. Schalten Sie um. Die neue Pipeline fuehrt die Produktionsfreigabe aus. Lassen Sie Copado installiert und unberuehrt, denn das ist Ihre Rueckfallebene: Scheitert die Freigabe, laeuft das naechste Release wieder darueber.
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 haengen, und die ehrliche Antwort lautet: Versuchen Sie nicht, sie zu importieren.

• Historische Datensaetze sind nur in dem Werkzeug sinnvoll, das sie erzeugt hat. Importierte User Stories ohne lebende Pipeline dahinter sind Dekoration und fuehren 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 uebrigen Release-Nachweise liegen.
• Die dauerhafte Historie ist Git. Commits, Pull Requests, Merges und Tags sind der Nachweis, den Pruefer tatsaechlich akzeptieren, und alles nach der Umstellung landet dort ohnehin.
• Fuer die Pruefkontinuitaet 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?

Aendern Sie eines nach dem anderen. Zuerst das Werkzeug, spaeter der Prozess.

Behalten Sie Ihr bestehendes Branch-Modell mindestens fuer 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 waehrend 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. Waehrend des Parallelbetriebs aendert 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 Rueckfallebene auf, bevor Sie sie brauchen. Ein Satz: Scheitert die Produktionsfreigabe auf der neuen Pipeline, laeuft die naechste ueber das alte Werkzeug, und beide bleiben ein Release laenger 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 fuer denselben Tag, und zum Serpent-Onboarding gehoert eine kostenlose Praxissitzung fuer das ganze Team, sodass die Pipeline-Zuordnung mit Ihnen gemacht und nicht als Aufgabe uebergeben wird. Weitere Salesforce-DevOps-Leitfaeden.

FAQ

Brauchen wir fuer den Wechsel einen Code-Freeze?

Nein. Das bestehende Werkzeug bleibt bis zum Umstellungsrelease installiert und massgeblich, die Entwicklung laeuft also durchgehend weiter.

Koennen wir Repository und Branch-Namen behalten?

Ja. Das Repository bleibt unberuehrt, und dieselbe Branch-Benennung laesst die Historie ueber 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 Pruefpfad.

Wie lange dauert die gesamte Migration?

Denken Sie in Release-Zyklen: ein Schattenzyklus, ein Parallelzyklus, ein Umstellungszyklus. Fuer eine normale Org-zu-Org-Pipeline sind das Wochen, groesstenteils Wartezeit auf Ihre eigenen Releases.

Laesst sich eine Package- oder ISV-Pipeline genauso umziehen?

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