Recently, I’ve been looking at various deployment strategies. I’ve spent a lot of my career doing some configuration management, mostly out of necessity where I’ve been the lead developer on a small team. Over the years, I’ve written several deployment scripts. For employers, they’ve always been built on top of SVN and Fabric. Since I didn’t want to use SVN for my personal projects but was familiar with Fabric, this morphed into a project called Fabox, which used Dropbox as a VCS, and Fabric as the CLI to deploy the code. I’ve talked about Fabox before. I used it for awhile but it was too involved for my simple personal projects (Fabric was overkill for my single-server environment). I’ve also soured a bit on Dropbox lately, since their customer support has been completely non-existent.
After Fabox, I wrote a PHP-based deployment server called Giply. It is built on top of Git, and utilizes a common feature with popular Git hosting services Github and Bitbucket where you can POST a payload to a URL. As a web service, Giply consumes these payloads and updates the Git repo automatically.
I took the concepts I learned while writing Giply and vastly improved it with Ripple. Ripple is built in Ruby and includes basic authentication support, easy restoration to previous deployments, and a full featured CLI. It includes a web service like Giply, but it can also be completely managed through the console script.
Since I’ve begun using Ruby for all of my personal projects, I find it really great. Obviously if you don’t have your server environment set up for hosting Ruby (specifically Sinatra), it would probably be a more complicated setup than you’d want. This is the only area where Giply excels. Giply is dead simple to use in a server environment if you have a LAMP stack already created.
There are obviously many other ways to deploy code. Ripple has worked for me in my single-server, no fuss environment. When I want to update the server code, I just push to my Bitbucket repo which POSTs to the Ripple URL I set up in Bitbucket and the rest is handled automatically. It will update projects written in any language, but I’ve added hooks for Bundler in Ruby and Composer in PHP since I use both in my side projects.
For multiple-server environments, there are many options. If you want your scripts written in a particular language, you have several popular options: Fabric (Python), Capistrano (Ruby), and Phing (PHP). These projects all work using SSH to connect to the servers they manage. I’ve personally used Fabric the most, and wouldn’t touch Phing unless I was paid to. Since I love Ruby, I want to try Capistrano but haven’t had the need.
If you’re interested in any of these deployment projects, they’re in my Github. Feel free to use them in your own projects.