Deployment projects

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.

Modern MVC web frameworks often involve a lot of boilerplate code just to support the primary client type of User Agents. This boilerplate code typically does little to help with supporting the other client types of Admin Processes and Unit Tests. As a result of the overhead introduced by this extra boilerplate code, developers often find themselves creating Fat Controllers (a side-effect of The MVC Paradox). Controllers take on too many responsibilities, both vertically and horizontally. Vertically, Controllers start to handle domain logic that should be pushed down to the Model layer. Horizontally, multiple concerns get stuffed into a handful of Controllers. These different horizontal concerns should be separated out into multiple Controllers (the Single Responsibility Principle). The overhead introduced by modern MVC web frameworks leads directly to these problems.

The MVC Paradox – Bradley Holt

» This article is a great read and something I’ve been pondering myself recently. The author references the Slim micro framework which, at least from a cursory glance, is very similar to Silex. I love Silex for the same reasons he mentions Slim:

There is very little boilerplate code involved in handling a User Agent’s request. Minting and handling new routes is incredibly simple. Placing your entire front-end application layer in one file may seem absurd at first. However, it has the nice side-effect of making it painfully obvious if you start to handle domain logic outside of your Model layer or if one route is doing too many things.

I’d recommend checking out these micro-frameworks. Silex has opened my eyes to a new way of designing web applications and services. Where Zend Framework has complexity, Silex offers simplicity.

Source: bradley-holt.com

Today I ran into a problem where my PHP Application would throw this fatal error:

Fatal error: Exception thrown without a stack frame in Unknown on line 0

… After a few minutes I found the problem: I had a class that would save itself to the Session, and that class also had a __sleep method which is invoked on serialization.

PHP, Sessions, __sleep, and Exceptions | Justin Carmony

I had a similar problem not too long ago. My solution was to call:

register_shutdown_function('session_write_close');

at the beginning of the bootstrap process.

Source: justincarmony.com

ps_files_cleanup_dir: opendir(/var/lib/php5) failed

» I’ve seen this error occasionally, but recently it has caused me some grief, so I finally decided to look it up.

In Debian and Ubuntu, /var/lib/php5, where the session data is stored, has permissions of drwx-wx-wt and should only be cleaned by a cron script. So, the package maintainers disable automatic session garbage collection.

The article linked gives some great background, and the answer seems to be setting session.gc_probability = 0.