Deploy changes to databases
dbForge Source Control is designed to simplify database change management among multiple developers within a team. The tool provides a straightforward process for committing changes to the repository, automatically generating scripts for database objects. In the Source Control Manager of the tool, the developer can easily select an object from the list and commit its changes to the repository. Subsequently, the Source Control tool detects the changes, generates a script for the object, and delivers it as a .sql file to the repository. When another developer needs to retrieve the latest changes from the repository, the tool deploys those changes by updating the database with the generated .sql script.
Note
Source Control starts tracking changes after the database has been linked to source control.
It is also important to link static data to source control to prevent any data loss when updating your local database with the latest changes from the remote repository or reverting database changes made to the object and static data in a database.
Prerequisites
Let’s assume there are two sample databases - development and production - and a development repository. The databases are synchronized, ensuring that objects such as Table1 and Table2 of both databases remain consistent with their DDL operations.
We need to pull the changes from the development repository and deploy them to the production database using the Source Control tool within the Studio.
The point to consider is the timing of when the user re-links the production database - before or after committing changes.
Let us explore the following deployment scenarios:
- Case 1: Both databases are linked to the same version control repository. A user makes changes and commits them to the repository without disconnecting from it at any point. Then, the user gets the remote changes into the production database.
- Case 2: Both databases are linked to the same version control repository. However, for some reason, a user disconnects the production database from the repository, modifies the development database, and commits changes. Then, the user re-links the production database to the repository to fetch any remote changes.
Case 1
1. Link the development and production databases to the development repository in the dedicated database development mode. The Refresh progress window opens automatically, showing the stages of the refresh operation. Also, the Source Control Manager opens for each database.
Note
The database can be linked to the repository anytime before committing the changes.
2. In the development database, modify Table1 by adding a column, delete Table2, and add Table3 to the database.
3. Commit these changes to the development repository. The Commit progress window opens, showing the stages of the commit operation. When all the stages are complete, click OK to close the window.
4. Switch to the Source Control Manager of the production database and refresh it. Source Control detects the changes and displays them with the following change types in the Remote changes section:
- Modify for Table1
- Remove for Table2
- Add for Table3
5. Select the objects whose changes should be deployed from the repository to the production database and click Get Latest.
Case 2
1. Link the development and production databases to the development repository in the dedicated database development mode. The Refresh progress window opens automatically, showing the stages of the refresh operation. Also, the Source Control Manager opens for each database.
2. Unlink the production database from the repository.
3. In the development database, modify Table1 by adding the column, delete Table2, and add Table3.
4. Commit these changes to the development repository.
5. Link the production database to Source Control and see the following:
- Table1, which has been modified, is now marked as a conflict.
- Table3, which has been added, is in the Remote changes section.
- Table2, which has been removed, is in the Local changes section.
6. To deploy the changes to the production database, select the objects and do the following:
- In the Remote changes section, click Get Latest for Table3.
- In the Local changes section, click Undo for Table2. In the pop-up window that displays, click Yes to confirm the undo operation.
- In the Conflicts section, click Get Remote for Table1. After that, the table with the Modify change type will be displayed in the Remote changes section. Select the object and click Get Latest.
In conclusion, when deploying changes from the development repository to the production database using dbForge Source Control, it is recommended to always maintain the connection between the source control and the production database. Alternatively, it is possible to deploy changes using the dbForge Schema and Data Compare tools.
Helpful guides
Want to Find out More?
Overview
All features
Request a demo
