Up until a few days ago I used to use a small bash deployment script to deploy a few simple sites to my live box. The process was a git archive and extract, then an rsync to the live site. Only inspecting it recently I realised that rsync no longer sent just the changes but all of the files, I'd never noticed before as the sites were so small the deploy was over very quickly. The rsync used to work fine before as I would deploy my current working code where the timestamps on files would match the server. Since I started using git at home for dev, the git archive method timestamps the files with the latest commit's timestamp. This messes up rsync.

His process involves a checked in version of Silex, a development branch, a push of the code to the live machine and an install script to set up Silex. He includes the "technical breakdown" and the information needed to replicate it - the .gitignore, setting up password-less SSHing, setting up the server and creating the git post-receive hook (a bash script).

In one of our last post we built a simple SQL wrapper with PHP. Now we are going to improve it a little bit. We area going to use a class Table instead of the table name. Why? Simple. We want to create triggers. OK we can create triggers directly in the database but sometimes our triggers need to perform operations outside the database, such as call a REST webservice, filesystem's logs or things like that.

He includes the updated code with the new "Table" class with methods that let you set up pre- and post-action hooks on each of the types (insert, delete, update) along with the rest of the library, there ready for the copy & pasting.

Sometimes, you just need to deploy code when it's ready. You don't need a build; you don't need to run tests - you 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. [...] 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.

He explains what each part of the process does and includes the simple PHP script that github calls to make the deployment (it's specific to his example, but you get the idea). He walks you through setting up the deploy key (a SSH key generated on your server) and how to get SSH to use this key when github comes knocking.

I ran into hooks rather simultaneously with two very different frameworks: Code Igniter and Lithium. In both cases I was using a rather nifty hook to handle ensuring that users were properly authenticated and authorized before accessing a page. [...] One day, while messing around, I accidentally turned off the hook configuration within Code Igniter (actually I clobbered a file, and restored the wrong one). Then, things came crashing down in a horrible cacophony of... actually they didn't. Everything kept working: that was the problem.

He shows two solutions he came up with to be sure that his hooks were executed - one for Lithium and the other for CodeIgniter. The Lithium one uses a "_remap" method and the CodeIgniter example uses the magic "__invoke" method to check for an "AUTH_CHECKED" constant that's only defined as a part of his hooks.

I'm no longer entirely dependent on one configuration option or file for my security to function. Should it fail, I've got a secondary check in place; this example of defence in depth allows me to be comfortable with the hooks security system once more.

This [move from svn to git] left a bit of a gap in my process where I could no longer test on a remote server without updating it manually by S/FTP or opening terminal and manually calling a git pull. Open terminal and manually git pull it did break up the work flow a bit so using the Dingo framework I created a very simple Git helper and gave it its own URL something like git/pull.

He added a post-receive hook to his git server that calls this "git/pull" URL on the staging server and updates the code on the server. This provides an easy asynchronous way to update things on another server. Note, though, that this should never be done on a publicly accessible server - it's a pretty large security hole (or at the very least made secure somehow). He used Dingo to create his interface, but something like the Slim micro-framework could have worked just as well. You can view his code on github.

I got to play with the Event Manager. I did like the plugin functionality in ZF1, but it required some pretty static coding. In some cases, like the front controller plugins, it makes more sense (though this way seems more desirable). [...] It's a ZF1 application, but since (it seems) the event manager is self-contained (and the autoloader works with both ZF1 and ZF2) you can simply paste it into your include_path and BOOM, you have an event manager.

In his case he has a set of models extending a base class and wanted to introduce pre- and post-validation hooks to make it simpler to check the data he was working with. He includes the code for his base model class showing how he implemented the ZF2 EventManager in his ZF1 application. He attaches an event to the password class property and, on update, it automatically updates a temporary password value too.

You can get more information on using the EventManager in this other post from Matthew Weier O'Phinney.