Agree with fluteplr - this is a wonderful product, I couldn't live without it and it is not expensive! You do have to be careful what order you run the scripts. If you put them all in one change script and run it, it may fail if you have a stored procedure that uses a table change that is also in the same script. I usually do all the table changes, then all the views, then all the stored procedures. And the nice thing is you can pick which items you want to script, so that you don't have to move items you know production doesn't need (such as procedures that are in the process of being modified or which relate to parts of the user interface you are not ready to move to prodcution). ALso, if you mess up something in development it is easy to move the old version back from production too.
It will show you which items are the same which items are in one database but not the other and which are different beteween the two databases. ANd you can view the changes to see if you really want to script them at this time. Often, I find at least one item that surprises me and then I check the change to make sure it is appropriate to move at this time.