How to get started deploying PHP applications from

Question

I've heard the phrase "deploying applications" which sounds much better/easier/more reliable than uploading individual changed files to a server, but I don't know where to begin.

I have a Zend Framework application that is under version control (in a Subversion repository). How do I go about "deploying" my application? What should I do if I have an "uploads" directory that I don't want to overwrite?

I host my application through a third party, so I don't know much other than FTP. If any of this involves logging into my server, please explain the process.

Answer 1

At my webdev company we recently started using Webistrano, which is a Web GUI to the popular Capistrano tool.

We wanted an easy to use, fast deployment tool with a centralized interface, accountability (who deployed which version), rollback to previous versions and preferably free. Capistrano is well-known as a deployment tool for Ruby on Rails applications, but not centralized and targeted mainly to Rails apps. Webistrano enhances it with a GUI, accountability, and adds basic support for PHP deployment (use the 'pure file' project type).

Webistrano is itself a Ruby on Rails app, that you install on a development or staging server. You add a project for each of your websites. To each project you add stages, such as Prod and Dev.

Each stage can have different servers to deploy to, and different settings. Write (or modify) a 'recipe', which is a ruby script that tells capistrano what to do. In our case I just used the supplied recipe and added a command to create a symlink to a shared uploads dir, just like you mentioned.

When you click Deploy, Webistrano SSHs into your remote server(s), does an svn checkout of the code, and any other tasks that you require such as database migrations, symlinking or cleanup of previous versions. All this can be tweaked of course, after all, it's simply scripted.

We're very happy with it, but it took me a few days to learn and set up, especially since I wasn't familiar with Ruby and Rails. Still, I can highly recommend it for production use in small and medium companies, since it's proven very reliable, flexible and has saved us many times the initial investment. Not only by speeding up deployments, but also by reducing mistakes/accidents.

Answer 2

After 3 years, I've learned a bit about deployment best practices. I currently use a tool called Capistrano because it's easy to set up and use, and it nicely handles a lot of defaults.

The basics of an automated deployment process goes like this:

1. Your code is ready for production, so it is tagged with the version of the release: v1.0.0
2. Assuming you've already configured your deployment script, you run your script, specifying the tag you just created.

3. The script SSH's over to your production server which has the following directory structure:

   /your-application
       /shared/
           /logs
           /uploads
       /releases/
           /20120917120000
           /20120918120000  <-- latest release of your app
               /app
               /config
               /public
               ...etc
       /current --> symlink to latest release
   
   Your Apache document root should be set to /your-application/current/public
   

4. The script creates a new directory in the releases directory with the current datetime. Inside that directory, your code is updated to the tag you specified.

5. Then the original symlink is removed and a new symlink is created, pointing to the latest release.

Things that need to be kept between releases goes in the shared directory, and symlinks are created to those shared directories.

Answer 3

This sort of thing is what you would call "Continous Integration". Atlassian Bamboo (cost), Sun Hudson (free) and Cruise Control (free) are all popular options (in order of my preference) and have support to handle PHPUnit output (because PHPUnit support JUnit output).

The deployment stuff can be done with a post build trigger. Like some other people on this thread, I would exercise great caution before doing automated deployments on checkin (and test passing).

Answer 4

Automatic deploy + run of tests to a staging server is known as continuous integration. The idea is that if you check in something that breaks the tests, you would get notified right away. For PHP, you might want to look into Xinc or phpUnderControl

You'd generally not want to automatically deploy to production though. The normal thing to do is to write some scripts that automates the task, but that you still need to manually initiate. You can use frameworks such as Phing or other build-tools for this (A popular choice is Capistrano), but you can also just whisk a few shell-scripts together. Personally I prefer the latter.

The scripts themselves could do different things, depending on your application and setup, but a typical process would be:

• ssh to production server. The rest of the commands are run at the production server, through ssh.
• run svn export svn://path/to/repository/tags/RELEASE_VERSION /usr/local/application/releases/TIMESTAMP
• stop services (Apache, daemons)
• run unlink /usr/local/application/current && ln -s /usr/local/application/releases/TIMESTAMP /usr/local/application/current
• run ln -s /usr/local/application/var /usr/local/application/releases/TIMESTAMP/var
• run /usr/local/application/current/scripts/migrate.php
• start services

(Assuming you have your application in /usr/local/application/current)

Answer 5

I wouldn't recommend automatic updating. Just because your unit tests pass doesn't mean your application is 100% working. What if someone checks in a random new feature without any new unit tests, and the feature doesn't work? Your existing unit tests might pass, but the feature could be broken anyway. Your users might see something that's half-done. With automatic deployment from a check-in, you might not notice for a few hours if something made it live that shouldn't have.

Anyhow, it wouldn't be that difficult to get an automatic deployment going if you really wanted. You'd need a post-check-in hook, and really the steps would be:

1) Do an export from the latest check-in 2) Upload export to production server 3) Unpack/config the newly uploaded export

I've always performed the last steps manually. Generally it's as simple as SVN export, zip, upload, unzip, configure, and the last two steps I just alias a couple of bash commands together to perform. Then I swap out the root app directory with the new one, ensuring I keep the old one around as a backup, and it's good to go.

If you're confident in your ability to catch errors before they'd automatically go live, then you could look at automating that procedure. It gives me the jibbly-jibblies though.

Answer 6

check fredistrano, it's a capistrano clone works great (litle bit confusing installing but after all runs great)

http://code.google.com/p/fredistrano/