<p>As you develop an application database changes inevitably pop up.  The trick I find is keeping your database build in step with your code.  In the past I have added a build step that executed SQL scripts against the target database but that is dangerous in so much as you could inadvertanly add bogus data or worse.  </p>

<p>My question is what are the tips and tricks to keep the database in step with the code?  What about when you roll back the code?  Branching?</p>

Version numbers embedded in the database are helpful.  You have two choices, embedding values into a table (allows versioning multiple items) that can be queried, or having an explictly named object (such as a table or somesuch) you can test for.
When you release to production, do you have a rollback plan in the event of unexpected catastrophe?  If you do, is it the application of a schema rollback script?  Use your rollback script to rollback the database to a previous code version.