PHP Site Deployment Suggestion [closed]

Answer 1

Use a deployment framework like Phing to manage deployment to the webservers and get rid of the cron job. Basically, a release on the production system should not happen automatically, but only after you are certain the current build is not broken. And it should not have a dependency on the dev system.

Since Phing uses XML and PHP to configure and control the deployment process, you can version control the process. This is an added benefit, as you can then keep the deployment connected to specific builds of your application.

To prevent the production website from being affected by the deployment process, consider uploading a new build into a separate directory and then just symlink to it. If anything goes wrong, you can easily symlink to a previous version.

Also consider using a CI server.

Answer 2

As a partial fix, create a URL on the web site that triggers the rsync command when you visit it, so that you can control when rsync runs (obviously, you need to make sure to hit server 1 with this URL and not expose this URL to the public). Better still, use curl to invoke the rsync URL at the end of whatever upload script you use.

Answer 3

I did the same thing at my last place. What we had was:

• a repository per website
• a branch for each website dedicated to the live site (i.e. /branches/live) and test site (i.e. /branches/testing)
• 2 webservers which could talk to SVN
• a test server which could talk to SVN
• all servers had SVN command-line client installed

Each webserver operated independently, so they didn't really know about each other - that was left to the load balancer. Each server had a cronjob that ran every 3 hours and exported the latest version of each website's live branch into the correct folder on the file system.

On our test server, it was a checkout of the testing branch for each website, and no cronjob. Developers updated the folders whenever they wanted to put something out for users to test before it went live.

During developments, commits were made to the trunk of the website. When changes were ready for testing, they were merged into the testing branch and the checkout updated manually on the test server. When changes were ready to go live, they were merged to the live branch and the servers would have updated by the end of the day.

In 3 years we only had one issue where a developer had committed something incorrectly and had to roll the site back.