I am using SQL Server and Visual studio. I have an automatic build via CCNET. When I commit my code in SVN the automatic build runs and all unit tests runs with mocked/stubbed data.
The only thing that not goes automatic now is running the database changes/scripts, I do that by hand. Anybody got tips how this can be autometed?
Self evidently you need to automate running of your database change scripts - the challenge there being how do you decide what to run. The answer there is that you need to store the schema version in the database (or in the database metadata) and choose what scripts to run accordingly - whether that be to bring a database up from scratch or to apply appropriate changes.
My solution is to put my database schema maintenance entirely in code, I think this is the best version of the writeup I've done so far:
Given code smart enough to do upgrade the schema either in-line in your application or in its own console app you should be able to integrate automating schema changes into your CI build scripts.
I've been chasing around this a bit further since I wrote the above - it turns out that what I'm doing is not dissimilar to Ruby Migrations (I believe soemthing similar also features in Subsonic) excepting that I don't currently have any "down" capability to reverse a schema change (an interesting idea I have concerns with having potentially destructive code "live"). There is an open source .NET project Migrator.net that looks useful, but I'm not sure how actively its being maintained.
There are many ways you could tackle this one. An approach I have used in a number of companies I have documented here, basically it's source code to handle the task of automating your database updates and some explanations of the hows and whys.
I'd also recommend checking out Data Dude (just Google it), I haven't used it but my understanding is that it can be used to automate db updates (could be wrong).
I would say that I don't recommend using a database compare tool to generate scripts...without extreme care being taken. Problem is usually you'd compare your dev db (where your changes are) with say the build box db, but your db may contain (and likely will) other changes you have made for 'work in progress' bug fixes you may be working on.
Anyway like I said, there are many ways to do it, investigate a few options and pick the ones that best suits the style of you and your team.
Happy automating :-)