Whenever you pull down changes to your database schema from Version Control, made by other team members, you will need to make sure that your development environment is up to date, before making your own changes to it.

If a team member has been changing the same objects as you are, you may get a merge conflict which needs resolving.

Update process with a dedicated development database

1. When you have a dedicated development database and are using a schema model, it is very important to make sure that any changes you have in flight against your development database are saved to your schema model before pulling. If you don't do this, you will have a mixture of changes in you development database which need making to your schema model, and changes made by other people in your schema model which need applying to your database. This situation is liable to be confusing and is inadvisable.
2. Pull the changes from Version Control. See this tutorial for how to do this in Flyway Desktop.
3. Address merge conflicts, if any. See this tutorial for how to do this in Flyway Desktop.
4. Apply the changes to your development database. If you are using a schema model, it is recommended to apply using the schema model. See below for elaboration.

Apply workflow considerations

When updating your development environment following a pull, you have the following options:

1. Update using the schema model. This will straightforwardly handle any scenario where there are changes in the schema model which have not yet been captured in a migration script. The one downside of this approach is that any data motion handled by your migration scripts will not be applied to your development database, although this often doesn't matter with development environments,
2. Apply any pulled migrations to your development database using migrate, and then apply the schema model updates after if needed. Note that this migrate operation will only work if you cherry pick the migrations to deploy, or if you have made sure to mark any migrations generated locally whose effects already exist in the development database as already applied with a dedicated migrate action using the skipExecutingMigrations flag.
3. Reprovision your development database to match the state of Version Control, and then apply any in flight changes. This is likely the most effective approach if it is available, but requires the relevant infrastructure to be put in place.

Update process with a shared development database

1. Pull the changes from Version Control. See this tutorial for how to do this in Flyway Desktop.
2. Address merge conflicts, if any. See this tutorial for how to do this in Flyway Desktop.

In the shared scenario your team mates will be making their changes in the same development database as you, so any changes you pull down from Version Control will already exist in the database.

Relevant tutorials

• Tutorial - Apply database changes from the schema model to your database
• Tutorial - Pull changes from Version Control
• Tutorial - Resolve merge conflicts