THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Jamie Thomson

This is the blog of Jamie Thomson, a freelance data mangler in London

SQL Server devs–what source control system do you use, if any? (answer and maybe win free stuff)

Recently I noticed a tweet from notable SQL Server author and community dude-at-large Steve Jones in which he asked how many SQL Server developers were putting their SQL Server source code (i.e. DDL) under source control (I’m paraphrasing because I can’t remember the exact tweet and Twitter’s search functionality is useless). The question surprised me slightly as I thought a more pertinent question would be “how many SQL Server developers are not using source control?” because I have been doing just that for many years now and I simply assumed that use of source control is a given in this day and age.

Then I started thinking about it. “Perhaps I’m wrong” I pondered, “perhaps the SQL Server folks that do use source control in their day-to-day jobs are in the minority”. So, dear reader, I’m interested to know a little bit more about your use of source control.

  • Are you putting your SQL Server code into a source control system?
  • If so, what source control server software (e.g. TFS, Git, SVN, Mercurial, SourceSafe, Perforce) are you using?
  • What source control client software are you using (e.g. TFS Team Explorer, Tortoise, Red Gate SQL Source Control, Red Gate SQL Connect, Git Bash, etc…)?
  • Why did you make those particular software choices?
  • Any interesting anecdotes to share in regard to your use of source control and SQL Server?

To encourage you to contribute I have five pairs of licenses for Red Gate SQL Source Control and Red Gate SQL Connect to give away to what I consider to be the five best replies (“best” is totally subjective of course but this is my blog so my decision is final Smile ), if you want to be considered don’t forget to leave contact details; email address, Twitter handle or similar will do.

To start you off and to perhaps get the brain cells whirring, here are my answers to the questions above:

  • Are you putting your SQL Server code into a source control system? As I think I’ve already said…yes. Always.
  • If so, what source control server software (e.g. TFS, Git, SVN, Mercurial, SourceSafe, Perforce) are you using? I move around a lot between many clients so it changes on a fairly regular basis; my current client uses Team Foundation Server (aka TFS) and as part of a separate project is trialing the use of Team Foundation Service. I have used SVN extensively in the past which I am a fan of (I generally prefer it to TFS) and am trying to get my head around Git by using it for ObjectStorageHelper.
  • What source control client software are you using (e.g. TFS Team Explorer, Tortoise, Red Gate SQL Source Control, Red Gate SQL Connect, Git Bash, etc…)? On my current project, Team Explorer. In the past I have used Tortoise to connect to SVN.
  • Why did you make those particular software choices? I generally use whatever the client uses and given that I work with SQL Server I find that the majority of my clients use TFS, I guess simply because they are Microsoft development shops.
  • Any interesting anecdotes to share in regard to your use of source control and SQL Server? Not an anecdote as such but I am going to share some frustrations about TFS. In many ways TFS is a great product because it integrates many separate functions (source control, work item tracking, build agents) into one whole and I’m firmly of the opinion that that is a good thing if for no reason other than being able to associate your check-ins with a work-item. However, like many people there are aspects to TFS source control that annoy me day-in, day-out. Chief among them has to be the fact that it uses a file’s read-only property to determine if a file should be checked-out or not and, if it determines that it should, it will happily do that check-out on your behalf without you even asking it to. I didn’t realise how ridiculous this was until I first used SVN about three years ago – with SVN you make any changes you wish and then use your source control client to determine which files have changed and thus be checked-in; the notion of “check-out” doesn’t even exist. That sounds like a small thing but you don’t realise how liberating it is until you actually start working that way.

Hoping to hear some more anecdotes and opinions in the comments. Remember….free software is up for grabs!

