I’m new to migrations. I’m playing with some test files and OttoDeploy. Very cool, so far! I like that I can develop new stuff and deploy it to production without having to worry about moving things manually and syncing data!
However, it looks like there’s no way to do a local data refresh (pull from prod) without overwriting the local schema? I found this post that says you can first copy local to prod, then back down to local… that would get you the data from prod, but also wipe out the schema still being developed. And what if I’m not ready to apply the new schema stuff I’m still working on to prod?
I think this would be a handy feature! If I’ve missed something (quite possible!) please let me know!
Thanks, and keep up the great work on this awesome tool!
That is correct; this method does wipe out your local schema. This is a limitation of the data migration tool that Claris provides and not really something that we can correct with OttoFMS. Practically, there are a few ways to get around this limitation, and you probably need a mixture of them depending on how you want to work.
One option is to use a “staging” environment. This is meant to be a place for you to test your most recent changes to the code/schema with a more recent version of the data (production), but still in a safe sandbox that doesn’t impact your production users. There’s also more details about this pattern at this page of the docs.
But this still would cause the problem of it making whatever schema changes you have “live” in that staging environment. To get around this, what you really need to always keep your dev code “deployable” using feature flags. I did a session about this at last year’s Engage that goes into a bit more detail, but essentially you should develop in such a way that new features/changes can be hidden to end-users, and a deployment of your not-ready code wouldn’t actually break anything in production.
You do have to change your mindset a bit to develop this way and take full advantage of all of Otto’s features, but over time you’ll really appreciate the idea that you can deploy to production at any time quickly and easily!
It looks like the resulting file won’t include the latest record, if there’s a user connected to the source file when the deployment is run. I tried toggling on the “Close file…” option, but maybe that doesn’t commit open records when it boots users to close the file?
What happens behind the scenes in the first step of that workflow is that the databases to be copied are paused, then an instant backup is made and OttoFMS sends that backup to the dev server, but it wouldn’t include any uncommitted changes.
To my knowledge, there isn’t a way from the server side to force a user to commit their changes.
