Comment by gnufied | Hacker News Reader

Comment by gnufied | Hacker News Reader

For real long time Capistrano v2 has been exclusively going forward with Pull requests and next to no new development while Lee worked on v3 on separate branch, which looks like a rewrite.

As a result various releases of v2 were buggy. Capistrano is a hard to test application agreed but its test coverage is plainly woeful.

About 6 months back when 2.4.12 release was broken (https://github.com/capistrano/capistrano/issues/434) I suggested to remove asset pre-compilation stuff from Capistrano. Capistrano is a general purpose tool, company where I work we use it for deploying java, php, ruby and all sort of stuff. I don't understand why it should have poorly tested asset pre-compilation things built in.

I don't know what made Lee work on a rewrite. I can only imagine how difficult it must have been for him to work on something so big singlehandedly while running a company.

His last point is very valid about using RVM, rbenv etc in production. I don't know why people do that. Does that make it easier? Aren't people aware of something like - https://launchpad.net/~brightbox/+archive/ruby-ng ?

The motivation behind the rewrite was in order to bring the project to a state where people who weren't intimately familiar with the internals would be able to contribute.

The rewrite is a ground-up re-think, but it's leaning on the best of what the open source community has come up with in the last 5 years, and leaning heavily on all the best practices we've learned as a community.

The rewrite was also a way for me to say "this isn't a rails tool anymore" (of course, those of us who knew Capistrano well could always cut out the core railsisms and use it for deploying pretty much anything). And a way to say "look, this tool isn't magic, it's an orchestration tool that glues together some other libraries".

Part of the rewrite was to split things into components, so that when people have a version that works for them, bug fixing changes to rvm or rbenv, or other extensions don't have to risk breaking the core functionality. Stability through modularity.

A way for me to pay my envisaged debt to society for the good things that being the custodian of such a widely used project has brought me.

Many of the v2 releases were broken as I tried to let two people help me with maintainer ship, and both of them went a little nuts accepting pull requests, and a lot of things got merged that probably weren't quite upto scratch, or caused subtle problems, which is a huge problem of Capistrano.

I'm grateful to both of them for their bravery, and willingness to try and help, but maintaining it has been such a hard task. A balance between maintaining compatibility, and not breaking people's production environments, and pushing the tool forwards, and improving it.

The reason I use RVM in production is that it makes it trivially easy to:

1) Use multiple parallel Ruby versions for transitions and rollbacks - for example, when we upgraded from Ruby 1.9 to 2.0, we installed 2.0 via RVM, ran our staging environment on 2.0 while production ran on 1.9. The instant-rollback safety net is great, because if we run into some obscure bug on one VM, we just change our RVM environment config var and deploy and we're back to known-good in seconds with no downtime.

2) Run applications that require different Ruby version levels. For example, Puppet 2.7 wasn't compatible with Ruby 1.9+, but our app was running on 1.9. With a single system install, we'd not be able to run both.

The point about stepping out-of-bounds in regards to LTS distros is extremely valid, but at least in our case, it's not about "just effin' compile already!", but rather about flexibility and resilience - by using RVM, we absorb the burden for making sure things work rather than delegating it to our distro, but it's worth it for the things we pick up.

I would recommend running using chruby or just ruby-install and $PATH (chruby just changes the path variable) for those things since it is less invasive.

Personally I always try to run ftom apt in production.

+1 to this. I wrote up how to build a ruby .deb from ruby-install here: http://www.blackkettle.org/blog/2013/08/26/how-i-ruby-part-2...

Reply on news.ycombinator.com