I looked at a while ago, the thin requirement is arbitrary and you can use unicorn from a fork iirc.
In the end - it just seemed a little too painful to get working with, but is something I am interested in playing with again now that I'm working full time on a Rails 3+ app.
We're trialling cutting packages from Rails apps with fpm[1], plus prm[2] to create the apt repository on s3.
There's a bit of footwork needed to include built gems and correct asset manifests in the package too, but we now have 10-20s deploys, down from 8-12 mins. Plus it has less impact on server resources.
I wonder whether this will please hardcode Debian people. A quick look reveals that the packaging structure does not conform to the FHS. I personally don't care but I've seen quite some resistance in the Debian community (and in general, the Linux distro community) against packages that do not conform 100% to their standards.
I'm assuming this is primarily meant for apps that get deployed to in-house servers rather than being submitted to the public Debian repositories, whose packing guidelines are indeed quite strict.
6 comments
[ 5.4 ms ] story [ 29.5 ms ] threadIn the end - it just seemed a little too painful to get working with, but is something I am interested in playing with again now that I'm working full time on a Rails 3+ app.
There's a bit of footwork needed to include built gems and correct asset manifests in the package too, but we now have 10-20s deploys, down from 8-12 mins. Plus it has less impact on server resources.
1. http://rubydoc.info/gems/fpm/latest/frames 2. http://rubydoc.info/gems/prm/latest/frames
I tried it once before, it's just not stable enough at the time.