Comments
3 comments
-
Official commentGreat advice from emmar00, the only thing I'd add is that Flyway Desktop has a dedicated tab for this scenario called ‘Update development’ so you can avoid needing to retarget databases.
-
I've done something like this with SQL Server.
1. Change your development database link to point to prod
2. Save any updated objects into your schema model
3. Change your development database back to dev
4. Use the Update development pane to push the changes from your schema model into the dev database
Assuming test/uat also need to be updated, I would recommend generating the migration script and using that to deploy to test/uat, then doing a skipExecutingMigrations move for prod.
-
Thank you both!
Add comment
Please sign in to leave a comment.
We are implementing Flyway into an existing environment, in which we have dev/test/uat and prod DBs. Over time, there has been some drift which occurred and we have changes in production which are not in our dev environment. Most of the documentation I've seen, as expected, is in regard to deploying changes from dev downstream to test, uat and prod. Is it possible within Flyway to propagate changes in prod down to our dev environment, without performing a full refresh and overwriting work of our developers? We are using Flyway Desktop (with Flyway Enterprise license).