Migration Scripts

To learn more about migration scripts including versioned migration scripts, repeatable migration scripts, treating programmable objects as repeatable migration scripts, undo migration scripts, and the order of execution for migration scripts, please see our page about Migration scripts.

Schema model tab

With Redgate Change Control it is possible to capture database changes into a schema model on the Schema model tab, which provides convenient object-level history in your version control system. The schema model tab will not be visible for older projects which do not have a schema model specified. This behaviour can be enabled by adding a schema model definition to your project settings.

Generate migrations tab

On the Generate migrations tab, you'll be able to see changes that have been made to your schema model that have not yet been captured in migration scripts. You can select the changes that you want to import into a new migration script. For older projects without a schema model changes are imported into migrations directly from the development database.

Apply to database tab

The Apply to database tab is only visible when using older projects which do not have a schema model specified.

On the Apply to database tab, you’ll be able to apply migrations scripts in your Migrations Folder to your development database.  This could come in handy if you want to create a migration script offline and then apply those changes to your development database.  This could be for a complex change that the tool won't generate correctly or for changes to update transactional data that need to be deployed. 

The Apply to database tab is also important if everyone on your team is working on a dedicated development database or you are switching branches.  Pull the latest changes to your Migrations Folder using your version control system and then apply the changes to your development database. 

Viewing all migrations

On the Apply to database tab, use the Show drop-down to change from Pending migrations to All migrations.  you'll be able to see information about all the migration scripts that have been applied to your development database.  You'll also see any pending migrations that are in your Migrations Folder that haven't been applied to the development database yet.  If any migration scripts failed during their execution, these will appear as well.

Some repeatable migrations will also show as superseded.  This means an older version of the repeatable migration was applied, but since then a change has caused the changed repeatable migration script to be re-applied at a later time.    

Development database

A development database is linked to a project for the purpose of generating Migration Scripts. Redgate Change Control enables a connected development experience.  You can make changes directly to your development database, and then when you're ready to commit these to your version control system, use the Schema model tab to script these to your project. When you are ready to deploy these changes to a downstream environment you can generate migration scripts using the Generate migrations tab. 

Shadow database

The shadow database is a separate database that is needed for generating migration scripts only.  When you generate migrations with Redgate Change Control, we run the scripts in the project against the shadow database.  Then, we use our Schema Compare for Oracle technology to compare the schema model or development database to the shadow database.  This allows us to show you what changes have been made to your project that have not been captured in migration scripts.  

See Shadow Database (or Shadow Schema) for more details.

Baselining

When working with an existing database, you must setup a baseline script that represents the current state of your database.  This is necessary so that we can build the shadow database from scratch when you generate migrations to understand any new changes on your development database that haven't been imported into the project yet.  This is also important so you can spin up new environments in dev and test or deploy to new client sites.  Learn more about how to setup a baseline at Creating a baseline script.