Обсуждение: Database config managment
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.
Any good solutions out there?
Thanks
Thom
Any good solutions out there?
Thanks
Thom
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. The easiest way I've found to do it is to create a changetrack table 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.
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
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:The easiest way I've found to do it is to create a changetrack table
> 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.
On Fri, Dec 12, 2008 at 1:51 PM, Thom Brown <thombrown@gmail.com> wrote: > 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. I'd use a branched svn / cvs type setup. And upgrade scripts that take you from branch to another (or trunk to a new branch, whichever you'd be doing.)