John Corry wrote: > I am working on designing an documenting a process for our team to use to > manage code updates/changes. > > What we've been doing has been ghastly: a bunch of developers using > dreamweaver's 'check in/out' functions, all using the same FTP login, to FTP > files to the production server. > > It turns out the site we're working on together is a bit too complex for > this, so it's on me to come up with a better way. > > I'm a big fan of SVN and think we'll be light years ahead of where we are > presently by using SVN to manage code revisions. > > So, I've set up an SVN repository on our dedicated server and imported all > of the live-site code. Then I set up a dev virtual host (dev.domain.com) and > exported all of the code in my repository to that vhost's DocRoot. So...that > gave me a copy. Next, I copied the MySQL db to a separate db that we'll use > for the dev server...so dev code doesn't query the live db. Then of course, > I had to edit the config files that have DSN information in them to make > sure my dev site actually uses my dev db. > > Here's where the problems start to creep in... > > If I export the whole repository from SVN to the dev DocRoot directory, I'm > going to overwrite the config files that have DSN info in them. Similarly, > there are some javascript files that declare variables like var base_url = ' > http://mysite.com'...those variables need to be set once for the environment > (my local IDE? the dev server? the production server?) and then not messed > with afterward. > > After an SVN commit, it's really easy to svn export svn://localhost/mysite > /path/to/my/dev_server > > Simple, all of the code in the repository goes to the dev server. > > The issue I'm having is that there are a number of files that I do NOT want > to be copied from the repository to the dev server, except on > rare occasions. > > So, I can choose to add the files to my svn:ignore in my working copy so > they aren't committed/updated. But I can't ensure that all of the developers > take this step and it's not a reliable way to keep those select files in the > repository out of my dev server. > > Or, I can write a shell script that does the SVN export, then overwrites the > selected config files with master versions that are stored somewhere else > and not edited by any of the team. One problem with that though, is that our > main javascript file tends to be edited/changed and it's one that can create > problems if that base_url var isn't appropriate to the server it's on. > > Or, in all of my PHP files, I can write the config values into switch > statements: > switch($_SERVER['HTTP_HOST']) { > case 'mysite.local': > // local IDE config directives > case 'dev.mysite.com': > // dev server config directives > // etc... > } > > ...but that leaves the production server DSN sitting around in development > code, which I'd like to avoid, and I don't have an analogous solution for my > javascript files. > > JS question: is there a js way to do the same thing? Evaluate the js > equivalent of PHP's $_SERVER['HTTP_HOST']? If there is, I think this > solution will work. > > This has got to be a fairly typical workflow and problem. > > What are some of the strategies you folks use for designing your flow of > code from local IDE to SVN to dev server to production server? > personally I just use a switch and a couple of sh scripts to roll out; for the development environment I run the update-dev.sh script as an svn commit hook so dev is updated on every commit; for uat/live it's requires a manual run of ./update-live.sh (in reality i actually use phpUnderControl for continuous build automation and it only rolls out to live when a build/revision passes all unit tests). To deal with custom files per site; I keep all user submitted site-specific content in separate storage directories outside of the web root which solves half the problem; and for the remaining config/htaccess/cache files its just a case of using a few lines of bash script to ensure domain specific stuff isn't wiped out on roll-out. on the HTTP_HOST side of things I personally try to negate the use of domains in urls wherever possible opting for /path/to/file.js instead - but when it does creep up you can easily negotiate then by doing a simple string replace: define( 'DOMAIN' , 'clientsite.com' ); function u( $uri ) { return str_replace(DOMAIN, 'http://'.$_SERVER['HTTP_HOST'].'/', $uri); } echo u( 'http://clientsite.com/some-page/' ); and on the js side you could use document.domain or window.location.hostname or suchlike ps non of this is worth arguing over, just something to get you going and filed under "works for me" -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
