Redgate Change Control is made for the database developer. It helps you understand changes made to your development database and generate migrations scripts for these changes. These migration scripts are included in your version control system and describe the sequence of changes required to move the database from one version to another. They can then be used in your Continuous Integration (CI) and Continuous Delivery (CD) processes for a safe and reliable deployment process.
Redgate Change Control works with any version control system. The migration scripts are written to a folder and then you can use your preferred version control system client to perform the necessary version control operations. This provides a lot of flexibility, but we also knew that most of our users use Git and we wanted to integrate the most common Git operations (commit, push, pull, create branch, and switch branch) directly into Redgate Change Control, for a more integrated experience. This is now available in v3.
Setting up Git
Before creating a Redgate Change Control project, clone a remote Git repository to create your own local Git repository. This might be a brand new Git repository, if you’re just starting to capture project changes in Git, or it might be an existing repository which already has your application code, so that you can now track the database code alongside it.
Once you have a local Git repository, check this out to a working directory. This is folder that you’ll want to specify as your Project folder when creating a new project.
As long as you specify a Git working folder for your project, then you’ll have access to all the new Git functionality in Redgate Change Control.
If you are working on a team and each developer, or different teams, have their own development copy of the database schema, then it’s a best practice to pull any of the other changes committed to the remote repository first. Once you pull any changes from the remote repository, you’ll then need to click the Apply to database tab to execute these migration scripts on your development database. Now, you have the latest version of the schema(s) in your development environment and you’re ready to start making changes.
After generating migration scripts, visit the Version Control tab to get a list of all the migration scripts that are yet to be committed.
From here, you can enter a comment and click Commit. If you’re familiar with Git terminology, clicking Commit both adds the changes, in this case the new migration scripts, to the Staging area and commits them, just to your local Git repository. The local repo is your sandbox, or play area, where you can make and test changes without fear of disrupting the work of others.
Once you’re confident in these changes and ready to share these with your team, then click Push.
This will push all commits that currently exist in the local repository to the remote.
Some teams use feature branches for their development work. With Redgate Change Control, you can now create new branches and switch between branches. If you’re developing on a feature branch, you can commit and push your changes to this feature branch. Then, you can use your Git client to perform a pull request to have these changes reviewed before their merged back into the main branch. Whatever branching strategy your team uses (GitFlow, GitHub flow, etc.), remember to name your branches clearly and that use of short-lived branches is usually the best strategy.
Where Next: Deploying database changes
Now that your database changes are captured as migration scripts in Git using Redgate Change Control, learn more about how to use Redgate Change Automation to deploy your database changes safely to other environments. Redgate Change Automation is available on Windows or Linux and helps you build, test, and deploy database changes safely through an automated pipeline. Both Redgate Change Control and Redgate Change Automation are part of the Deployment Suite for Oracle.
You can now perform everyday Git operations like commit, push and pull directly from within Redgate Change Control. If you’re using branches in Git, such as feature or development branches, you can even create and switch branches directly from Redgate Change Control.
If you have any questions about these new features or need help setting up Compliant Database DevOps for your team, then please get in touch with the Redgate development team.
Was this article helpful?