Content-omgevingen gebruiken om staging en productie te scheiden

Je hebt een nieuw verplicht veld toegevoegd aan een contenttype in productie en drie minuten later mislukte je Next.js-build omdat bestaande entries dat veld niet hadden ingevuld. Contentomgevingen voorkomen precies dit. Ze werken als Git-branches voor je CMS — je kunt vertakken vanuit productie, schemawijzigingen doorvoeren, testen met echte content, en pas samenvoegen als alles werkt.

Wat contentomgevingen je opleveren

Elke ContentGrid-omgeving is een volledige kopie van je schema. Entries zijn standaard scoped aan een omgeving, zodat wijzigingen in staging nooit de productiecontent beïnvloeden. Je kunt:

• Velden toevoegen aan of verwijderen uit contenttypes zonder productie aan te raken.
• Migratiescripts testen op een echte schemakopie voordat je ze op productiedata uitvoert.
• Editors nieuwe contentstructuren laten previewen voordat de feature live gaat.
• Terugdraaien door de omgeving simpelweg te verwijderen als er iets misgaat.

Een stagingomgeving aanmaken

Ga in het ContentGrid-dashboard naar Instellingen → Omgevingen en klik op Nieuwe omgeving. Kies Klonen van productie om het huidige schema te kopiëren. Noem de omgeving staging. ContentGrid geeft je voor elke omgeving een apart API-endpoint — sla dit endpoint op in je omgevingsvariabelen als CONTENTGRID_ENV_STAGING.

Stel voor Vercel-deployments het staging API-endpoint in de preview-omgevingsvariabelen in. Vercel preview-deployments gebruiken dan automatisch de staging CMS-omgeving. Je productie-deployment gebruikt het productie-endpoint. Dit betekent dat elke pull request-preview automatisch naar stagingcontent wijst.

Omgevingen koppelen aan je deploy-pipeline

Stel drie omgevingen in die aansluiten op een standaard workflow:

• productie — live site, gebruikt door je hoofd-Vercel-deployment.
• staging — spiegelt het productieschema, gebruikt door Vercel preview-deployments.
• development — gebruikt door lokale ontwikkeling, kan vrijelijk worden gereset.

Sla elk endpoint op in een aparte omgevingsvariabele en schakel ertussen via NODE_ENV of een aangepaste CMS_ENV-variabele. De ContentGrid SDK-initialisatie neemt het endpoint als parameter, zodat overschakelen één regel configuratie is.

Schemawijzigingen samenvoegen naar productie

Wanneer je schemawijziging is getest en de content klaar is, gebruik je de ContentGrid CLI om de diff toe te passen:

• Voer contentgrid env diff staging production uit om precies te zien wat er gaat veranderen.
• Bekijk de diff — let vooral op verwijderde velden, want die zijn destructief.
• Voer contentgrid env promote staging production uit om schemawijzigingen toe te passen.
• Migreer content-entries die de nieuwe velden nodig hebben voordat je nieuwe front-endcode wordt gedeployed.

Omgevingen kosten niets extra op ContentGrid — je kunt er zoveel aanmaken als je workflow vereist. De meeste teams landen op twee of drie. De belangrijkste discipline is dat je nooit schemawijzigingen rechtstreeks in productie doorvoert. Vertakken eerst, testen, dan promoten.