How people solve syncing 🔃 from 'dev' to 'live'?

[itspers]

Lets say we use it as simple CMS with some Pages collection, which has some blocks and some consumer Next.JS website. And both of them installed on two servers - dev and live.
And most likely workflow for content-managers will be to create tone of content on dev and then say 'ok we are done, please update live'

Strapi has plugins which allows to export-import data as json. Here we have mongodb, which theoretically even better - can export whole collection and it should work (except some relations like Media)... But why there is nothing like this in docs and dicussions? Maybe it should be done totally different?

[bencun]

Why not rely on the drafts and versioning on prod environment to manage the release of the content? No DB imports/exports to run + no file upload management shenanigans if you're not using a cloud provider for that.

[itspers]

Mostly because code shape would be different - prod payload installation will not have 20 new fields from latest client change request. This should be first deployed on dev CMS, tested along connected consumer dev app. And then when all that settled - dev merged to 'live' branch of app, which updates both live site and cms. Everything fine - except fields will be empty. So i was even thinking about making some 'seed' function, which will run on cms init...

[DanRibbens]

We have some scripts that use mongo commands that were written for enterprise clients. We can share a generic version if it helps.

All we do is add a script to the package.json for managing DB dump and import. It takes a source and a destination to move data between different databases for prod to staging/dev environments.

Import and export is a heavy handed approach and we will have a solution for migrations in the future.

[itspers]

I thought about just exporting-importing collections in mongo, but yeah - it should be heavy handed from beginning. Plus i already use one CMS (thanks for grouping functionality) for two websites.

My idea was next:
On particular collection i make some button "get dump of this Page", which will get collection item with all nested blocks etc, then for each relation field (media or some other page mentioned in some richEditor) get document too and so on, reclusively.
And then i have giant json file, which i put into some 'migrations' folder and it runs on payload init function inserting/updating data.
Then I merge 'dev' branch into 'live', github action build&updates live - and CMS already starts with data, consumer website happy, managers happy.

Complex, but doable while you know your data. If your scripts has some similar custom logic - please share some generic example 🙏

[DanRibbens]

No, our script is much more naive than your approach. I think your way is going to prove much more capable. Let us know if you get stuck I'm interested in the work you're doing here.

[MentalGear]

Also very interested in the best approach for data migration here. Would you mind sharing your XP and maybe scripts so far?

[DanRibbens]

I made a sample repo that has migrations inside a Payload project using migrate-mongo and it worked pretty well in my testing, see https://github.com/payloadcms/migrate-mongo-example.

I'll write a blog post on and depending on reception, it could be added to the Payload docs.