If I’m understanding your question correctly, it sounds like you’d like to use the VCS as the database of record for changes made in development to apply to other environments through your CI/CD process. Is this correct? If so, Team Coding doesn’t directly provide that functionality. There are a number of reasons this is the case:
- Every company generally has its own strategy for how it wants to structure its VCS repository.
- Some companies have tried to configure Team Coding into a existing structure that already has files and revision history stored inside it.
- Some companies are using the VCS as a historical archive repository, removing old deprecated objects in the database since they’re stored historically in the VCS.
- Team Coding stores the snapshot of the object DDL at the time of the change, rather than a diff patch of the object between revisions. As a result, executing changes such as table DDL modifications, could be detrimental to the underlying data if applied directly from the VCS as opposed to a sync script.
Team Coding is designed to manage source and change control within a database environment, but it has no ultimate control over the quality or cleanliness of the VCS repository to which it attaches. As a result, a more common solution for deploying changes is to use the Database and Schema compare features of TDT or TOAD when ready for deployment, which can create sync scripts to bring the destination environment current with the source environment. John Pocknell created a short video to demo this here:
This sync script could be then used as a deployment script. Once created, it could be published for review and approval as part of the CI/CD process, and also be saved up in the VCS for versioning purposes before being executed within your CI environment. In this kind of setting, Team Coding would be used in your development environment for source, change, and version control, along with code quality metrics (if using Code Analysis integration); database and schema compare through TDT could then be used to generate, review, and deploy database changes within your CI environment. It could also be used to generate reversion scripts. If approved, your CI script could then save those deployment scripts off to the VCS.
In case it helps at all, John also created a 10-part video series about using Toad for Oracle in an agile environment. Not all of it may be applicable to the current version (as it was created two years ago), but in case it helps:
Hopefully this helps to answer some of your questions and/or provide some additional direction on how you can leverage each tool in your environment. If you have any additional questions, or if there’s anything else we can do, please do feel free to respond and ask. We’re happy to help wherever we can.