Redgate Change Control 4

Creating a new project

In v5, Redgate Change Control has been renamed to Flyway Desktop. Check out the latest documentation at https://documentation.red-gate.com/fd


A Redgate Change Control project allows you to track changes to a development database and generate migration scripts that can be versioned controlled and used for continuous integration and automated deployments.  One person on your team should create the project and commit/push it to your version control system to start working with other team members.  Other team members can then clone or pull the latest version version control and then use the Redgate Change Control home screen to open an existing project.

If you are using Git, we recommend that you clone the repository to your machine first to create a local repository that you will work in.

To create a new project, click New project... on the home screen.

This will bring up a New Project page. 

Configure the project

Enter a name for the new project and specify the location on disk for the project files that will be created.  If you want to use the integrated Git functionality, then this folder should be in an existing local Git repository. It's best if you capture these changes in a dedicated area, maybe by creating a "Database" folder in an existing repository.  This way all database related scripts can be kept together. 

Select the Database Type (Oracle or SQL Server (preview)).  In this example, we use SQL Server.

Click Create project.

Per-user settings

Some settings (particularly the urls and credentials for the development and shadow databases) may need to vary for each user of a project. Redgate Change Control will create new projects with a separate per-user settings file stored adjacent to the main configuration file. These files have the .user.json  extension.

Settings in the per-user files override settings specified in the main project file. If required, development and shadow database details can be kept in the main project file, but using dedicated per-user databases is recommended wherever possible.  The .user.json file is added to the .gitignore file so these user-specific settings are not committed to version control.




Didn't find what you were looking for?