Having site under version control (Both DB and code)

Replies to This Discussion

Permalink Reply by Wilco Jansen on December 10, 2009 at 4:37pm

That is the way we implemented Moovur, it is basically managed by SVN. We work in a branch (even DB scheme), and when we are happy, we merge back and the site is automatically deployed. And it is not even that difficult to set up.

Permalink Reply by Ercan Özkaya on December 10, 2009 at 5:06pm

Yes it doesn't take that much time.

A question: How should configuration.php be handled? If it's in the repository, developers will need to update it for their local copies and it can be committed by mistake.

Permalink Reply by Arlen Walker on December 10, 2009 at 5:13pm

I tend to use capistrano for deploy, but that's ruby-based, and you might have some issues with that.

It looks like your system will work (don't have much experience with phing so I can't comment on it). Here are some alternatives to think about (they aren't so much "better ways" as "different ways"):

Live site is in a subdirectory that is set to be document root for apache. Can be called anything, I'll refer to it as "current". There will also be a directory tree of x other copies, each directory named with a version number or a date. The "current" directory is a symlink to the most recent of those. (Using a symlink makes it easy to quickly roll back to a previous working version. Keep the last x versions on the site.) Your "deploy" script does the checkout to a new version and as a final step, replaces the symlink with the newest version.

Use a checkout instead of a clone. If you want to use clone, remember the --depth switch.

Don't forget to build scripts to roll back the db changes as well as make them.

Permalink Reply by Rick Blalock on December 11, 2009 at 8:00am

You can always ignore the configuration.php, thus allowing each user to have their own configuration.php file and plus it keeps it from being committed.

Permalink Reply by Oleg Nesterov on December 12, 2009 at 2:07pm

As far as I know, you can't ignore the file that you've checked out from the repository. I had the same question some time ago and didn't find the right solution. So I still check each time to prevent some "configuration" file to be committed.

Permalink Reply by Ercan Özkaya on December 13, 2009 at 9:15am

@Arlen, what do you mean by checkout instead of clone? I didn't understand that. I read about this symlinking structure somewhere else. Tags can also be an option there maybe.

It also looks like dbdeploy in phing does not have rollback capabilities. I'll need to rewrite some of it.

For configuration.php I'm thinking of adding a configuration.custom.php as ignored file and then merging this file, if present, in configuration.php. So developers can create this file and enter their own database credential. Not a brilliant idea, but it seems to work.