Re: Prod and Dev environments/management

Jason, Thank you for your intelligent response. If I may prevail upon you (and any others competent/interested) I have interposed comments and more detailed questions, below:- > On Tue, Oct 09, 2001 at 07:34:22PM +0100, DL Neil wrote: > > Do you keep separate MySQL (et al) databases, eg dbOrders_Tst, > > dbOrders_Prd, or simply have differently named tables within one db, > > eg tblOrders_Tst, tblOrders_Prd? Once separated, when coding your > > PHP, how do you 'point' the script to the appropriate db/tables? > > The best way is to have a dev server and a production server. I don't > have that luxary either, so here is what I do. =I hear you about the luxury - but I think your scripts would work happily in cases of both penury and luxury! I keep separate > databases and keep separate include directories. =I have been keeping the separation/duplication at the table-level, if only because I could use my MySQL administration tool to make prod to dev/test copies or sub-set extracts with less keyboard-effort. The database-level seems more sensible to the 'management/safety' side of my brain; but I see no compelling reasons for one over the other. Do you? =I had not thought about separating include directories. At present, and again working at the 'lower level' of management, I copy/rename the include file: thus Req_MySQLv2.php reflects quite a different db/tbl structure than the ...v1.php code. Obviously the mainline PHP scripts in prod only know about the ...v1 include file, and the mainlines in dev/test only know about the ...v2. I haven't discovered any trick or trap 'the hard way' with this yet... My PC runs one Apache server, with multiple v-hosts. I hadn't twigged to the idea that I could have multiple Include directory specifications. I assume these are configured so that each v-host has its own IncludeDir? What advantages does keeping separate include directories offer? I also have two > scripts that help with all of this. The first one is the one I use to > backup my Mysql databases, and I also use it to restore them to test > databases. I simply prepend test_ to all of my databases... > ...mysql_backup.pl and golive.pl =thank you for this detail. I think the backup cron job was part of another discussion on this list recently. I know I cribbed something from it to improve my WinNT AT command/batch file. However I must admit that because my 'Prod' environment is only a 'copy', ie for attempting to reproduce reported errors etc (and is not supporting live transactions), I do not have to worry about 'operations issues'. Also, I tend to use a mySQL admin tool in 'manual mode' to copy back and forth - so I can 'cheat', ie taking 'snapshot' copies/extracts as/when needed. Your script has improved my cross-machine transfers! =The golive script is interesting. The script delivery mechanism and code amendment are neatly wrapped up together. I regret that my Perl knowledge derives only from PHP and my *nix mainly from a previous life working on Dec/Digital PDP and VAX machines (thus apologies if I'm not up with your play). Am I correct in interpreting the "s/test_nwdata/nwdata/g;" (etc) commands as opening the PHP script and performing a replace-all to rename any calls against the NWDATA database from test to 'prod'? That's neat! I can't immediately think how this might be achieved in WinNT/DOS, but I'll give it some thought. Does this mean that you face a minor drawback in the need to run a 'test' on the new prod environment because the files have effectively been 'edited' since system testing? (audit purists stand up and applaud...) =I have been tinkering with some code to examine PHP environment variables to pick up either the v-server or PHP script's directoryname (path), and thereby decide which database to point to. eg (in pseudo-code; and assuming the v-servers are appropriately named/set up) if ( v-server = "tst" ) use that as prefix elseif ( v-server = "prd" ) use that as prefix etc (NB deciding the default case may be an issue) mysql_select_db( prefix . "SiteIntegrity" ) or mysql_query( "select * from " . prefix . tblname ) =A similar alternative would be to use parameters (argc) but because they require (repeated) manual intervention, such doesn't seem appropriate. =Would you suggest that such a hard-coded solution has particular disadvantages compared to your script's translate-and-deliver method? =dn > > PS my personal dev env is NTWusS 4.0, PHP4, MySQL, and Apache