Our goal is to help you make deployments to Oracle databases as easy and safe as possible.  We do this by helping you generate migrations scripts that capture changes made to a development database.  These migration scripts can then be tested and used as part of a process to automatically deploy database changes to other environments (e.g., Test, Staging, Prod). 

Watch this 8-minute video to see how to capture development database changes using Redgate Change Control, commit and push them to Git, kick-off a build and test process, and then automatically deploy changes through a release pipeline, including a manual intervention step before going to Production.

You can access a free 28-day trial of Redgate Change Control from here.

Requirements 

1. .Net Core Runtime – available at https://dotnet.microsoft.com/download 
2. A Development Source.  This could be a:
   1.  Development Database that you want to make and capture changes to.
   2. A Source Control for Oracle project that represents changes made to a development database that you now want to generate migration scripts from for deployment.
   3. Learn more about the Development Source.
3. A Shadow Database, which is a separate database or schema to run the project scripts against.  The Development Source is compared to the Shadow Database when you go to the Generate migrations tab to understand any changes made in development that haven’t been imported into the Redgate Change Control project yet. 
   1. In the Shadow Database, the user will need permission to create schemas.  If this is not possible, then the schema(s) that you are tracking changes to in Dev need to exist on the shadow.  Make sure the schema name in the shadow has the same casing as the schema name in Dev.
   2. Learn more about the Shadow Database (or Shadow Schema).

Supported Oracle versions

Oracle versions compatibility is aligned to 

• 19c
• 18c
• 12c
• 11g
• 10g

Getting started

1. Get the latest version of Redgate Change Control by installing Redgate Deploy.  
2. Launch Redgate Change Control from the start menu.
3. You can then 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 opened/created a project, there are several options:
   1. On the Generate migrations tab, you'll be able to see changes that have been made to your development database that aren't in your project yet. You can select the changes that you want to import into a new migration script. Stateful objects (ie Tables) will be put into versioned migration scripts. Programmable objects (procedures, packages, views, functions, etc) will be put into repeatable migration scripts. 
      1. 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 (eg. V1__InitialChanges.sql - note: it's a double underscore after the version number). 
      2. 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 (eg. R__prcGetEmployees.sql - note: it's a double underscore after the R). 
      3. 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.
      4. To keep track of which migrations (versioned and repeatable) have already been applied when and by whom, a redgate_schema_history table is added to the first schema that you're tracking changes to.
      5. For more information, please see our Terminology Reference.  
         
   2. On the Apply to database tab, you’ll be able to review and apply migrations scripts in your working folder to your development database.  This could come in handy if you want to create a migration script that changes data or if you have a dedicated development database and pulled the latest changes to your working folder using your version control system and want to apply your team members' changes to your development database. 
   3. On the Apply to database tab, you can also change the drop-down from view pending to view all migration scripts to see a list of migrations scripts that have been applied to your development database.  
5. If you want your migration scripts to be in version control and part of a Continuous Integration/Development process, learn more about how to deploy database changes as part of your CI/CD process.

We’re looking to continually improve this solution.  Please email the Oracle development team with your questions/feedback.

Some helpful links:

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

Note: 

• Since we are compatible with Flyway migrations, you can run Flyway commands against configurations created and used by Redgate Change Control.  This allows you to use advanced Flyway features that are not implemented within Redgate Change Control yet (e.g., callbacks, undo).  When running Flyway outside of Redgate Change Control, make sure you either run flyway in the same directory that contains your configuration file or set the workingDirectory flyway command line option. This should ensure that Flyway reads the correct configuration file and resolves the path to the migrations folder appropriately.