PDA

View Full Version : Source Control for Databases - Nightmares with TFS



NorthWestPerm2Contr
27th May 2015, 16:37
TFS is driving me and the other developers absolutely mad.

Over the years I have worked with various versions of Visual Source Safe (VSS) and several incarnations of SVN. I have enjoyed using them and they have allowed me to deliver outstanding solutions to companies.

Alas, come TFS 2013 the destroyer of all expert Database and Data Warehouse masters. I honestly get the idea behind it and how it is supposed to be the "proper way" of doing database deployment. But how much easier, quicker and endlessly more efficient was it to be able to open up your Drop/Create statements from file straight into Management Studio, do all of your coding using nifty tools such as Redgates SQL Prompt and then save the file thereafter checking it in.

Now editing all of the objects is a real frustration as it has to go and do all it's checks and do a full deployment. Not only that but I have to move code in and out of Management Studio. After several discussions we are all in agreement that for the size of team and the development approaches and methodology, TFS is reaping absolute havoc on us.

Has anybody else had a similar problem and what was your solution?

northernladuk
27th May 2015, 16:37
Hand your notice in and leave? ;)

NorthWestPerm2Contr
27th May 2015, 16:43
Hand your notice in and leave? ;)

If only it were that simple with TFS..... I'd have ditched it for another Source Control Editor in a heart beat ;-)

eek
27th May 2015, 19:03
Why is TFS doing a full deployment on check-in? I think you need to decide on your build and deployment approach...

SimonMac
27th May 2015, 20:00
You can go into the job and change the paramaters so that it doesn't do all the checks, its not very intuitive, I think a double negative to get the right setting "don't do not do the checks" kinda thing, I will have a dig through my old notes and try and find the right config items

NorthWestPerm2Contr
28th May 2015, 10:09
You can go into the job and change the paramaters so that it doesn't do all the checks, its not very intuitive, I think a double negative to get the right setting "don't do not do the checks" kinda thing, I will have a dig through my old notes and try and find the right config items

It's more to do with the pain of editing objects and developing between management studio and VS. I prefer to do all development in SSMS. VS should just be used for source control and checkin/check out/diff functionality.

woohoo
5th June 2015, 17:33
It's more to do with the pain of editing objects and developing between management studio and VS. I prefer to do all development in SSMS. VS should just be used for source control and checkin/check out/diff functionality.

I agree it's a pain that source control is not integrated into SSMS, probably like you I checkout/in using VS then mostly work in SSMS. If I'm adding new sprocs, tables then I tend to work in SSMS then in VS do a compare and update the database project with the new changes. Its not pretty but works fairly well.

The good thing is we can now do deployments and be confident that the code going onto production is the code that's been tested.

NorthWestPerm2Contr
5th June 2015, 19:39
I agree it's a pain that source control is not integrated into SSMS, probably like you I checkout/in using VS then mostly work in SSMS. If I'm adding new sprocs, tables then I tend to work in SSMS then in VS do a compare and update the database project with the new changes. Its not pretty but works fairly well.

The good thing is we can now do deployments and be confident that the code going onto production is the code that's been tested.

I have found a solution, it costs money but it's well well worth it. Part of the redgate toolbelt. I have already invested in SQL Prompt and this one now makes development on Databases a breeze. You wonder why Microsoft can't do it's job properly and requires 3rd parties to come in and show it how it is done.

woohoo
5th June 2015, 20:49
I have found a solution, it costs money but it's well well worth it. Part of the redgate toolbelt. I have already invested in SQL Prompt and this one now makes development on Databases a breeze. You wonder why Microsoft can't do it's job properly and requires 3rd parties to come in and show it how it is done.

Tell me more?

NorthWestPerm2Contr
5th June 2015, 20:54
Tell me more?

connects Management Studio directly to TFS, overlays SSMS with source control features. I should be a salesman for Redgate (If only they matched my day rate!)

SQL Source Control - download a free trial for a month. I will be buying it at the end of the trial and it only took me 1 hour to realise that!

woohoo
6th June 2015, 07:12
connects Management Studio directly to TFS, overlays SSMS with source control features. I should be a salesman for Redgate (If only they matched my day rate!)

SQL Source Control - download a free trial for a month. I will be buying it at the end of the trial and it only took me 1 hour to realise that!

Great will take a look when back off my hols.

BlueSharp
11th June 2015, 10:07
In the past we have got VS to deploy the development instance to a local db and then made changes using SSMS. When it comes to checkin you can do a compare in VS to identify the changes so it will auto check-them out for you. If it builds locally with sql unit testing, checks then your good to check the changes in.

NorthWestPerm2Contr
12th June 2015, 21:26
In the past we have got VS to deploy the development instance to a local db and then made changes using SSMS. When it comes to checkin you can do a compare in VS to identify the changes so it will auto check-them out for you. If it builds locally with sql unit testing, checks then your good to check the changes in.

Try using the tool I suggested and you will see the phenomenal difference. Even if you are working as you suggest it still is very useful. Most places I have worked have a single dev Database due to limited number of developers - usually I control things when it comes to dev/source control/deployment. Local DB makes a lot of sense in larger teams, except it can kill your machine with intensive queries.