PhpRiot
News Archive
PhpRiot Newsletter
Your Email Address:

More information

Deploy on push (from GitHub)

Note: This article was originally published at Planet PHP on 5 June 2012.
Planet PHP

Continuous deployment is all the rage right now, and I applaud the use of systems that automate a task that seems way easier than it is.

That said, sometimes you need something simple and straightforward: a hook that easily deploys a few pages, or a small application, all without often-complicated set up (come on, this is a PHP-focused site, mostly).

Sometimes, you just need to deploy code when it's ready. You don't need a build; you don't need to run testsa-ayou just need to push code to a server. If you use git and GitHub (and I think you should be using GitHub), you can easily deploy on push. We use a setup like this for PHP Advent, for example (it's a very simple app), and we also used this approach to allow easy deployment of the PHP Community Conference site (on Server Grove), last year.

There are really only three things that you need, in most cases, to make this work: a listener script, a deploy key and associated SSH configuration, and a post-receive hook. This is admittedly a pretty long post, but once you've done this once or twice, it gets really easy to set up deploy hooks this way. If your code is in a public repository, you don't even need to do the SSH configuration or deploy key parts.

The listener is just a simple script that runs when a request is made (more on the request bit below). This can sometimes be a bit tricky, because servers can be configured in different ways, and are sometimes locked down for shared hosting. At the most basic level, all your listener really needs to do is git pull. The complicated part is that git might not be in your web user's path, or the user's environment might otherwise be set up in a way that is unexpected. The most robust way I've found to do this just requires you to be as explicit as possible when defining the parameters around the call to git pull.

To do this with PHP (and this method would port to other platforms, too), make a script in your application's web root (which is not necessarily the same thing as the git root), and give it a name that is difficult to guess, such as githubpull_198273102983712371.php. The abstracted name isn't much security, but much security isn't needed here for the simple cases we're talking about, in my opinion. In this file, I have something like the following.

&1"); // main repo (current branch) system("/usr/bin/env -i {$gitpath} submodule init 2&1"); // libs system("/usr/bin/env -i {$gitpath} submodule update 2&1"); // libs echo "\nDone.\n";

The header prevents accidental browsers to this page from having their clients cross-site-scripted (XSS). The submodule lines are only necessary if you're using submodules, but it's easy to forget to re-add these if they're removed, so I just tend to use them every time. 2&1 causes stderr to get redirected to stdout so errors don't get lost in the call to system(), and env -i causes your system() call to be executed without inheriting your web user's normal environment (which, in my experience, reduces confusion when your web host has git-specific environment variables configured).

Before we can test this script, we need to generate a deploy key, register it with GitHub, and configure SSH to use it. To generate a key, run ssh-keygen on your workstation and give it a better path than the default (such as ./deploy-projectname), and use a blank password (which isn't the most secure thing in the world, but we're going for convenience, here). Once ssh-keygen has done its thing, you'll have two files: ./deploy-proj

Truncated by Planet PHP, read more at the original (another 5090 bytes)