Migration-scripting is quite tricky to do; it would be great if, when I wanted to make API changes, I could make them manually on a fork of the primary environment, in correpondence with code changes, and then once the code-changes are proven to work I could capture the environment changes as a script that I could re-run…
This feature would be huge for us (or a “promote structure only” option).
It’s also confusing to me that this isn’t more frequently requested, as the workflow for making non-trivial updates to “live” sites is really pretty broken without it. Hand-coding migrations is a solution to the “staging and then promoting updates without losing live content history” problem, but it really undermines some of the core appeal of the product (i.e. rapid development of content models etc.).
@lunelson if you discover or develop a solution for this we would be really keen to discuss, or contribute to creating something.
Thanks @rob yeah I might come back around to this. It seems to me that for the use-case of API-naming and structural changes, without content changes, one could probably write a script to compare all models from two different environments, and format the results as some kind of list, that a second script could then interpret as instructions, to reproduce those changes. Would have to do some hacking around on this
Hello @rob, can you please expand on why do you think that hand-coding migrations is not good enough for live sites?