November 16, 2011 at 8:19 am
Hi Guys!
I have 2 goals. pls guide me does Red-gate help for this.
1) Red-gate support for Version controlling with Subversion ; This means that i can put my SQL Server in Subversion through subversion. Benefits?????
2) I want when dev commit in Subversion ; the Redgate automatedly deploy those changes on SQL Server. Is it possible? If it is possible then HOW would i do this?
For Automated deployments of Scripts(SPs , DDL/DML Scripts , Views , Functions , triggers) ; is it mandatory to put my DB under version control through RED-Gate?
I hope you guys will Guide me elaborativey and tell me specialy those part that i have missed.
Thanks in advance.
November 16, 2011 at 8:45 am
1) you don't put your sql server in subversion, or any VCS. You check in changes of the objects into the VCS. The benefits are that if you need to roll back, or recover older changes, you have a record in the VCS of what the objects looked like.
2) you're misunderstanding what happens. The Dev working in a dev environment compiles the changes on the SQL SErver instance already. With the Red Gate tool, the change is tracked, but you have to commit it to Subversion. Those changes are then linked with that particular database.
IF you want to deploy to another instance, there is a feature in SQL Source Control that will use SQL Compare and move those changes to another instance, but you don't want that to happen automatically. Part of the process of deploying changes is ensuring that the proper changes are deployed, and in a controlled way. Not every change will need to be deployed all the time, and not every change can go alone. Some need to be deployed in batches.
What SQL Source Control can do is detect changes submitted to a central VCS, but not deployed on your particular instance. So if you have InstanceA and another developer has InstanceB, and both are linked to the SalesDB point in a VCS with SQL Source Control, the tool does allow you to pull changes back to InstanceA, which another developer committed to the SalesDB VCS after compiling them on InstanceB
November 16, 2011 at 8:51 am
Thanks for the wonderful answer.
kindly explain this.
but not deployed on your particular instance. So if you have InstanceA and another developer has InstanceB, and both are linked to the SalesDB point in a VCS with SQL Source Control, the tool does allow you to pull changes back to InstanceA, which another developer committed to the SalesDB VCS after compiling them on InstanceB
November 16, 2011 at 9:58 am
You can connect multiple databases to the same branch in a VCS.
Suppose you create the SalesDB project/branch in VCS (Subversion/Git/etc). That is done outside of SQL Source Control, and potentially you also include some .NET code, PHP code, etc in there.
On your local laptop, you install SQL Server as Instance1, just for you. You create a database, MyDB, link this database with SQL Source Control to the SalesDB project in your VCS, and then start adding objects.
As you add those objects, they are compiled and created in Instance1/MyDB. At some point you commit these objects to the VCS and SQL Source Control checks in the CREATE code for the objects into the VCS for you.
Your friend, Bob, has his own laptop, and he creates a database on his Instance2 called BobDB. He can link this database, with SQL Source Control, to the same project, SalesDB, in the same VCS. This can happen if the VCS is on a file share, or accessible to http or another network link.
Once Bob creates this link, the SQL Source Control tool reads the VCS, notes which objects are different than on his local database, which is all of them at this point. He then can update his database from source control with SQL Source Control.
At this point you two both have synchronized BobDB and MyDB to the same schema.
You create a new table, SalesReports, on your MyDB database. You commit this to VCS. SQL Source Control detects this (it polls periodically) and then changes an icon so Bob is aware there are changes in the VCS that he does not have. He can pull those changes down and apply them to his database. The reverse can also happen.
It is possible that you both make colliding changes here, so the resolution for that is manual.
It is also possible that you link a third database, say on the QA server, SalesQA database to the same VCS. You could attach to the QA server with your SSMS, and if you have SQL Source Control you can apply the changes that were checked into the VCS back to the QA database if you wish.
Or you can go from your instance, MyDB, and use SQLCompare (linked from within SQL Source Control), to build a script and apply that to the QA server.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply