Options
Source Control and SQL Change Automation
xedni
Posts: 1 New member
I'm a SQL Developer now plopped into an environment essentially without a DBA, and I need to stand up version control and build/deploy procedures for the database I've inherited. I have a full SQL Toolbelt, and have looked at both SQL SQL Source Control and SQL Change Automation, but I'm a bit of a n00b to the "Ops" half of "DevOps", and I'm getting confused on where one ends and the other begins. I've read the documentation for both pretty thoroughly, but am still getting tripped up.
We have an existing database (not version controlled) for an application built in TFS and source controlled by Git. There are probably 2-3 other developers who might need to develop against the database as well and use whatever process I set up. Generally speaking, I like the migrations-based approach of SCA, but if I go that route:
* Is there any reason to put the same database managed by a SQL Change Automation Project under SQL Source Control as well?
* Should every developer maintain their own SCA project for their own local instance?
* Should those SCA Projects be source controlled as well, and if so, is that done by SQL Source Control (with a capital "S"), or just plain ol' Git Bash?
Sorry if this question is a bit broad in it's scope; perhaps there's a critical understanding I'm missing to make all the pieces fall into place, and I'm hoping someone out there has it.
We have an existing database (not version controlled) for an application built in TFS and source controlled by Git. There are probably 2-3 other developers who might need to develop against the database as well and use whatever process I set up. Generally speaking, I like the migrations-based approach of SCA, but if I go that route:
* Is there any reason to put the same database managed by a SQL Change Automation Project under SQL Source Control as well?
* Should every developer maintain their own SCA project for their own local instance?
* Should those SCA Projects be source controlled as well, and if so, is that done by SQL Source Control (with a capital "S"), or just plain ol' Git Bash?
Sorry if this question is a bit broad in it's scope; perhaps there's a critical understanding I'm missing to make all the pieces fall into place, and I'm hoping someone out there has it.
Tagged:
Answers
SCA VS and SCA Powershell
SCA VS is meant to be used at the development stage and generate migration scripts
If you prefer a state-based approach, you can use SQL Source Control (SOC) for development instead
SCA Powershell uses either SCA VS or SOC projects as inputs and handles builds and releases, using your analogy it is the component on the "Ops" side of things
If you look at the picture on this page: https://www.red-gate.com/products/sql-development/sql-change-automation/
SCA VS or SOC would be used at the start of the process on the left and then SCA Powershell takes over
You don't really need to use SOC if you decide to use SCA projects: Visual Studio has some Version Control support built-in, if you use a Version Control System not supported by VS you can always source control your solution folder using your VCS management tool.
In SCA VS, each developer should work with a local copy of the same project synched through source control.
Product Support Engineer
Redgate Software Ltd
Please see our Help Center for detailed guides on how to use our tools