PHP Site Deployment Suggestion [closed]

Question

I'm currently quite troubled by the way of deployment my team is adopting... It's very old-fashioned and I know it doesn't work very well. But I don't exactly know how to change it, so please give some suggestions about it...

Here is our current setup:

• 2 webservers
• 1 database server
• 1 test server

Current deployment adaptation

1. We develop and work on the test server, every changes is uploaded manually to the test server.
2. When a change or feature is complete, we then commit the changes to SVN repository.
3. After committing the changes, we then upload our changes to the first webserver, where there will be a cronjob running every minute to sync the files between the servers.

Something very annoying is, whenever we upload a file just as the syncing job starts, the file that is sync-ed will appear corrupted, since it is only half-uploaded. Another thing is whenever there is a deployment fault, it will be extremely difficult to revert. These are basically the problem I'm facing, what should I do?

In addition, since there are files on the 1st webserver which needs to be sync-ed to the other servers anytime, so the cronjob was there for the reason.

P/S: I'm sorry I forgot to mention that, the SVN server is hosted. We don't have too much control over it, but I believe I can edit hooks...

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

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.