Rob Kinyon wrote:
On Fri, Sep 9, 2011 at 11:30, Alan Humphrey <[email protected]> wrote:
Hi –
I’m wondering how people are handling connecting to different databases,
e.g. dev vs. test vs. production. Is there a technique that’s considered
“best practice”?
Configuration files are good things. Just swap in the right config
file for a given environment.
Rob
I'd like to +1 config files for handling things like this, and follow up
with a config scheme that I've used; try it out, adapt, etc...
I'm very conservative with what I put in MyApp.pm. Any config here is
rarely if ever changed; so, I think of its config more as constants. If
it is changed, I refactor it out to...
myapp.conf contains default dev environment values. A dev who checks
out this project could start it up with little to no config changes.
The project contains a myapp_local.conf.sample file that is nearly
identical to myapp.conf. However, most values are blank or are "hint
values" like /path/to/foo. All lines are commented out. A dev, tester,
IT person, deployer, etc. copies this file to myapp_local.conf,
uncomments and sets values appropriately for the environment. A dev may
use it simply to swap out which DB she's pointing to when she needs to
work against a different data set.
No myapp_local.conf is committed with the project code in this scheme,
so the project can be deployed (and updated) without smashing the
existing local conf. Any updates to the conf are noted in a
RELEASE_NOTES file that is consulted during deployment (planning).
I hope this gives you some config management ideas to play around with.
Cheers,
--Trevor
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[email protected]
