How to do deployment for php application

Question

I am currently developing a php-application for a charity organization and I am now in the stage of defining the deployment practices.

Our application is using both Zend Framework and Doctrine. The application will be rolled out to different servers, each with a different configuration file. The machines are both Windows and Linux (but all with Apache and php 5.2+).

The source is available in a subversion repository and we want to build and store our packages on a Linux server.

Preferably we want the update process to be as easy as running an update command in the application directory, where the update command also updates the database (with the doctrine scripts) and ensures dependencies of the frameworks. This update command must be a command on the machine (we can't ssh into them). Preferably we have the option of downloading a new version or providing an already downloaded tarball with a new version. (but only downloading or only tarball is also ok)

The packages with installations and updates (new versions) are also preferably build by a single command.

I have been reading a bit about phar's, pear, phing but I have no clue what the best way to do this is. A continuous integration server is not really necessary, but I think about deploying test environments automatically after building a version.

Initially only the updating of the php app has to be very easy, filling initially a configuration file when installing can be done by hand.

Answer 1

I'd start by making the application root of the various servers an SVN working copy. You can add in mod_rewrite (or IIRF ASAPI filters for IIS) rules to ensure people can't address your .svn directories directly.

Then, updating to the latest source can be as simple as an SVN update. For your database update needs, I'd maintain the database modification scripts also in SVN. You'll likely need to wrap the SVN update in a batch/shell script in order to perform the database updates after the scripts are downloaded.

For change management on the live servers, I'd also have their working copies not of trunk, but a release branch. You can merge trunk into the release branch when you are ready for a release. This will allow you to test the deploy and make sure it's solid before performing it on the live servers. It also has the nice side-effect of giving you a nice replica of the site-release versions in case you need to track down issues post-launch.

Lastly, depending on the intensity and timing of these updates, you may also want to have your update script flip an "under maintenance" switch so that users are temporarily met with a proper message rather than a broken site.