dbForge Source Control is designed to streamline 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 dbForge Source Control.
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:
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. Refresh the Source Control Manager.
4. 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.
5. 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:
6. Select the objects whose changes should be deployed from the repository to the production database and click Get Latest.
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. The Commit progress window opens, showing the stages of the commit operation. When all the stages are complete, click OK to close the window.
5. Link the production database to Source Control and see the following:
6. To deploy the changes to the production database, select the objects and do the following:
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.
1. In Object Explorer, right-click the database containing the changes and select Source Control > Commit.
2. In the Local Changes section, select the checkboxes next to the changes you want to commit and click Commit.
3. The Commit progress window opens, showing the stages of the commit operation. When all the stages are complete, click OK to close the window.
Note
The flow may differ depending on the timeline you link the databases to version control - before or after the commit operation.
4. In Database Explorer, right-click the remote production database and select Source Control > Get Latest.
Note
If you have modified the same object in both databases, Source Control will mark it as a conflict. To resolve a conflict, go to the Conflicts section, select the object and click Get Remote to apply new changes to the remote database. For more information, see Resolve conflicts.
5. In the Remote changes section, select the object and click Get Latest. For more information, see Get the latest version.
6. Confirm that you want to pull the latest changes and click OK. The Get Latest progress window opens, showing the stages of the operation. When all the stages are complete, click OK to close the progress window. The production database will be updated with the latest changes.