Options
Tfs or Tfs + RedGate Source Control
Morris
Posts: 1 New member
Hello All -
I have to bring a large application in house on a short timeline and am thinking about utilizing RedGate Source Control with tfs and would like input form others who are more experienced than I in this realm. We will initially have three environments that we will push code through. This is a .Net application that is very back-end heavy...anything that can be handled in SQL is. There are 1000's of complex procedures that drive various processes across several databases. Some of these processes include edi file consumption and intricate workflows. Some tables have 25+ million rows. There will be frequent low level schema changes to the databases as new modules are developed on the front-end and back-end processes change. We will have several developers working with the code.
We we will be using tfs for the application but I was thinking given the complexity of the back-end configuration, leveraging RedGate source control could have added value that we may otherwise miss out on with tfs alone. My initial thoughts are that RG will facilitate the build and deployment process, and versioning will be more granular, but I would like to hear from others who have implemented a similar solution. What did you like and what was problematic?
Thank you!
I have to bring a large application in house on a short timeline and am thinking about utilizing RedGate Source Control with tfs and would like input form others who are more experienced than I in this realm. We will initially have three environments that we will push code through. This is a .Net application that is very back-end heavy...anything that can be handled in SQL is. There are 1000's of complex procedures that drive various processes across several databases. Some of these processes include edi file consumption and intricate workflows. Some tables have 25+ million rows. There will be frequent low level schema changes to the databases as new modules are developed on the front-end and back-end processes change. We will have several developers working with the code.
We we will be using tfs for the application but I was thinking given the complexity of the back-end configuration, leveraging RedGate source control could have added value that we may otherwise miss out on with tfs alone. My initial thoughts are that RG will facilitate the build and deployment process, and versioning will be more granular, but I would like to hear from others who have implemented a similar solution. What did you like and what was problematic?
Thank you!
Tagged:
Answers
@Morris, We use TFS + SOC where I work and it is very helpful. It streamlines the tedious tasks of generating and checking in objects. It also helps in identifying objects that have changed. One thing that I would strongly suggest is using the 'Dedicated' model for source control. The 'shared' model seems simple, but it really only works well with very few developers or if code is handled in silos between developers (ie Bob only changes certain tables/procs, Erin only works on other certain tables/procs, and neither Bob or Erin work on the same stuff at the same time). Dedicated does mean you have to figure out how to provide your developers with SQL Server instances, either locally on the developer workstations or somewhere else (server, cloud, etc), but you can generally get that figured out with the Developer Edition of SQL Server for local installs. It's worth it in the long run by not having to worry about people changing the same objects at the same time with different changes. You will really want to understanding branching/merging/conflict resolution as that is a somewhat difficult task, but I can't say if it is better or worse than without SOC. Either way they happen, it just depends on how you coordinate the communication within your team to resolve the changes.