· 3 min read
Deployer, a good alternative to Capistrano
Deployer as a PHP alternative to Capistrano for atomic deployments with releases and instant rollback.

Episode rescued from the SeViR Notes archive and translated from Spanish. Originally published on February 14, 2015.
For a long time at DIGIO we’ve been going round in circles about how to deploy our projects to the server better. Our workflow was based on a Git repository that was updated from the server with a simple git pull, so if anything went wrong we could reset to a version in the Git history.
We also added a few extras, such as loading cron configuration from a .crontab file inside the project, so the cron jobs get updated every time we deploy. There was also a .deploy file, acting as a shell script, that let us run actions once the code had been updated, for example running database migrations or clearing cache files.
The biggest problem I saw was with high-traffic projects: while we’re updating the code, a request might come in when part of the code has been updated but other parts haven’t (JavaScript, controllers, models, etc.). That can cause failures in the system because of half-updated code, and problems for users.
On my last visit to Emagister in Barcelona, they told me they used Capistrano and Jenkins. The deploy process is similar in that you can run migrations and other tasks, but it solved the problem we had of potentially serving half-updated code when a web request arrives.
Capistrano, a Ruby tool for deploying to multiple servers
Capistrano creates a release folder with the new code (usually from a Git repository), and the root folder isn’t switched over until everything has been copied into the new release folder. You can configure how many release folders to keep, and roll back instantly if something goes wrong simply by pointing the DocumentRoot at the previous release folder.
But I have a little quirk: being a PHP and JS developer, I always try to find an alternative to installing a Ruby or Python interpreter or anything like that, just as I don’t like frameworks that mix XML, YAML and PHP when everything can be done in a single language.
After a lot of searching I found a couple of interesting projects: Rocketeer and Deployer. The latter, perhaps because of its simplicity and because, let’s admit it, its website is nicer to read, was the one I liked most.
Both projects are copies of Capistrano, and both run as a phar, like Composer, which is very convenient: you only need a single file to run them. Deployer perhaps offers a bit more versatility with less configuration.
Deployer: versatile and easy to configure, in PHP
With Deployer we get a safe deploy process, the ability to roll back instantly to a previous version, easy execution of commands on the remote server or on the deploy server, support for SSH keys or username and password, and multiple servers per environment (for example, pushing new changes to several servers in our cluster).
In Deployer we define environments (production, development); within each one, a group of servers we’ll send updates to (usually there’s only one); and finally tasks to run on those servers. In our case, that means shipping the latest version of the code from Git.
Combine this with Jenkins or our online deploy tool and the whole team can easily update the project’s code.