Overview

Redgate Change Control helps you easily and safely version control your database schema and prepare deployments for SQL Server and Oracle databases. 

Redgate Change Control captures snapshots of your database objects into a schema model. You can version control and share changes to the schema model with teammates to rapidly iterate on new development. When you are ready to prepare a deployment, you generate migration scripts to deploy these changes safely.  Migration scripts are also committed to version control and are used as part of an automated CI/CD process to validate and deploy database changes to other environments (e.g., Test, Staging, Prod).

Get started with Redgate Change Control

1. Download and install latest version of Redgate Change Control. See system requirements for more information on supported Operating Systems.
2. Launch Redgate Change Control from the start menu.
3. You can create a new project, open an existing project that your team member setup, or open an existing Flyway configuration since we are compatible with Flyway migrations.
4. Once you have opened/created a project, go to the Schema model tab
   1. You will be prompted to configure a development database.
   2. Refresh to see changes that have been made to your development database that aren't in your project schema model yet. You can select the changes that you want to import.
      1. Alternatively, press the Apply to database toggle to invert the comparison. This allows you to update your database to match the project schema model.
   3. When you have made your selections, click Save to capture them.
5. At this point there are several options:
   1. Go to the Version control tab or open your project in an external version control client to commit your changes to version control.
   2. Continue to iterate on making changes to your development database and updating the schema model.
   3. Go to the Generate migrations tab to selectively capture your schema model changes in a migration script
      1. By default, only a single versioned migration script will be generated, but it is possible to set an option to generate repeatable migration scripts for programmable objects (procedures, packages, views, functions, etc.). We currently recommend that you leave this option disabled when working with SQL Server projects – learn more on Redgate Change Control using SQL Server.
      2. Versioned migrations have a version number, a description, and a checksum. The version number must be unique. The description is purely informative for you to be able to remember what each migration does. The checksum is there to detect accidental changes. Versioned migrations are the most common type of migration. They are applied in order exactly once.  They are named V<VersionNumber>__<description>.sql (for example, V1__InitialChanges.sql - note: a double underscore is required to be present after the version number). 
      3. Repeatable migrations have a description and a checksum, but no version number. Instead of being run just once, they are (re-)applied every time their checksum changes.  This is helpful because you can see how the objects change over time using your version control system and also helps to keep the number of migration scripts down. They are named R__<description>.sql (for example, R__prcGetEmployees.sql - note: a double underscore is required after the R).
   4. When you first use the Generate migrations tab, Redgate Change Control prompts you to generate a baseline migration script. This is required in all situations where you are intending to deploy to a non-empty database. As a one-off operation the application will need to link to a downstream database which you are intending to make changes to via this pipeline, in order to generate a script which captures the existing state of the database.
6. Once you have generated a migration script, go to the Version control tab or open your project in an external version control client to commit it to version control. If you are working in a newly created project where Git has not been initialized, see Version control.
7. Migrations can be deployed by running the flyway migrate command. Running this command against an arbitrary database is not yet supported within Redgate Change Control, although it is used internally to build the shadow database. You can either run this command manually or as part of a CI/CD pipeline.
   1. Within a single migration run, all the pending versioned migrations that have never been applied to the database are run first, followed by any repeatable migrations that have been changed.  Both sets are run in alphabetical order.
   2. To keep track of which migrations (versioned and repeatable) have already been applied when and by whom, the flyway_schema_history table is added to the first schema that you're tracking changes to.
   3. For more information, please see our Terminology Reference.
8. If you want your migration scripts to be in version control and part of an automated validation and deployment process, learn more about how to deploy database changes as part of your CI/CD process.

Feedback

We’re looking to continually improve Redgate Change Control.  Please share questions and feedback with us via this quick survey.

Additional 'Getting Started' topics

• About Redgate Change Control
• System requirements
• Redgate Change Control using Oracle
• Redgate Change Control using SQL Server
• Redgate Change Control using other databases
• Development database environment configuration

Helpful links when getting started

• Redgate Change Control using Oracle
• Redgate University - Redgate Change Control
• Database DevOps FAQs
• Roadmap
• Proof of Concept Checklist