Appwrite Environments (Development, Staging, Production)

I've seen some posts about this already but I'm not satisfied with the answers as they basically say "not possible".

It's absolutely crucial to be able to manage your database structures without losing data. This should preferably be done without user involvement, during a CI operation.

This is the flow I would expect to be able to run:

• Update my Staging server's buckets, teams, collections
• Develop my features locally, using the Staging server for development data
• Push my feature in a Pull Request, test it in a staging production environment, run e2e tests, etc
• Merge my changes to main, CI runs, updates the production Appwrite databases, buckets, etc, using the appwrite.json
• Frontend is deployed to production, everything works in harmony 🌟

From what I can tell, the documentation says that this should work https://appwrite.io/docs/command-line-deployment#deployCollections, however official word from people here is that this command is not usable on production, as it wipes all data?

Do we need to write custom migration scripts using the API's whenever our Appwrite structure changes?

I know your pain bruh 😅

if you need to make changes over time, I suggest creating custom migration scripts or a whole migration system.

To be fair, there's no good way of doing this with Firebase either... at least that's a collection storage, so migrations might not even be relevant, fields and sub-documents can be added or deprecated on the fly.

Since Appwrite is using a "fake" document storage, but still uses a column-like document structure, attribute syncing without data loss is crucial.

Would this be mitigated by the upcoming mongodb database? Or will it still require strict attributes?

I really want to love Appwrite, but I keep running into walls wherever I turn!

So many great features, self-hosted and for free, it's incredible. I really can't complain. Just gotta find workarounds for some of the basics.

updating schemas is a pretty complex/complicated topic (especially when trying to do it at scale in production).

Yeah you're right of course, not calling the operation basic. Just that it's one of the things that every serious project will need.

And having to make proprietary scripts with proprietary API's can be a bottleneck.

Am afraid to go live with my website as once the database is gets filled in making changes to the database structure would be slow and difficult

So planning ahead for what I'm doing and for what I'm planning in the future 😅

I've worked with CMSaaS, like Storyblok where it's not really a thing to use multiple environments for the data structure.
When working with that, we made backwards compatible changes directly on the production structure in their dashboard. Works fine for content, but I don't think it's suitable for app-data.

we made backwards compatible changes
I think this should definitely be the approach for an app in production, especially for mobile apps where people can be on different versiosn

Yeah in that scenario, we simply just had one source of truth which was production. It could be one way of doing it.

True, upgrading mobile apps is a mess 😅

I even needed adding a message that is shown to make people go and upgrade the app 😬