Geeks With Blogs
ken spencer

This morning I was working on a client application after I made my last post on Ben’s article about shared databases.

So, I went to check in my code. TFS build ran a bit and then rejected it. The services layer was throwing an exception. Took a bit to track down the exception occurred in the database call to a sproc. So, what was going on?

Turns out someone changed a sproc in the shared database. So when my code checked in the unit tests failed.

Perfect example of the evil of a shared development database. If the developer had used a local dev database, they would have caught this error when their code was checked in and the build / unit tests ran. Instead the sproc is sitting out there for all of the folks on the team and all of the users testing the application to find the problem.

Posted on Tuesday, January 25, 2011 10:41 AM | Back to top


Comments on this post: Shared databases again

# re: Shared databases again
Requesting Gravatar...
If you're looking for a tool to help with private dev databases, here's what my team is using internally. One of our devs wrote it. Feel free to email if you have any questions.

http://tsqlmigrations.codeplex.com/

Here's some additional resources.

http://geekswithblogs.net/wesm/archive/2010/03/04/database-version-control-resources.aspx

I have to admit I'm not really familiar with the VS DB projects mentioned in Ben's article so I can't really provide a comparison. However I will note that TSqlMigrations works great for bringing an existing database under version control. I make all my changes by scripting them out in SSMS and then applying them with the tool.

Cheers!
Left by Ryan on Jan 26, 2011 12:10 AM

Your comment:
 (will show your gravatar)


Copyright © xamlnotes | Powered by: GeeksWithBlogs.net