Migreren van Copado naar Serpent: een stappenplan

Kort antwoord: je hebt geen code freeze nodig, en je migreert geen data. Je metadata staat al in Git, dus overstappen van Copado naar Serpent is een wissel van het besturingsvlak: je bouwt de pipelinedefinitie opnieuw, laat beide tools een volledige releasecyclus naast elkaar draaien, en laat daarna de nieuwe pipeline de productiepromotie doen terwijl de oude blijft staan als je terugvaloptie. Plan op releasecycli, niet op kalenderdagen.

Wat verhuist er echt, en wat niet?

Hier precies in zijn haalt de meeste spanning uit de kamer:

• Er hoeft niets gemigreerd te worden. Je bron van waarheid is je Git-repository, en die blijft exact waar hij staat, met historie intact.
• Wat achterblijft zijn de records die alleen in een managed package bestaan: user stories, promoties, deploymentrecords en alle automatisering daarop gebouwd. Copado is in je org geinstalleerd, dus die objecten vertrekken met het package.
• Wat je opnieuw opbouwt is de pipelinedefinitie: omgevingen en hun credentials, volgorde van de stages, goedkeuringsregels, kwaliteitspoorten, geplande jobs en de ticketkoppeling.

Die laatste lijst is het hele project. Het is configuratiewerk, en daarom leest dit als een mappingoefening in plaats van een migratie.

Hoe vertalen Copado-begrippen naar een Git-native pipeline?

Copado modelleert de release in Salesforce-records. Een Git-native pipeline modelleert hem in de repository. De vertaling is bijna een op een:

• User Story wordt een work item gekoppeld aan een branch.
• De feature branch per user story blijft een feature branch. Je kunt de naamgeving behouden zodat de historie doorloopt.
• Promotie en de bijbehorende promotion branch worden een pull request naar de volgende omgevingsbranch.
• Deploymentrecord wordt een pipeline-run, met eigen log, resultaat en terugvalpunt.
• Omgeving of stage wordt een omgeving gekoppeld aan een branch.
• Back-promotion wordt een merge terug omlaag vanuit de hogere branch.
• Compliance- en kwaliteitspoorten worden pull request checks: tests, statische analyse, AI-codereview.

Wat is het stappenplan?

1. Inventarisatie, een tot twee dagen. Noteer elke omgeving, branch, stage, goedkeurder, geplande job, kwaliteitspoort en integratie, met een eigenaar erbij. Heeft een stage geen eigenaar, dan is dat je eerste bevinding.
2. Spiegel de pipeline, alleen lezen. Koppel dezelfde orgs en dezelfde repository aan Serpent zonder iets te deployen. Koppelen kost minuten. Vergelijk daarna: zijn beide tools het eens over wat er nu in elke omgeving zit? Elk verschil is drift die je al had.
3. Schaduw een release. Elke wijziging gaat zoals gewoonlijk door Copado, en daarnaast door de nieuwe pipeline naar een reserve-sandbox. Vergelijk de deployplannen. De verschillen worden je bevindingenlijst, en gaan meestal over profiles, permission sets en flows.
4. Draai een echte release parallel. De nieuwe pipeline promoveert naar UAT, de bestaande doet nog productie. Dit is het gecontroleerde middelpunt, en hier worden goedkeurders rustig.
5. Zet om. De nieuwe pipeline doet de productiepromotie. Laat Copado geinstalleerd en ongemoeid, want dat is je terugval: mislukt de promotie, dan gaat de volgende release er weer doorheen.
6. Ontmantel na twee schone releases. Exporteer de historie, zet eerst de oude geplande jobs uit, en verwijder het managed package eerst in een sandbox voordat je productie aanraakt.

Wat doe je met de user story-historie?

Dit is de vraag waar migraties op stranden, en het eerlijke antwoord is: probeer hem niet te importeren.

• Historische records betekenen alleen iets in de tool die ze maakte. Geimporteerde user stories zonder levende pipeline erachter zijn decoratie, en misleiden over een jaar iemand.
• Exporteer in plaats daarvan. User stories, promoties en deployments naar CSV, met de commitreferentie waar die bestaat. Bewaar het waar je overige releasebewijs staat.
• De duurzame historie is Git. Commits, pull requests, merges en tags zijn wat auditors daadwerkelijk accepteren, en alles na de omzetting komt daar vanzelf terecht.
• Voor auditcontinuiteit bewaar je de export plus de commitlinks. Een gedateerd archief en een traceerbare branch verslaan screenshots uit een uitgezet systeem.

Hoe pak je de branchstrategie aan?

Verander een ding tegelijk. Eerst de tool, later het proces.

Houd je bestaande branchmodel minstens de eerste twee releases aan, ook als je van plan bent te vereenvoudigen. Langlevende omgevingsbranches blijven werken, promotion branches worden een op een vervangen door pull requests, en wil je richting trunk-based ontwikkeling, doe dat als aparte oefening na de omzetting. Let tijdens de parallelle periode vooral op botsende automatisering: zet de geplande jobs en automatische merges van de oude tool uit voordat de nieuwe pipeline naar dezelfde branches gaat schrijven.

Hoe voorkom je downtime en een code freeze?

• Bevries de pipelineconfiguratie, niet het werk. Tijdens de parallelle periode wijzigt niemand stages, goedkeuringen of branchregels in een van beide tools.
• Plan de omzetting aan het begin van een sprint, nooit aan het eind, en nooit in een releaseweekend.
• Schrijf de terugval op voordat je hem nodig hebt. Een zin: mislukt de productiepromotie op de nieuwe pipeline, dan gaat de volgende via de oude tool en blijven beide nog een release gekoppeld.
• Houd beide tools maar een paar releases gekoppeld. Twee systemen die eindeloos naar dezelfde branches schrijven zijn geen vangnet, maar een mergeconflict met een agenda.

De doorlooptijd wordt bepaald door releasecycli, niet door installatie. Orgs en repositories koppelen is een klus van een dag, en bij Serpent hoort een kosteloze hands-on sessie voor het hele team, dus de pipelinemapping doen we met je in plaats van hem als taak af te geven. Meer Salesforce DevOps-gidsen.

FAQ

Is een code freeze nodig om over te stappen?

Nee. De bestaande tool blijft geinstalleerd en leidend tot de omzettingsrelease, dus ontwikkeling loopt gewoon door.

Kunnen we onze Git-repository en branchnamen houden?

Ja. De repository blijft ongemoeid, en dezelfde branchnaamgeving aanhouden laat de historie doorlopen over de overstap heen.

Wat gebeurt er met onze user stories als we het package verwijderen?

Die gaan mee, en daarom exporteer je ze eerst naar CSV. De commits, pull requests en tags in Git blijven, en dat is het duurzame audittrail.

Hoe lang duurt de hele migratie?

Denk in releasecycli: een schaduwcyclus, een parallelle cyclus, een omzettingscyclus. Voor een gewone org-naar-org pipeline is dat een kwestie van weken, waarvan het meeste wachten op je eigen releases.

Kan een package- of ISV-pipeline op dezelfde manier over?

Ja, met een extra cyclus. Packageversies, ancestry en subscribertracking hebben hun eigen schaduwrelease nodig voordat je de omzetting vertrouwt.