Another option is to have the schema creation/upgrade as scripts (either hand made or autogenerated ) , then check them into source control.
And resist the temptation of hacking the schema directly in your servers, it ends being a larger effort :)
And resist the temptation of hacking the schema directly in your servers, it ends being a larger effort :)
Each change is stored as a script which have names like "<timestamp>_<brief description>.sql", and the timestamps serve as IDs as well in the "changelog" table in the DB. Creating the changelog table is always the first change.
The "migrate" command of the tool then has options for "status", "up" "down" etc., and features to create scripts to go from v1 -> v2. Another nice concept they provide to the mix is adding an "Undo" section to each script so that you can rollback changes and downgrade schemas just as easily as upgrading them.
Nowadays I'm primarly working with non-relational datastores where this seems to be much less of an issue. There we version the entities that we store instead of a schema and that is done entirely in source control as well.