Schemamigrations uitvoeren met de ContentGrid CLI

Je hebt vorige week een contenttype rechtstreeks in het ContentGrid-dashboard aangepast en nu hebben staging en productie verschillende schema's. Niemand weet meer precies wat er is veranderd. Schemamigrations als code lossen dit op: elke wijziging is een bestand in je repository, wordt in volgorde uitgevoerd, en geeft hetzelfde resultaat in elke omgeving.

Migratiebestanden opzetten

Maak een migrations/-map aan in je projectroot. Elke migratie is een JavaScript- of TypeScript-bestand met een tijdstempelprefix en een beschrijvende naam:

• 20250519_001_auteur-veld-toevoegen.ts
• 20250519_002_excerpt-hernoemen-naar-samenvatting.ts
• 20250519_003_gepubliceerd-op-index-toevoegen.ts

Elk bestand exporteert een up()-functie die de wijziging toepast en een optionele down()-functie die deze terugdraait. De ContentGrid SDK biedt methoden voor elke schemabewerking: createField, deleteField, renameField, changeFieldType en createContentType.

Een migratie schrijven

Een typisch migratiebestand ziet er qua structuur als volgt uit:

• Importeer de ContentGrid Management-client.
• Exporteer een asynchrone up()-functie.
• Roep binnen up() SDK-methoden aan om velden toe te voegen, te hernoemen of te verwijderen.
• Exporteer een asynchrone down()-functie die de wijziging terugdraait.

Voor een veldhernoem roept up() aan: client.renameField({ contentType: 'post', from: 'excerpt', to: 'samenvatting' }). De down()-functie roept dezelfde methode aan met from en to omgewisseld. Houd migrations klein en gericht op één wijziging per keer.

Migrations uitvoeren

De ContentGrid CLI houdt bij welke migrations zijn uitgevoerd via een migratielogboek in je ContentGrid-space. Voer migrations uit met:

• contentgrid migrate up --env development — voer openstaande migrations uit op development.
• contentgrid migrate up --env staging — voer uit op staging na testen.
• contentgrid migrate up --env production — voer uit op productie tijdens je deploy.
• contentgrid migrate down --env development — draai de laatste migratie terug tijdens ontwikkeling.

Voeg de productiemigratieopdracht toe aan je CI/CD-pipeline, en voer deze uit na de build maar vóór de nieuwe front-endcode wordt gedeployed. Dit garandeert dat het schema klaar is voordat code die ervan afhankelijk is live gaat.

Destructieve migrations afhandelen

Veldverwijderingen en typewijzigingen zijn destructief — ze kunnen data vernietigen. Volg dit patroon voor elke destructieve wijziging:

• Voeg eerst het nieuwe veld toe en deploy de front-endcode die het gebruikt.
• Schrijf een datamigratieScript om waarden van het oude veld naar het nieuwe veld te kopiëren voor alle bestaande entries.
• Voer de datamigratie uit en controleer of de waarden correct zijn.
• Verwijder het oude veld in een aparte migratie nadat de front-end er niet meer naar verwijst.

Dit expand-and-contract-patroon betekent dat de schemawijziging en de codewijziging nooit uit sync zijn. Het vereist twee deploys in plaats van één, maar het elimineert dataverlies en downtime.