@jamiet 

    Published Thursday, October 18, 2012 2:48 AM by jamiet

    Comment Notification

    If you would like to receive an email when updates are made to this post, please register here

    Subscribe to this post's comments using RSS

    Comments

     

    sqlbattsman said:

    Are you putting your SQL Server code into a source control system?

       Yes

    If so, what source control server software (e.g. TFS, Git, SVN, Mercurial, SourceSafe, Perforce) are you using?

       We're using TFS

    What source control client software are you using (e.g. TFS Team Explorer, Tortoise, Red Gate SQL Source Control, Red Gate SQL Connect, Git Bash, etc…)?  

       I'm currently using SSDT to maintain schema/database code in the form of database projects, and a Team Explorer connection from SSMS to maintain historical custom deployment/rollback scripts for production deployments.

    Why did you make those particular software choices?

       Primarily due to a being a Microsoft-based shop with existing TFS licensing.

    Any interesting anecdotes to share in regard to your use of source control and SQL Server?

       Jamie, I echo your comments about the benefits of TFS and things like the ability to associate check-ins with work-items, etc. One frustration I have with TFS is the inability to source control various reference data and have it ready to automatically deploy to a new instance of the database if needed.  It's much more complex to set up continuous integration and automated unit testing of apps and databases together without having that capability.  I haven't had the chance yet to run a trial of something like Red Gate's SQL Source Control, which I hear includes such features but it's definitely on my list.

    October 17, 2012 9:35 PM
     

    merrillaldrich said:

    Yes; TFS; Visual Studio Team System and SSMS with the TFS provider plugin, also the Windows Shell Extensions for TFS; system selection was dictated by my employer, but it works OK.

    We are not really a dev shop, per se, but add integration and sometimes tweaks to purchased systems. It makes the source control a bit unorthodox.

    The one thing I would love to know more about is the unique challenges of working with databases as source code - you can store scripts, but are they written as deployment scripts with all the logic about how to apply them to an existing DB? Where is that baseline DB? Where's the data? How does a team share the data and the code? It's a real challenge.

    I am also curious about the Red Gate product but have not had time to really look at it yet.

    October 17, 2012 9:36 PM
     

    Kent Chenery said:

    Are you putting your SQL Server code into a source control system?

    Yes!

    If so, what source control server software (e.g. TFS, Git, SVN, Mercurial, SourceSafe, Perforce) are you using?

    Git.

    What source control client software are you using (e.g. TFS Team Explorer, Tortoise, Red Gate SQL Source Control, Red Gate SQL Connect, Git Bash, etc…)?

    Git Extensions.  We're free to use any client software we choose to however.  But Git Extensions is well supported so I went with that.  Works for me.

    Why did you make those particular software choices?

    I didnt.  When I joined the company thats what was being used.  However, having now used it for a short while I would recommend it.  Being a distributed source control platform its great for distributed teams but also for trying something on a fork or branch and then ditching it if it doesn't work.  In fact, I started using it at home too.  I also like the fact there's no check-outs per se since everyone has their own copy of the source.  It spots file changes and then you check those in.

    Any interesting anecdotes to share in regard to your use of source control and SQL Server?

    SSDTs - always remember to do a Save All to ensure new objects are added to the project file.  Especially if you're using something like Git that doesn't bind too well to Visual Studio compared to something like TFS.  Not doing so can have some fun impacts on a merge.  Like your files suddenly dropping out of the project.

    October 17, 2012 10:05 PM
     

    Peter Schott said:

    Are you putting your SQL Server code into a source control system?

     Yes

    If so, what source control server software (e.g. TFS, Git, SVN, Mercurial, SourceSafe, Perforce) are you using?

     Git && GitHub

    What source control client software are you using (e.g. TFS Team Explorer, Tortoise, Red Gate SQL Source Control, Red Gate SQL Connect, Git Bash, etc…)?

     I mostly use SmartGit for Windows. I've used the Windows Git software, GitExtensions, and tried my hand at the shell, but SmartGit has been the best so far for me. (It does cost money, though. GitExtensions and the Git client are free.)

    Why did you make those particular software choices?

     It was chosen by a team looking at working offline more often so TFS was hard to justify. SmartGit was the Windows client chosen at the time as more full featured and it does have a great conflict resolution interface.

    Any interesting anecdotes to share in regard to your use of source control and SQL Server?

     Watch out for moving files around with Git - it doesn't track moves well.

     SSDT - Clear out the "variable" portion in DB references to use a DB Literal instead of a variable.

     SSDT - on importing a script with ALTER statements, be aware that you'll need to manually update the objects that you wanted to alter.

    @merrill - SSDT, DB Projects, and SQL Source Control all store their schemas as scripts. Data has to be handled differently - in MS solutions as pre/post deploy scripts. You'll want to make sure these can be re-run without the scripts having unintended consequences.  Red-Gate tends to take advantage of their Data Compare (an excellent product).  The baseline DB is whatever you make it in both scenarios. You'll usually want to have a good branching strategy to make changes and merge them into a master project that will represent what should be in production.  You can often set up a local SQL instance and keep those up to date through pushing that project locally once everyone starts at a given baseline.

    October 17, 2012 10:40 PM
     

    Anatoly Popov said:

    Are you putting your SQL Server code into a source control system?

    Yes.

    If so, what source control server software (e.g. TFS, Git, SVN, Mercurial, SourceSafe, Perforce) are you using?

    Perforce.

    What source control client software are you using (e.g. TFS Team Explorer, Tortoise, Red Gate SQL Source Control, Red Gate SQL Connect, Git Bash, etc…)?

    Perforce client: p4v.

    Why did you make those particular software choices?

    Perforce is main source control system in our company, so choice wasn't really a choice :)

    Any interesting anecdotes to share in regard to your use of source control and SQL Server?

    No :)

    October 18, 2012 12:13 AM
     

    Valentino Vranken said:

    Absolutely; TFS/Team Explorer.

    Why am I using those?  Same as you, all of my clients so far use TFS because usually they're a Microsoft shop...

    But... to really find out how many SQL devs are not using source control you're probably asking the wrong crowd.  Those who don't use it mostly don't even have an idea of what they're doing.  They've rolled into their IT position due to circumstances without any decent IT-related background. They rely on forums to get their task done, quick and dirty or not.  It's those people that don't use source control.  To version their software, in the best case they make a copy of their local project and put it on a share (which is hopefully backed up).

    Unfortunately most of those probably don't even know your blog, nor any other blog which would be a must-read for their position.  So they won't be responding here neither...

    Best regards :)

    @ValentinoV42

    October 18, 2012 6:03 AM
     

    SQLSophist said:

    •Are you putting your SQL Server code into a source control system?

    Yes, been doing this for years. I am aware that there are sites that don't do this though, they just rely on database backup...

    •If so, what source control server software (e.g. TFS, Git, SVN, Mercurial, SourceSafe, Perforce) are you using?

    Current client: TFS.

    •What source control client software are you using (e.g. TFS Team Explorer, Tortoise, Red Gate SQL Source Control, Red Gate SQL Connect, Git Bash, etc…)?

    Current client: Team explorer

    •Why did you make those particular software choices?

    On current client, this is a Microsoft shop, and that's what we use. We are also using team build (see below).

    •Any interesting anecdotes to share in regard to your use of source control and SQL Server?

    In general, I don't think the management overhead and licensing cost associated with TFS is worthwhile if all you're doing is using source control. To get value from TFS, at a minimum you need to be using team build, and possibly other stuff as well, such as the sharepoint integration.

    If that's all you need, then svn with Tortoise would be my first choice. If you want to add build automation later, you can do this with cruisecontrol (is it still called that?), JetBrains, etc.

    For a long time I thought that Redgate's claims about "bridging the SSMS-VS divide" were a load of hot air, since in my experience anyone who knew what they were doing was using Visual Studio, in particular SSDT and its predecessors.

    However, on a recent client I was putting in source control for the first time, and I discovered that the "divide" really does exist. That client has ended up using svn with Redgate SQL Source Control, with no build automation, but with scope to add it in the future.

    October 18, 2012 6:11 AM
     

    André Kamman said:

    We use TFS with Team Exlorer which is a departmental standard in our SQL Server shop, relying heavily on having to "check out" something since we store SSIS packages wich can't be merged. On our new project which is just around the corner we'll use 2012 so SSIS should be able to merge.

    We're going to give your branching tips from an earlier blog post a try... (and we're going to use build to do some automated testing on limited datasets etc. Continuous deployment is something we would love to do but our databases are 1TB+ and for us creating a meaningfull test harness without using real data is hard.)

    Regards,

    André

    October 18, 2012 6:57 AM
     

    Zahid Hanif said:

    •Are you putting your SQL Server code into a source control system? Yes

    •If so, what source control server software (e.g. TFS, Git, SVN, Mercurial, SourceSafe, Perforce) are you using? Perforce

    •What source control client software are you using (e.g. TFS Team Explorer, Tortoise, Red Gate SQL Source Control, Red Gate SQL Connect, Git Bash, etc…)? P4V

    •Why did you make those particular software choices? Used by the client

    •Any interesting anecdotes to share in regard to your use of source control and SQL Server? When clients tell me that their nightly backups are their Source Control. I ask them how long it takes to restore a stored procedure from the backup compared to how long it would take from a source control system.

    October 18, 2012 7:46 AM
     

    Nick said:

    * Are you putting your SQL Server code into a source control system?

    - Yes.

    *If so, what source control server software (e.g. TFS, Git, SVN,    Mercurial, SourceSafe, Perforce) are you using?

    - SVN

    *What source control client software are you using (e.g. TFS Team Explorer, Tortoise, Red Gate SQL Source Control, Red Gate SQL Connect, Git Bash, etc…)?

    - Specifically for SQL an older version of Red Gate SQL Source Control. Most of team has V1.x I have V2.x since I came in later.

    *Why did you make those particular software choices?

    - Were in use when I got here.

    *Any interesting anecdotes to share in regard to your use of source control and SQL Server?

    - I think putting the DB under source control is a great idea.  I have issues with the earlier versions of SQL Source Control in that it provides little help in versioning the DB. I think the latest version merges SQL Compare and SQL Source Control together.  Which is how it should have been all along. Sure I have the DB scripts in SVN, but I can't automate DB builds and changes without more tools.  Frankly I'm surprised databases don't have some sort of versioning built into them.

    @nportelli

    October 18, 2012 9:26 AM
     

    Chris Nelson said:

    •Are you putting your SQL Server code into a source control system?

    - Yes for current new projects, maybe for older code depending on it's use.

    •If so, what source control server software (e.g. TFS, Git, SVN, Mercurial, SourceSafe, Perforce) are you using?_  

    - Mercurial

    •What source control client software are you using (e.g. TFS Team Explorer, Tortoise, Red Gate SQL Source Control, Red Gate SQL Connect, Git Bash, etc…)?

    - TortoiseHG, VisualHG extensions to Visual Studio

    •Why did you make those particular software choices?

    - Mercurial is good quality, easy to use and better integration in Windows than git. Plus it's free and BitBucket has free hosting for repositories.

    •Any interesting anecdotes to share in regard to your use of source control and SQL Server?

    Source control in VS and other code editors is a lot easier than that in SSMS. Currently I want to have all my code in HG repositories, the SQL, the C#, the Python, and the PowerShell code, but maybe not my forthcoming blog.

    October 18, 2012 9:42 AM
     

    Steve Jones said:

    Thanks for the note, Jamie, and it's interesting, but I don't see any respondents that aren't using VSC. I'm guessing many people don't want to admit that.

    I use source control, sort of. I don't have a lot of production code, mostly demo stuff, which doesn't change so much as gets scrapped and restarted. However I am using Subversion (Turtle interface) with Red Gate's SQL Source Control (of course).

    Why? Well, since I have a 1:1 with my boss today, I should mention Red Gate makes a fantastic product that I couldn't do without. Actually I think I'm bound to use it since I work for Red gate, but even if I didn't, it makes things easier.

    I built this habit at a startup, with Visual SourceSafe, and 6 months of browbeating developers to actually check out code from VSS, do a File | Open in Enterprise Manager (SQL 2k at the time), make changes, save the code, and check it back in. It can be done manually, and should, but there are tools like Red Gate's products that make it easier.

    I know lots of people just edit code in SSMS/VS without controlling it, and that's a mistake if you are trying to work in a team environment, and product quality software. I haven't had to roll back often, but there are times we have needed to, and not having control was an issue.

    As an anecdote, I had a job once, waaaayyy back in the last century, using SQL 6.5. The developers had done a great job of using source control for all ASP, VB6, and SQL code. The problem was that they had checked out the code, saved it locally, copied it to another folder, and then checked it in. Then they might check back in the original script that was checked out. Or they might check the original back in and forget the modified version. Or they might not check anything in.

    We found 3, 4, even 7 copies of some stored procedures on various desktops and shared drives, and they had decided to encrypt all the code on the SQL Server. We were never quite sure what version was deployed where, and deployments of the "latest" versions from VSC broke functionality.

    We ended up decrypting all code, and reloading it into VCS, while removing all copies of local storage. It isn't enough just to use source control or implement something; you need to understand what you are doing and do it consistently. Tools help here, so please use something.

    October 18, 2012 10:58 AM
     

    Alan Dykes - twitter: @dykesa said:

    Are you putting your SQL Server code into a source control system?

       Yes - Everyone in my division has started using Source Control and we source control everything.  As I told them when we started migrating, if you don't source control it, its gone since we aren't backing up local dev boxes.

    If so, what source control server software (e.g. TFS, Git, SVN, Mercurial, SourceSafe, Perforce) are you using?

       We use TFS.  I don't care for the Visual Studio Admin "functionality", but otherwise its worked fine for us.

    What source control client software are you using (e.g. TFS Team Explorer, Tortoise, Red Gate SQL Source Control, Red Gate SQL Connect, Git Bash, etc…)?

       Red-Gate Source Control.  It is mostly fantastic.  It's extremely easy to use which is important for our setup.  I need some pharmacists to be able to use it and they don't have any issues with it.  The only things I don't care for are:

       1) You can't force a comment on check-in

       2) It requires the TFS user to have check in privileges to do a get-latest.  I really wish I could set up some repositories as read-only for users in TFS so they could get shared functionality/structures for their local dev setups without having the ability to change what is in there.  It hasn't been an issue but it makes me nervous.

    Any interesting anecdotes to share in regard to your use of source control and SQL Server?

       Source control has been immensely useful and saved me from a lot of rework on more than one occasion.  I have learned that you have to be extremely careful checking in data.  Our system is internal only so during the system production run once a week, if there is a problem that I can fix easily(for example, a control table points to a file in the wrong environment), I'll do it directly in production so the run can continue as soon as possible since we have a specified time window.  We do full test runs to minimize this but it has come up once or twice.  We use Red-Gate source control to "push" from the test environment to the production environment.  There have been a couple of occasions where the test environment with the wrong setting was pushed back over the production environment because the change was made only in production.  Gotta keep an eye on that.

    October 18, 2012 11:33 AM
     

    Cliff said:

    •Are you putting your SQL Server code into a source control system?

    Yes.

    •If so, what source control server software (e.g. TFS, Git, SVN, Mercurial, SourceSafe, Perforce) are you using?

    At my prior position, I used TFS or SVN depending on what system I was working on. My current position, we are using VSS due to a stalemate with the company that bought us out (we were going to move to TFS, they want us to use Serena Dimensions) so we remain in VSS 2005.

    •What source control client software are you using (e.g. TFS Team Explorer, Tortoise, Red Gate SQL Source Control, Red Gate SQL Connect, Git Bash, etc…)?

    With TFS, we checkout in/out from within Visual Studio (Data Dude) and I thought that worked out very well.

    Current position, with VSS, we check out from VSS manually and edit in SSMS. There has been encouragement from corporate to use Toad but I find that tool lacking for development and the source control is not exactly intuitive.

    •Why did you make those particular software choices?

    I didn't. My preference would be to use SSDT with TFS.

    •Any interesting anecdotes to share in regard to your use of source control and SQL Server?

    Not that I can think of. Everything is pretty routine.

    October 18, 2012 3:04 PM
     

    Alexander Kuznetsov said:

       Are you putting your SQL Server code into a source control system?  

    Yes

       If so, what source control server software (e.g. TFS, Git, SVN, Mercurial, SourceSafe, Perforce) are you using?

    Git

       What source control client software are you using (e.g. TFS Team Explorer, Tortoise, Red Gate SQL Source Control, Red Gate SQL Connect, Git Bash, etc…)?

    Git bash

       Why did you make those particular software choices?

    Of course, I wanted a third generation VCS. I tried it out and loved it. Linus Torvald's stellar reputation was a factor. Almost all my friends use git as well.

       Any interesting anecdotes to share in regard to your use of source control and SQL Server?

    Git is easy to use, lightning fast, and rock solid. As such, there is nothing interesting to share - it just works.

    October 18, 2012 10:32 PM
     

    MartinIsti said:

    Instead of giving answers I'd like to ask a question :o) I use source control only occasionally because I don't really develop databases but mainly SSIS and SSAS solutions and use TFS for that.

    But: nowadays I quite often have to write stored procs and I do that in SSMS (I tried Toad, Razor, etc but since most of our clients use purely SSMS and I develop via RDP that's something I can't really change). I so far have skipped putting them under SC mainly because I found the following tedious in SSDT when I tested it:

    1) opening SSDT, check out the sproc in the db project

    2) open SSMS do some changes, and test it! etc.

    3) check it back in SSDT to make sure I have a safe version

    4) check it out again in SSDT

    5) in SSMS do so more changes (it's usually iterative)

    6) check back again in SSDT

    ...

    I might just miss some point and it's possible that what I need is not a tool but a better approach :o) I don't really like switching back-and-forth between SSDT and SSMS (not to mention plain old BIDS that does not have the db project type).

    As far as I know RedGate's tool provides this functionality inside SSMS so it might suit my needs but I'm open to suggestions of how to do it more effectivly or what are the best practices regarding that!

    Thanks in advance!

    October 18, 2012 11:41 PM
     

    Koen Verbeeck said:

    I use TFS and Team Explorer, because my client says I have to :)

    Actually it's the same as Valentino, because we work on the same project.

    October 19, 2012 2:45 AM
     

    Peter Schott said:

    @Martin - one of the main reasons to store your schema in a version control system is to make sure that you can release a controlled set of changes as well as have the ability to roll those changes back. In your scenario, Red Gate may not be as helpful because you do most of your work through RDP.

    For SSDT, you may want to look at populating your "localdb" used in debugging with data and turning off the "rebuild database" option for debugging. That will let you test your code locally in the Debug instance without needing to leave SSDT. It _should_ also be tied directly to the files when you edit the code so you can make changes and start debugging pretty quickly.

    The process can feel a little tedious but you gain the ability to release a project that builds successfully (implying there are no very obvious errors), and can even stage those releases so you can move forward. Working in a VCS also means you can work on different branches so if there are sweeping changes coming up, you can still do a hotfix or minor enhancement to one branch without losing all of the changes or having to cherry-pick the changes you want to release.

    I probably would just go SSDT for projects (or Red-Gate if that's your preference). SSDT supports 2005+ at this point and is likely your best option. You can even work locally on changes, package them up, copy to the remote system, and release as a whole.

    I think you'll find that in the long run having a good process for working with these changes will save you a lot of grief when it comes time to release. I also think that your approach isn't necessarily a bad one, though I'd consider staging your changes instead of checking them in if you know they're not done.

    October 19, 2012 11:08 AM
     

    Mark Woodruff said:

    We're using SVN/Tortoise/Bugtracker.Net because they're free, work well in our environment, and can be customized to suite our needs. We would never use TFS, nor advise anyone to use it for three reasons:

    1) It ties you completely to Microsoft's development process.

    2) If Microsoft decides to get rid of it, or change it in ways that don't suit your business, as they have done with so many of their tools and technologies through the years, you're screwed because:

    3) Once installed, it's very difficult to get rid of and transfer to a different system while preserving your development history.

    There is one feature that should be in every source code control system, but which I've never found in any one. When you commit changes, it should look in all editors/tools that have an open file that has been changed, but not saved, and warn you.

    Oops. Done this more than once.

    October 21, 2012 6:51 PM
     

    Josh Luedeman @JoshLuedeman said:

    Are you putting your SQL Server code into a source control system?

    Unfortunately No. It wasn't setup when I arrived in this new role. I'm still evaluating between jumping on the current SVN used by our Software Engineering and SQL Source Control.

    If so, what source control server software (e.g. TFS, Git, SVN, Mercurial, SourceSafe, Perforce) are you using?

    None

    What source control client software are you using (e.g. TFS Team Explorer, Tortoise, Red Gate SQL Source Control, Red Gate SQL Connect, Git Bash, etc…)?

    None

    Why did you make those particular software choices?

    I've had some setup and performance issues to tackle before I looked at Source Control.

    Any interesting anecdotes to share in regard to your use of source control and SQL Server?

    I'm not the smartest guy for not focusing on source control as of yet.

    October 23, 2012 10:56 PM
     

    John Hennesey said:

    Are you putting your SQL Server code into a source control system?

    Yes - TFS.  Saved my butt more than once!

    What source control client software are you using?

    Team Explorer, TFS Shell extension (I LOVE this).  We have a VS 2010 DB Project for our stuff.

    Why did you make those particular software choices?

    I inherited it.  Ugh.  I would like to make it better but running as thin as we are I just don't have enough time.  There are a couple features I would *love* to have in VS - but that would squash innovation from great non MS companies.  *cough-cough, enter Red Gate* :)

    Any interesting anecdotes to share in regard to your use of source control and SQL Server?

    Goodness is it manual.  And can be extremely painful at times.  Not only are we running thin, we are constrained on the tools we can get ($$ must mean free).  Certainly no excuse, and a great opportunity to improve my skills by learning new things.  But...  Getting buy in a on a proven process or methodology is hard, takes time, and diverts us from development.  If SQL Source Control is easy to use and proven oh boy could you get some serious fans around here!  Seriously though, as the "accidental dba" of this shop any new ideas / easy to implement tools can make a world of difference in productivity and most importantly accuracy.  Manual = bad. :)

    Thank you for helping make our lives easier!

    JohnHennesey[@at][yahoo][dot][commmmmmm]

    October 30, 2012 12:31 PM
     

    Peter Schott said:

    John,

     I have a series going up on using SSDT for DB Version Control on my site @ http://schottsql.blogspot.com (bad name - horrible at those things). This is the upgrade to DB Projects in VS 2010 and is free - where VS2010 just includes the functionality. There are some pretty good upgrades within SSDT, though there are also some differences.

     I saw your response and thought that it might give you some ideas towards a little more automation. Of course, it doesn't do the built-in change tracking like SQL Source Control, but with some good management to keep track of the changes, it's not too bad. I set up a job to track changes to our shared dev environment and send out e-mails when something changes. That with some compares and it's not too bad to use.

    Anyway, hope you get some better control of your DB in VCS. We were on the "save a bunch of scripts in order" method. Hated it as it turned out we needed to cherry-pick changes out of those scripts to do most releases. Branching and merging our DB Projects has proven much more manageable.

    October 30, 2012 4:45 PM
     

    SSIS Junkie said:

    About a month ago I posed a question here on my blog SQL Server devs–what source control system do you

    November 21, 2012 4:28 AM
     

    bcse said:

    Hi

    I was quite intrigued by reading your post .  control systems are helping dewoloper make their life easier . I always look for new technological advancement in these areas as they interest me and i see the bright future in terms of development in such area.

    Thanks for this wonderful information

    www.bcse.co.in

    November 30, 2012 1:58 PM
     

    SSIS Junkie said:

    In my blog post SQL Server devs–what source control system do you use, if any? (answer and maybe win

    January 26, 2013 5:41 PM
     

    Aaron Reese said:

    Using Redgate Source Code 3 plugin into MSSql2008 connection to Mercurial

    Love it compared to the building generate script tasks because the scripts are clean (i.e. no created on memeo lines) so Mercurial sees them as different only if the actual DDL is different and you can save scripts to the repository or roll back the database to the repositry version from within mgm studio.

    We are Also storing SSIS packages in Mercurial.  This solution works best with the rest of the Redgate toolbelt.  SQL Compare and SQL Data compare are life-savers.  A script deployment for release took me all day to prepare.  SQL compare created a better script, with dependency order managaed and it remembers to update the views :) in less than 2 minutes.  Data compare similarly allows you to deploy reference data from DEV/TEST to UAT/PROD seamlessly.  Again these scripts and be Source code controlled if necessary.

    November 22, 2013 12:17 PM

    Leave a Comment

    (required) 
    (required) 
    Submit

    This Blog

    Syndication

    Powered by Community Server (Commercial Edition), by Telligent Systems
      Privacy Statement