TFS Integration Concerns

MartinUMartinU Posts: 14 Bronze 1
Some things that I think are a bit disconnected between SSC and TFS working in a dedicated database environment.

1) When you modify an object on your dedicated dev database and SSC marks it as edited it does not actually check out the script or file in Source Control. In return, you cannot use the shelve feature of tfs if you wanted to because your files are not actually checked out anywhere.

2) When you modify an object on your dedicated dev database and the file (object) is different in source control it does not automatically load the latest version of that object.

I think the biggest problem I see here is SSC is storing the resulting script files directly to TFS server rather than checking out the files on the server, updating them locally and then committing them to Source Control when checked in.

Comments

  • Hi,

    We've had a fair number of requests, predominantly from TFS users, to support the check-out model of source control. The model that SQL Source Control has adopted is more akin to that of Subversion, where you modify objects without checking them out, and only upon commit are conflicts considered. The reason we chose this is not only because of its simplicity, but because unless we instrument dedicated databases with DDL triggers, there's no way we can prevent a user changing their database even if another user has taken a lock in TFS. What we hope to do in future is to provide more information on who is actively changing which object, so although we can't prevent users changing the 'same' objects at the same time, we can warn them when they start doing it.

    Your suggestion to get the latest version of an object on edit is a nice option we could also add in future. Please suggest or vote for any ideas you have on our uservoice forum. http://redgate.uservoice.com/forums/390 ... ce-control

    I hope my explanation makes sense. If not, let me know.

    Thanks for the feedback,

    David Atkinson
    Product Manager
    Red Gate
    David Atkinson
    Product Manager
    Redgate Software
  • MartinUMartinU Posts: 14 Bronze 1
    Thanks David. While I was researching and doing some additional testing of SSC I came across SQL Connect preview. To be honest I think this is the turning point for SQL Source Control in a positive way. Once static data scripts, pre and post deployment scripts are incorporated with sql connect it will be the go to product for TFS users with teams of developers working in sql.
  • Indeed. Not TFS users specifically, but anyone who prefers to develop their SQL in Visual Studio.

    However, if you plan to engage in 'connected development', where you modify a real development database linked to your source controlled database, you could still get into a situation whereby User A has checked out an object, and User B unknowingly modifies the same object on their connected database causing a conflict when they eventually try to push their changes down to the project and check them in. If this becomes an issue, we'll have to consider implementing the DDL-Trigger-based solution, or come up with another solution.

    Out of interest, what would you like to see in pre/post-deployment scripts?

    David
    David Atkinson
    Product Manager
    Redgate Software
  • MartinUMartinU Posts: 14 Bronze 1
    I think the current process with SQL connect works great in regards to check-ins and check-outs. At this point in time I think two key items would be:

    1) Ability to execute static data scripts when synchronizing. Should be optional.
    2) Ability to perform an actual merge when conflicts arise.

    There may be other things but in regards to our teams and development process this is what we would have expected the VS DB projects to be where we can develop in VS or on our local and quickly and easily move things back and forth. The speed and the fact that it mimics how items are scripted from SSMS is ideal. Where things on a table level such as triggers are part of the table script and not a separate object in the solution somewhere is key as well.
  • MartinUMartinU Posts: 14 Bronze 1
    I guess one other thing but I believe this was already posted by someone on the feedback and that is the ability to synchronize a single object, project, or entire solution.
  • If you mean synchronizing the RG project to the connected database, the current behavior in SQL Connect is to synchronize all objects in the project.

    I'm not sure what happens if you have more than one RG project in a solution. I guess the sync should only apply to the project, but I don't see why this couldn't also be an option at solution level if you were to have multiple RG projects under it. Please post these requests on the SQL Connect UserVoice site!

    http://redgate.uservoice.com/forums/140 ... ilters/new

    Regarding the merging, SQL Connect just leverages your current VS TFS integration, it should 'just work'.

    David
    David Atkinson
    Product Manager
    Redgate Software
  • MartinUMartinU Posts: 14 Bronze 1
    David I will make sure to get these things into the user voice pages.

    Could you do one last thing for me and point me to a resource or a quick write up of how SQL Connect and SQL Source Control work together?

    I understand SQL Connect is still in beta but if we were to work on a long term plan with our current SQL Source Control 3 rollout, how and where does SQL Connect play into that plan.

    I have been doing some testing with SQL Source Control 3 and the SQL Connect plugin and can kinda see where each one fits in but I am curious as the direction that Red Gate is going with SQL Connect.

    If there is another method or location where these types of communications should occur please let me know.
  • Just an update - this conversation continued via phone/email - if you're interested in the topic please do post below or contact sqlconnect@red-gate.com
  • MartinUMartinU Posts: 14 Bronze 1
    Michael it was a pleasure speaking with you. As I indicated on the call I believe SQL Connect will be the next huge success for Red-Gate. I was very excited when I stumbled upon it as it is the true replacement for the standard MS DB projects in my opinion. I look forward to providing great feedback and will encourage the same with my colleagues.
Sign In or Register to comment.