Published 10 December 2019
Redgate Change Control allows you to make changes to your development database whilst you are working on features and improvements. When you are happy with your changes you can capture them as migration scripts by using the generate migrations workflow. You can share the migrations with the rest of your team and deploy them to other environments.
1. Make change(s) to your development source
Make changes directly to your development database or to your Source Control for Oracle project. In this example, we are adding a new column called TWITTER_ID to the CONTACTS table and we're also updating our GET_CONTACTS procedure to return this new column.
2. In Redgate Change Control, navigate to the Generate migrations tab
If you were previously on this screen and you do not see any changes, click Refresh in the top-right.
There's information that shows how long ago the project was refreshed. We also poll periodically to check for changes to your development source that have not been imported yet. If there are any changes, a little red asterisk will appear on the Refresh button.
After clicking Refresh the changes are shown:
3. Review the differences
Click on the objects in the top list to show the differences for that object at the bottom. This allows you to see exactly how each object will change. You can also sort the columns by clicking on the different column headers.
4. Generate scripts for the selected objects.
Select each object that you are ready to script out changes for. You can select all objects by using the checkbox in the column header. Then click Generate scripts in the top-right.
Be careful to only select your own changes if you are working on a shared development database with other team members.
5. Review scripts and update the version and description
This next page allows you to review the generated scripts. If your changes involve an object that stores data, such as a table, then a versioned migration script will be created. The next version number will automatically be picked up from your project, and a timestamp will be included in the version, which you can change if you wish.
Timestamps are included in vesioned migration filenames by default. RCC/RCA cannot apply two migrations with the same version number, which can happen when multiple developers are merging parallel migrations. The sequential timestamp ensures that even identical version numbers are still able to be applied to a database, since their timestamps will almost certainly differ.
You can edit the version number (e.g., maybe this is the next major version, V2.0). You can also provide a clearer description, which is the second part of the filename, so it's more obvious what the file contains. You can also edit the generated versioned migration script if you want to make any additional changes. An example of this is if I added a new NOT NULL column, I might want to provide an initial value for the existing records if the new column will not have a default.
If you selected any objects that manipulate data, such as a function, a repeatable migration script will also be generated for each object. This keeps the number of versioned migration scripts down if a lot of changes happen to these Programmable Objects (e.g., Packages, Procedures, Functions, etc.) This also allows you to see how each object changes over time using your version control system and easily get back to previous versions. It also helps with conflict detection if your branching in your version control system.
You can learn more about the different migration scripts in our Terminology Reference.
Once you're happy with your changes, click Save. This will write the scripts on the screen to your project folder on disk.
6. Review the summary
The summary page confirms which scripts were generated and their names.
- Commit the files to version control using your VCS command line or preferred tool.
- Once your changes are in version control, they can be included in your CI/CD processes. Learn more about this at Deploying database changes.
Writing your own migration scripts
You can also add your own migration scripts in the project folder. Make sure you are following your project's naming convention (V###__<description>.sql or R__<description>.sql). This can be useful for migration scripts that deal with updating transactional data or for scripts that are supplied to you by someone else. Once the migration scripts are in your project folder, you will need to apply the changes to your development database.