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:
How to create "embedded" SQL 2008 database file if it doesn't exist?
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 something 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.
Addendum
Since I wrote this entity framework code first has appeared and they're starting to make headway with migrations - so that would now be worth a look. However I don't think its quite there yet and like several other options I've seen its not simple. I need to package mine up and make it available!