.htaccess and VirtualDocumentRoot

[apeisa]

Yesterday we worked on our server and deploy stuff. With one script we can create new site (from our demo profile or from any of our sites) with dev version also:

./new_site.sh www.example.com [www.copy-from-any-site.com]

that gives us:

www.example.com.pwire.fi (live)

www.example.com.pwire.fi:8080 (dev - will probably add some access restrictions here)

and after www.example.com resolves to our IP, then it would serve live site from there.

This will export & import database, copy files over to two places (dev & live folders), do some symlinking (assets files, wire), handle folder permissions etc. It takes two seconds to start building new site from any "profile" we want. I can share that script if anyone is interested here (after I have cleaned it a little bit)?

To make those domains work out of the box we added some Apache configuration so that we don't have to configure every vhost manually (but we can if we need some expections). We used Apache mod_vhost_alias to keep things simple: http://httpd.apache.org/docs/2.0/vhosts/mass.html | http://httpd.apache.org/docs/2.2/mod/mod_vhost_alias.html

Only thing that caused little problems here was that .htaccess was not working. After little googling we found solution: http://blog.justin.kelly.org.au/htaccess-and-apache-virtualdocumentroot

Not sure how this should be handled in PW default .htaccess file. Probably just comment for this option like it seems they have in Drupal: http://drupal.org/node/118569

[Adam Kiss]

Sounds awesome, but I'd really be much much much more interested in how you'll do the db syncing later, if I can ask?

[apeisa]

We don't. Dev and live uses same database. After the launch we'll do our dev work on live database and working with actual content. It has never been a big problem (quite a opposite, it has many benefits), but it might cause now more issues, since pw manipulates databases much more than our own cms.

But pw also fails silently (when I add new fields to templates, it doesn't matter at all if client "pre-populates" those before I have updated the template files). I am pretty sure that we won't go into db syncing at all.

[ryan]

Awesome setup Antti!

I'm adding that same comment to PW's htaccess that you mentioned from Drupal.

I would be a little worried about sharing the same DB. There are some things between the DB and the file system that need to be consistent. For instance, if you install a new module, upload a file, etc. It's possible for an exception to get thrown if something is out of whack. Though admittedly, I've not tried this sharing the same DB myself, so your experience may prove that it's an okay thing to do (just be really cautious).

One thing you can do is to copy your /site/config.php to /site/config-dev.php (on your dev server) and it'll use the config-dev.php instead. This makes it a little easier to maintain a separate live and dev config, and still be able to manipulate the live config from dev. And I could be wrong (?) but I think that MySQL db files can just be copied like any other file. So you could copy over the DB once a day with a cron job pretty easily, and avoid any problems sharing the same DB. But in my case, I just let the cron job dump on one server and import on the other as that's relatively simple too.

[apeisa]

I would be a little worried about sharing the same DB. There are some things between the DB and the file system that need to be consistent. For instance, if you install a new module, upload a file, etc. It's possible for an exception to get thrown if something is out of whack. Though admittedly, I've not tried this sharing the same DB myself, so your experience may prove that it's an okay thing to do (just be really cautious).

One thing you can do is to copy your /site/config.php to /site/config-dev.php (on your dev server) and it'll use the config-dev.php instead. This makes it a little easier to maintain a separate live and dev config, and still be able to manipulate the live config from dev. And I could be wrong (?) but I think that MySQL db files can just be copied like any other file. So you could copy over the DB once a day with a cron job pretty easily, and avoid any problems sharing the same DB. But in my case, I just let the cron job dump on one server and import on the other as that's relatively simple too.

Thanks for the info. Files won't be problem, since dev version have /assets/files/ folder as symlink, so dev site uses all the same files than live. What kind of problems there could be with module installs etc? I might even go with symlink route there as well if needed.

In your setup, you then build the db changes again when deploying? Or do somekind of partial import there?

[ryan]

On my dev, I use it primarily for testing stuff out before migrating to live. I don't deploy content or stuff from the database. Usually it's templates, stylesheets, modules or PW upgrades. Then if all is good, I'll mirror the changed files over (for template stuff ) or perform the same install/upgrade actions on live (for modules or PW upgrades). I don't keep the DBs all that up-to-date on my dev server, though I do have daily DB backups running (I just don't import them on my dev unless there is some change I need to test with).

I need to keep my dev server completely isolated from my live server so that they aren't sharing anything. If the two are sharing anything then, then technically you are working off the live server to some extent. If something goes haywire, it's feasible it could take down both your dev and live sites at the same time.

What kind of problems there could be with module installs etc?

If you install a module on your dev then it's in the DB and PW is expecting to find it on the file system too. If it's autoload, or if something calls upon it, and it's not there on live, I believe PW would throw an exception on your live server, taking it offline. You could solve this by symlinking your /site/modules/. But you don't have a real staging ground for modules unless you have an isolated database.

Another scenario. Lets say you upgrade PW on your dev server (or even some module), and that upgrade involves some change to the DB. The live site is now running an older version of PW on a newer version of the DB, possible data corruption ensues. While this isn't likely at the present time since we rarely change anything in the DB, it's not safe to assume that multiple versions of any CMS (or modules) would run properly off a different version of the database. You can solve this by symlinking the /wire/ dir, so that the DB and PW version are always consistent with each other (maybe you are already doing this).

Last scenario. You are now symlinking your /wire/ dir to avoid version mismatches between source and DB. You do a "git pull" to grab the latest PW commit. You are essentially committing this to live without testing. If there's a bug in the commit, you'll see it on both dev and live.

But then we're left with the only real difference between dev and live being /site/templates/ ... but that's an important one, and I can see the advantages there. For instance, you could create a new template and new page and have them work on your dev server while live still sees it as a non-viewable page (since there is no template file on live). Push the template to live and then all those pages start working–pretty cool. Maybe not much different than just creating it on live and keeping it unpublished until you are ready to publish it, but using the template lets you do multiple pages or a structure of them in one shot. It should also be reasonably safe to modify most templates on your dev server and be able to test them before migrating to live. A parse error in a template on dev won't affect the live site. Likewise, things like stylesheets, javascript and most front-end dev stuff–your current setup is a fine way to test this stuff out before migrating to live.

I'm sure there are other advantages too. But I guess I think that if using this route, you may want to consider another 100% isolated dev machine for doing your more in-depth template development, module development, and testing upgrades/commits or new modules before migrating to your dev-live. Basically all the back-end stuff. Then your current dev site could be kind of a intermediate option and place to work with front-end stuff.

[apeisa]

Great answer Ryan! Thank you.

For bigger changes it's same script and you have new copy of the exact same site where you can build and test freely (well, on same vps, but different db and folders - no any connections between the sites). Just copy the site you need to work into some temp domain (ie. ver2.example.com) and start building:

./new_site.sh ver2.example.com www.example.com

Wire is already symlinked. Although I might use dev side to test if site runs later version of pw without any problems. Only for minor and non DB upgrades of wire of course. I'm not sure yet how many pw versions I keep on server, currently I keep two: pw21stable and pw21head.

We will have good testing on before putting live sites here (probably goes to next year anyway) to see how sites behave. But the stuff where we use this dev environment is mainly templates, css and js. I don't believe doing any module development or anything like that on this setup - at least not with live sites. So "dev environment" is probably wrong term for this.

Also - I will have oneliner scripts to check status (are dev and live identical), update (files from dev => live) and to reset (from live => dev).

[ryan]

But the stuff where we use this dev environment is mainly templates, css and js.

It sounds like a great environment for this. Also amazing how convenient that script is, I'd definitely be interested in taking a look at it sometime.