In order to capture changes to your database in your version control system, you need to configure a development environment, save changes you make to that environment to your schema model on disk, and then commit and push those changes to share them with your team.

Configuring a development environment

Before beginning to capture information in your schema model, you will need to configure the development environment you will use for making your database schema changes.

If you already have a development environment, follow this tutorial to configure the connection. For guidance on more complex database connections, see Connecting to environments.

If you have not yet set up a development database, you will want to provision a database whose schema matches the baseline state of your production database. You can do this via your own means, or using Redgate Clone or Redgate Test Data Manager to provision one. A common use case is to generate a development database based upon a sanitized clone or backup of production. You can also potentially populate a development database using Flyway only: if you are using migrations, you can populate an empty development database by creating a baseline script, and then running migrate on the empty development to deploy that script.

Choosing where to save environment configuration

If you have a dedicated development database, you will likely want to store that database connection information in your user settings. This allows you to configure your database without sharing that connection information through Version Control.

If everyone on your team is using the same development database, then it is preferable to save the database information to the project settings so that the connection information does not need to be reentered by everyone on the team.

It is also possible to spread the configuration between the two files. It might be that the URL is the same but your credentials differ.

Committing and pushing to Version Control

After you save your database changes to the schema model or save your migration scripts, you may want to commit these changes to your local version control repository and then push them to your remote repository to share them with your team. 

If you are using Flyway Desktop, you will see how many files need to be committed under the symbol in the right hand side panel. If you expand the panel, you can see the name of each file, if it was added/modified/deleted, open the file with the hyperlink, and expand it to view the differences If you wish to commit these changes to version control, then enter an appropriate commit message and click Commit. (If you are familiar with the Git cmdline or other tools, you do not have to stage your changes. Flyway Desktop does that for you automatically. If there are files that you are not ready to commit yet, deselect them from the list.). For more guidance see the tutorials on commit and push.

Associating commits with issues, work items, bug ids

For associating commits with issues, see this tutorial using a GitHub repository.

This process will be similar for any Git repos (Azure DevOps Repos, GitLab, Bitbucket, AWS CodeCommit, etc.). In GitHub, you can also use key words (close, closes, closed, fixes, fixed) in your commit message to update the status of the issue as part of the commit.  Check if your Git system also has similar options.

If you are using Jira, you can also associate Git with your Jira issues. Make sure you're Jira system is connected to your Git system.  You can find many apps on the Atlassian Marketplace for Git integrattion with Jira.

Relevant tutorials

• Tutorial - Configure the development database
• Tutorial - Save development database changes to the schema model
• Tutorial - Commit changes to version control
• Tutorial - Push changes to version control
• Tutorial - Associating commits with issues, work items, bug ids