TFS Organization Opinions
Hello,
I wanted to see other people's opinion of how to organize your source code in TFS.
So, a simple breakdown. We have the organize the following code:
1. ASP.NET project
2. SQL Server Database Project
3. SQL files: Stored procedures, scripts, functions
4. SQL Server Reporting Services reports
Do you organize your sql files with your database project in TFS?
Do you organize your sql files with your reports project in TFS?
Or do you organize you sql files with your ASP.NET C# project (considering those sql files are only called from that ASP.NET C# project)?
Thanks for any opinions...
I wanted to see other people's opinion of how to organize your source code in TFS.
So, a simple breakdown. We have the organize the following code:
1. ASP.NET project
2. SQL Server Database Project
3. SQL files: Stored procedures, scripts, functions
4. SQL Server Reporting Services reports
Do you organize your sql files with your database project in TFS?
Do you organize your sql files with your reports project in TFS?
Or do you organize you sql files with your ASP.NET C# project (considering those sql files are only called from that ASP.NET C# project)?
Thanks for any opinions...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
In storing sql files in with the db vs. a visual studio project, what happens if you want to rebuild the db from all your source control files? You would need to hunt for all those files scattered in all different projects to build the db accurately.
If you keep the sql files with the db project, you wont have that problem.
I guess I'm looking for pro's & con's, but as you mention, it may be preference.
Another example would be, what happens if you need rename a column in your database or change its datatype. If you stored your sql scripts with projects you would need to then search for all scripts/sp's that use that field in the projects, whereas if you keep the sql files with the db, they are all in 1 easy to find project.
I'm looking for other scenario's, like these if possible.
Thanks...
If you keep the sql files with the db project, you wont have that problem.
I guess I'm looking for pro's & con's, but as you mention, it may be preference.
Another example would be, what happens if you need rename a column in your database or change its datatype. If you stored your sql scripts with projects you would need to then search for all scripts/sp's that use that field in the projects, whereas if you keep the sql files with the db, they are all in 1 easy to find project.
I'm looking for other scenario's, like these if possible.
Thanks...
When I was using SQL Server Database Projects, those would go in a top-level folder, since they really don't need to be in a project-specific folder, buried somewhere deep in the hierarchy (as you described). You are right, that there are a lot of script files generated for a database, and being able to find those easily is usually paramount in our jobs.
Do you generate test data, and use database unit tests? Those usually need to go with the project, but that would be personal preference.
Do you generate test data, and use database unit tests? Those usually need to go with the project, but that would be personal preference.
ASKER
Thanks for the opinions...
Provide build configuration dependencies in TFS Build
http://visualstudio.uservoice.com/forums/121579-visual-studio/category/30925-team-foundation-server
http://www.devproconnections.com/article/visual-studio-2011/tfs-2012-143104