Migreren van Gearset naar Serpent zonder downtime

Kort gezegd: een release freeze is niet nodig. Je Git-repository is het draagbare bezit, dus beide tools kunnen er tegelijk aan hangen terwijl je pipeline voor pipeline overstapt, laagste omgeving eerst en productie als laatste. Wat meegaat is de repo, de branches en de historie. Wat je opnieuw bouwt is alles wat binnen de leverancier leefde: CI- en monitoringjobs, org-verbindingen, goedkeuringspoorten, backupschema's en deployment-historie.

Wat gaat er echt mee bij een overstap?

Het model dat dit makkelijk maakt: metadata woont in Git, orkestratie woont bij de leverancier. De documentatie van Gearset zelf beschrijft jouw repository als de plek waar de metadata staat, waarbij de tool die tussen orgs en die repo verplaatst. Het bezit dat je jarenlang hebt opgebouwd, de commit-historie, het branchmodel en de mappenstructuur, is dus van jou en blijft precies waar het staat.

Gaat ongewijzigd mee:

• De Git-repository, met elke branch, tag en commit.
• Je mappenstructuur en metadataformaat, zolang de nieuwe tool het leest.
• Branch protection-regels en reviewerlijsten, want die staan in GitHub, GitLab of Bitbucket.
• Alles wat al code is: scripts, Apex-tests, configuratie voor statische analyse.

Moet opnieuw worden gebouwd:

• CI/CD-jobdefinities en hun schema's.
• Change monitoring-jobs en hun notificatieregels.
• Org-verbindingen en geauthenticeerde gebruikers, per omgeving.
• Goedkeuringspoorten en de regels voor wie naar productie mag promoveren.
• Backupschema's en bewaarde backupdata, die niet overdraagbaar is tussen leveranciers.
• Deployment-historie en auditrecords die in de oude tool zitten.

Wat controleer je voordat je iets aansluit?

Bevestig eerst je metadataformaat. Gearset commit in SFDX source-formaat wanneer het een lege repository initialiseert en ondersteunt daarnaast het metadata API-formaat, dus een geerfde repo kan legitiem in beide staan. Een formaatmismatch is precies het ding dat een rustige parallelle run verandert in een muur van valse diffs.

Staat de repo in metadata API-formaat en wil je converteren, doe dat dan als losse wijziging: converteren, reviewen, mergen, en een deployment eruit verifieren. Converteer nooit het formaat en wissel van tooling in dezelfde week. Je kunt dan niet zien welke wijziging welke verrassing veroorzaakte.

Hoe blijf je releasen terwijl beide tools aangesloten zijn?

1. Inventariseer wat de oude tool voor je doet. Deployments, CI-jobs, change monitoring, backup, code review, sandbox seeding. Die lijst is je migratiebacklog en is meestal langer dan iemand zich herinnert.
2. Sluit de nieuwe tool read-only aan. Richt hem op dezelfde repository en dezelfde orgs en draai vergelijkingen zonder te deployen. Op dag een verandert er niets voor het team.
3. Bouw de laagste omgeving eerst opnieuw. Dev of integratie. Laat een squad een sprint lang via de nieuwe pipeline leveren terwijl de rest op het oude pad blijft.
4. Draai beide een volledige releasecyclus. De nieuwe pipeline valideert elke wijziging, de oude deployt nog. Elk verschil tussen de twee uitkomsten is een configuratiegat dat je gratis vindt.
5. Verplaats UAT en staging. Op dit punt is de pipelinevorm bewezen, het goedkeuringsmodel afgesproken en ziet de auditoutput eruit zoals je reviewers verwachten.
6. Verplaats productie als laatste, binnen een normaal changevenster. Er is geen cutover-moment, alleen de laatste omgeving die verhuist.
7. Ontmantel met vertraging. Houd het oude abonnement minstens een backup-bewaartermijn aan, trek daarna org-verbindingen in en verwijder deploy keys en webhooks.

Wat zijn de valkuilen van parallel draaien?

• Twee schrijvers, een branch. Spreek af dat er per moment maar een tool naar een branch commit. Racende commits zijn de meest zelf toegebrachte wond in een migratie.
• Dubbele status checks. Beide tools willen rapporteren op pull requests. Maak er maar een verplicht, anders blijven merges wachten op een pipeline die je aan het uitfaseren bent.
• Dubbele deployment. Als beide tools een geplande job op dezelfde doel-org hebben, deploy je twee keer. Zet het oude schema uit op het moment dat het nieuwe live gaat, niet de week erna.
• Backups. Backupdata is doorgaans niet in herstelbare vorm te exporteren naar een andere leverancier. Bepaal je bewaarpositie voordat je iets opzegt.
• Auditgaten. In een gereguleerde omgeving exporteer je de deployment-historie die je moet bewaren zolang het oude contract nog loopt.

Hoe lang duurt het geheel?

De beperking is je releasecadans, niet de tooling. Een team met een tweewekelijkse cyclus is meestal in twee cycli klaar: een parallelle cyclus en een productiecyclus. Serpent is per workspace in minder dan 15 minuten opgezet en onboardingsessies met ons team zijn gratis, dus de meeste tijd gaat zitten in wachten op je eigen changevensters.

Waarom stappen teams eigenlijk over?

Drie redenen keren steeds terug. Prijzen die meebewegen met gebruikers en met het aantal CI/CD-orgs. Een workflow die Git-vaardigheid veronderstelt die de admin-helft van het team niet heeft. En packagelevering die een aparte aankoop is. Serpent rekent vast per bedrijf, werkt ticketgestuurd met Git op de achtergrond, installeert niets in je org en bevat 1GP-, 2GP- en AppExchange-releaseworkflows op elk plan, inclusief het gratis Essentials. Meer migratieplaybooks staan in onze SF Guides-bibliotheek.

FAQ

Hebben we een release freeze nodig om over te stappen?

Nee. Bouw omgevingen een voor een opnieuw en laat de oude pipeline deployen tot de nieuwe een volledige releasecyclus heeft gevalideerd.

Kunnen twee DevOps-tools tegelijk aan dezelfde repository hangen?

Ja, en dat maakt een overstap zonder downtime mogelijk. De regel die het veilig houdt is een schrijver per branch per moment.

Gaan onze bestaande backups mee?

Nee. Backupdata is niet in herstelbare vorm overdraagbaar tussen leveranciers, dus plan een overlap die je bewaartermijn dekt.

Wat gebeurt er met onze deployment-historie?

Die blijft bij de oude tool. Exporteer wat je auditors nodig hebben zolang het contract nog loopt.

Installeert Serpent iets in onze Salesforce-orgs?

Nee. Het verbindt alleen via standaard-API's, dus er is geen package om goed te keuren en later niets te de-installeren.