Stairway to Database Source Control Level 1: Setting Up For Database Source Control

  • Comments posted to this topic are about the item Stairway to Database Source Control Level 1: Setting Up For Database Source Control

  • We are a SQL Server\Visual Studio\TFS shop and I am searching for a DB source control guide using these tools. I'm curious as to why TFS is excluded from your articles.

    Is this because it doesn't work very well or because I haven't searched hard enough and a guide already exists?

    I'm sure I'll be able to work something out from your series anyway. I await further articles with anticipation!

  • Hi Nick,

    Thank you for your kind comments. I am starting with version control systems which have been about for a while on the application development side, and are freely availably for adoption; these are the tools with which the most developers who don't use source control for databases will be familiar. I wanted to clearly show the different approaches and implications of the types of system side by side, as generally these principles translate across types of system (for example, TFS and SVN are both centralised VCS systems, whereas GIT for example is a distributed system).

    I use TFS and SSDT in some of my day to day work, and I would note that the current versions, if used properly integrated with a developer team, can be of even greater benefit in terms of adding code review and workflow management into the development IDE; however this additional functionality is somewhat outside of the scope of this stairway.

    TFS can be used with Red Gate SQL Source Control (and using manual file-based methods), so you should be able to follow along with the series, and put your databases into source control using the same methods.

    Good luck, I hope you enjoy the series, and please do reach out to me either here or on twitter (@d_a_green) if you'd like more help with TFS.

  • Good opening article and I look forward to the rest of the stairway. I'm in the process of trying to get my current workplace to get databases in to source control (TFS) and evaluating SSDT vs. SQL Source Control vs. SSDT & SQL Source Control. The key thing is to get things into source control and get all the people doing database work to work within source control.

  • Jack Corbett (4/24/2014)


    Good opening article and I look forward to the rest of the stairway. I'm in the process of trying to get my current workplace to get databases in to source control (TFS) and evaluating SSDT vs. SQL Source Control vs. SSDT & SQL Source Control. The key thing is to get things into source control and get all the people doing database work to work within source control.

    I'm in a similar position to you, Jack and have just signed up for a 'TFS Online' account - essentially Source Control in the Cloud. Will be interesting to see how I get on.

    Regards

    Lempster

  • This is something the organization that I'm in doesn't do. The source code is in source control, but not the database and all the components within, tables, stored procedures, etc. It should be. At other places, the database along with reference data were also kept in source control.

  • We have a UAT and PROD DB and as developers we modify the UAT environment directly. Then script out any changes for PROD.

    We did request a copy of Redgate Source Control as this offered an out of the box solution to this development flow. However it was denied as it was not within policy.

    Any recommendations on how I can get my team of developers to easily adopt source control?

    Here are the hurdles I'm dealing with: cannot use 3rd party tools, cannot have local development servers, need to use SVN (tortoiseSVN is our client)

  • nick.latocha (2/3/2016)


    We have a UAT and PROD DB and as developers we modify the UAT environment directly. Then script out any changes for PROD.

    We did request a copy of Redgate Source Control as this offered an out of the box solution to this development flow. However it was denied as it was not within policy.

    Any recommendations on how I can get my team of developers to easily adopt source control?

    Here are the hurdles I'm dealing with: cannot use 3rd party tools, cannot have local development servers, need to use SVN (tortoiseSVN is our client)

    I recommend using SSDT database projects. SSDT is a free download in the VS shell. I've used RocketSVN which was a free add-in for VS to connect to the SVN server, there is also the AnkhSVN add-in[/url] that is still free that I tried.

  • Thanks Jack.

    Will SSDT sync the local project and the physical database automatically? My devs make changes direct to DB in our dev/uat env.

  • nick.latocha (2/4/2016)


    Thanks Jack.

    Will SSDT sync the local project and the physical database automatically? My devs make changes direct to DB in our dev/uat env.

    Depends on what you mean by automatically. There is no connection between the database and the project and no SSMS add-in like SQL Source Control has to indicate when the database and project differ. There is the ability to do a schema compare in SSDT between the database and the project and update the project "automatically". This is how I worked when I first started with database projects. I never automated the process but I believe you could automate the schema compare and project update if you wanted to, but then you wouldn't get check-in comments and might get incomplete code.

    In my opinion the best way to work with database projects is to make changes in the project first and push out to a dev environment. You can unit test in the environment using LocalDB (kind of like Express edition, but included in the SSDT install).

Viewing 10 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply