Comments
9 comments
-
Issue '1' can be solved by importing as a database project straight away. I'm guessing the reason you don't is because of the overhead of keeping source control up to date, which leads me on to '2'. The process you outline requires a separate step to ensure source control is up to date. So although you can claim that your database changes are source controlled, you aren't using the tools in a way to manage this. You are effectively doing this manually by swapping out to Visual Studio as and when you need to import a change. This model is what is called the "offline" or "disconnected" model. Conceptually you're source controlling files and not database objects.
This is essentially why we developed SQL Source Control. We wanted to provide a completed integrated solution where we'd manage those changes for you, and cut out the manual step. The way this works is that SQL Source Control keeps track of the database changes on your dev instance. This is called the "connected" development model.
Is there a reason you're using VS database projects over SQL Source Control? If there's a desire to source control your changes as part of a VS solution, then maybe Redgate ReadyRoll should be considered. This uses the connected model, but is implemented as a VS extension so could be the best of both worlds for you.
-
Thanks for this David. I agree with the sentiments above and that we're essentially using source control in name only. I'm currently using Red Gate sql source control with a working folder which doesn't give me the history but does still benefit me a lot (seeing which objects have changed, reviewing changes etc).
I've only been here a few weeks. I'm definitely going to at least demo Sql Prompt and Sql Source control (when I mentioned it I got a lot of hesitation as they said their method was free, although i do question that).
What dissuaded me from pushing on this was the collective satisfaction amongst the other developers with this process. It may have been a lack of confidence on my part owing to my lack of experience with Visual Studio, one of the reasons why i've thrown the question out to the community to get some input.
In my opinion however, they will never achieve any sort of efficient development pipeline (moving on to CI, automated unit testing etc). It's a difficult one when coming into an established team. -
If you're using a working folder, you can use an external version control client to commit the changes to build up a version history. Is there a reason you're not using SQL Source Control's native connectivity? Or is it because versioning happens in VS database projects so your only need at the moment is to track which changes you've made since the last commit?
-
Ben,
The only thing I don't think is pretty normal for working with SSDT Database Projects is the not putting in Source Control right away. I do work in a disconnected model similar to how you describe. My process currently using SSDT is to:- Create Database Project and develop initial objects in SSDT
- Publish to a development (usually local) SQL Server
- Make changes & unit test on the development server
- Push changes to Database Project from Dev server
- Publish from Database Project to QA
Promotion of code is always from the database project, so no new changes should be made anywhere but development.
It isn't ideal and I do like the integration of SQL Source Control into SSMS. You can use both SSDT database projects and SQL Source Control, but there are some things that aren't supported when you do both.
The reason I use Database Projects in SSDT instead of SQL Source Control is because in a database project the database settings are also part of the project and under source control, while SQL Source Control only includes the schema and things like SET options and collation definitely affect the way you have to code.
-Jack
-
I'm thinking about installing VisualSVN server or getting an account on GitHub and learning about that. The two reasons I'm not using TFS with RedGate source control are
1. i was struggling associating the check-ins with a TFS work-item and couldnt get past that commit-hook
2. I believe the folder structure that red gate generates would differ to a visual studio database project.
the second one isnt really an issue, i'm still trying to figure it all out -
thanks Jack, that is really helpful
-
@ben_b Sorry to hear about (1) - did you raise this with Redgate support? The #A #R syntax should in theory work...
Yes, Redgate's structure is slightly different to the VS project. Redgate tools do a pretty good job at reading database projects, but the reverse isn't true.
If you're picking a VCS from scratch, pick GitHub (or any other implementation of Git), as this is the future. VisualSVN might be more familiar, but you won't be learning any valuable skills by choosing this. -
Ben,
Glad my post helped some. I agree with David that you should go the Git model as that is what almost all development shops are using now and TFS has a Git mode that most TFS shops are moving to.
I would recommend playing with the combination of SQL Source Control and Database Projects. It isn't perfect, but it can work. Here's the latest documentation on using the 2 together. I have played with it on the side, but haven't used it as my process yet. -
thanks both for all the info. will definitely have a look at git (probably having a crack at the TFS version first). I couldn't get the #A feature to work although I've never setup a TFS server before I didn't know if it was something on that side.
I'm not sure if this uservoice details the same problem
/redgate.uservoice.com/forums/39019-sql-source-control/suggestions/538567-add-ability-to-associate-check-ins-with-work-items
If i setup a new TFS git repository i'll try using the #A work-item functionality at the same time.
Add comment
Please sign in to leave a comment.
I recently joined a new company in their BI team. A lot of the team have some .NET experience but we are purely doing database work at the moment. It's a fairly new team so there aren't many processes in place at the moment. We have TFS 2017.
Before I joined, some of the guys here (all 10+ years experience) agreed upon and use the following process.
1. A new database is created and the first iteration of work is done in SSMS (with no source control)
2. Once they are happy they have 'v1.0' they use Visual Studio to import the database as a database project and then check-in
3. Troubleshooting and changes from then on in are worked out in SSMS. Once they are happy they want to change an object, they check it out, make the change in Visual Studio before being checking back into TFS.
I have always done my database work in SSMS with Red Gate Sql Source Control although I am comfortable with Visual Studio/SSDT.
What I would like to know is if the above process is in anyway 'normal' in the industry?
The disadvantages I see are:
1. no source control benefits until v1.0 is ready.
2. lots of chopping and changing of tools. Visual Studio essentially only being used to perform check-ins/check-outs (rightly or wrongly they use VS community edition).
Are there any DBAs or BI Developers (or even .NET guys) who have largely ditched SSMS and mostly use Visual Studio/SSDT? If I am to be working on TFS without Red Gate source control would you recommend purely using Visual Studio/SSDT??
I feel the SSMS + Redgate approach is a much better experience but I dont want to bias my decision because that is what I have become comfortable with.
thanks
Ben