What about managing the script files themselves, keeping in mind that some scripts could be applied to more than one database version, like a database which is a branched version of another database, but which have common elements which can both be updated by a common script. Although sometimes a script would be unique to that database.
You're right about the tracking table. I used to use such a system at my last place of work which we used to store the date it was applied, the version, the developer and the description of the change. The added bonus of that is since I work for a web development company which has a company gateway, I could add version tracking information to that to show what has been released into each environment. Hmmm... I feel some ideas forming.
Thom
2008/12/11 Scott Marlowe
<scott.marlowe@gmail.com>On Thu, Dec 11, 2008 at 5:30 AM, Thom Brown <
thombrown@gmail.com> wrote:
> What do you folk think is the best way to manage deployments to databases?
> This would include things like table/view/function creations/changes and
> possibly static data changes.
in pgsql, and then make each update use that. You can get fancy if
you want, or just keep it simple. For instance:
create table chtrack (id int primary key, changename text, changedesc text);
Then in a file you can have:
begin;
insert into chtrack (id, changename, changedesc) Values (10,'schema
create','This change creates the initial db schema');
create table
etc...
commit;
If any of the script fails, the whole thing does and your db doesn't
change. Then you can create your new updates in a similar manner.