21 ms·

Time to hand over the reins before Capistrano costs me my youth?

472 points by codebeaker 13y ago

codebeaker 13y ago
I'm the OP of the mailing list post, and have maintained Capistrano for the last 5 years. I'm passionate about providing great open source tools, my business and reputation are built on Capistrano and I don't want to give it up, but it's destroying me.
- mtarnovan 13y ago
  As I have used Capistrano on many projects, I want to thank you for your hard work and assure you that it has been much appreciated.
- beachstartup 13y ago
  if you can't find a successor - just keep in mind that people don't tend to step up unless there is a vacuum. if you were to step down, someone would step up, especially in a community as large as the one you're in. if it's destroying you, leave. go on a long vacation. it's not worth it. there's no shame or guilt in taking a break or passing on your work.
- gnufied 13y ago
  Hey Lee, I am yet to look into v3 stuff closely, but if you think it is better why not make maintstream? Is the main reason just community backlash?
  - codebeaker 13y ago
    As I wrote in the mailing list post, it'll be made mainstream this week, as I think it's a general improvement in all areas, at least it's faster, easier to debug, looks and works better, and has better out of the box compatibility with Rails (3 and 4).
- nikoftime 13y ago
  Hi Lee - Our company also uses Cap extensively and we really appreciate all your hard working building and maintaining it. I totally feel your pain reading responses about bugs, test coverage, etc. I urge you to consider whether you can get a couple of trusted allies or colleagues involved in putting Cap 3 out. I think it could be a huge boon to those of us who like the idea of modularized code and perhaps you can find a buffer or person who is willing to field some or all of the influx of bug reports (directly ask the community if so!)
  - codebeaker 13y ago
    Tom `seenmyfate` Clements has been helping to support me over the last three months when I've been very burned out, and has really taken my vision for v3 and made it reality where I wouldn't have been able to. He'll always be around taking care of Capistrano as his company grants him some 20% free time to work on it, I trust him implicitly, and he already has deploy and unregulated commit access. Tom, if you are on HN, you're the only reason this project has been able to come as far as it has. Thank you.
    - tomdefi 13y ago
      It's been a pleasure, I'm really proud of what we've built so far. I hope that following a long and well deserved break you'll find yourself itching to return. No-one can deny you've gone above and beyond with a very demanding project, maybe with v2 retired and some additional support the overhead will come down to a much more manageable level.
- gravitronic 13y ago
  We use capistrano at Shopify for our main rails project and countless smaller projects. Thanks for your efforts.
- sandGorgon 13y ago
  Kickstarter ? I mean for something as operationally critical like Capistrano, why dont you seriously raise money on Kickstarter, outsource some of the testcases, etc. and be more productive overall. And please feel free to raise money to fix RubyGems as well ;)
  - palidanx 13y ago
    I don't know how this would vibe in the open source community, but I'd definitely donate to help out a Capistrano project.
  - martinkallstrom 13y ago
    Running a Kickstarter project is not recommended for someone close to burning out.
- mikkelewis 13y ago
  Lee, we use Capistrano at Scribd for our main Rails app, QA servers and countless other Ruby/Java services. In a world of complaints, we haven't had a single complaint about Capistrano. Thank you.
- hannesfostie 13y ago
  Thank you so much for Capistrano. We use it on a daily basis (several times) and built http://capo.io http://capo.io to make it easier to re-use deploy scripts. I'm going to take a closer look into the source code and try to help out with issues. It's something I've been wanting to do for a while so I hope I can at least help out a little bit here
- kintamanimatt 13y ago
  Maybe you need to take some time off completely if you're this burned out. Go travel and come back to software and life in a few months to a year. Maybe you'll be inspired to start something new, or maybe there will be something completely different you'll want to do. You'll always be the creator of Capistrano and for this your reputation will live on. If you've got clients that love you, your business will also thrive. I think your fear of letting go is probably unwarranted, and in any event your happiness should come first.
  - npsimons 13y ago
    Have to second this; your love and dedication is too much to lose, both for the community and for yourself. Take a break, ignore the haters, stay happy.
- kule 13y ago
  Just wanted to add my thanks for such a great tool. I've been using cap since the rails 1.x days and it's always worked for me like a charm - I'm so grateful you stepped up to the plate to create & maintain it. Maybe you can find a way to delegate the bits you don't like about maintaining Capistrano so you don't need to directly manage it yourself? This is probably niave and maybe you are doing this already with v3 but it occurs to me if rails is the main cause of the headaches perhaps you can split that part into a cap-rails gem that is separately managed then you could hand over the reigns to someone else? Anyways, as mentioned, thank you for a great tool - I very much hope you find a solution that helps you feel good about the situation.
- politician 13y ago
  Thank you for all of your hard work on Capistrano. We use cap extensively at Simply Measured... as well as a "TurboGC" version of Ruby on an LTS version of Linux (hah!). Perhaps in the future something like containers will provide a better way forward, but for now cap is irreplaceable.
- Axsuul 13y ago
  Hey Lee, just wanted to say thanks for making Capistrano. It's awesome and it's made the world a better place.
- tomphoolery 13y ago
  I just want to say that I love Capistrano. Even though I don't use it all the time, I still think it's a really great way of deploying when you aren't in a container-based workflow and you just want a quick way of running remote commands from your local machine. As for your comment, "Ruby is pathologically difficult to install correctly on modern Linux distributions", I disagree wholeheartedly with this. It may be more difficult to install than a simple `apt-get`, but if you're used to compiling from source and you know what the hard dependencies are, it's really not a huge problem. ruby-install and ruby-build of course make this easier but those tools don't require the use of RVM or rbenv, especially on a machine where you know there will only be one Ruby. However, you're correct in the assumption that Ruby could be a lot easier to install if the language creators would move towards that. That said, I think there are a lot of people who are unfairly blaming you for their own misunderstandings of what these tools do and how they are used. For example, chruby or rbenv is absolutely vital on my dev machine because I work with projects using different versions of Ruby. But it's just bad practice to have a production box running multiple versions of Ruby, in my opinion. I really feel that the users you've interacted with may have been frustrated by their own misunderstanding of the tools they're using, because it's really not as hard as a lot of people make it out to be...
  - pessimizer 13y ago
    Ruby is awful to install for production.
    - bradleyland 13y ago
      I compile Ruby from source for all my deployments (Debian based). I only need to apt install a handful of build deps and the build goes off without a hitch every time. Can someone direct me to the common complaints, or outline the common complaints here?
      - lost-theory 13y ago
        Your method is sane, the problem is with RVM and rbenv, which everyone uses and depend on hacky implicit shell BS (rbenv less so, but it's still there). Build from source and use the full path to the interpreter is the only sane method IMO.
- kaishiro 13y ago
  Lee - We're a small dev shop in the greater Boston area and we use Capistrano exclusively for our deployment process. Frankly, I'm blown away that you've taken this as far as you already have, and completely understand your stance on the community at-large. I think I'd have to echo others before me in saying that sometimes you just need to step back and grab a cocktail. Take a few months away for the sake of self preservation. It's only code :) Thanks for all you've done.
- t4567 13y ago
  Let's say that you decide to continue. I think that you should get advice from elsewhere than here, from someone whose professional expertise is in the emotions. Before everyone leaps to conclusions, I'd better clarify - I am not saying there's anything wrong with you - I am not excusing the crass behavior which is getting you down. What I'm saying is that there are almost certainly skills you can learn which will stop this getting to you. I don't know exactly what they are, and most people here don't either (although they will passionately sell you the hammer which worked for their particular nail). Ask an expert.
- conatus 13y ago
  Just to say, I love Capistrano - its a great product that I use almost every day. I introduced it at one place I worked and it took deployment time from painstaking hours to minutes. Thanks very much for your efforts and I am sorry you feel the need to step down from maintenance.
- damncabbage 13y ago
  Thank you so very much for your efforts. We use Capistrano at Bigcommerce to deploy our apps and components, and it's saved us from an inevitable pile of shell scripts. :-)
- r7000 13y ago
  I have never commented anywhere about Capistrano. But, it has been part of a toolchain that has brought me success and improved my life. Thank you very much for all you have done.
ealexhudson 13y ago
A good decision - get out while things are still positive. Not enough people are brave enough to step down at the right time (or even when it's obvious it's already the wrong time).
gnufied 13y ago
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 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 https://launchpad.net/~brightbox/+archive/ruby-ng ?
- codebeaker 13y ago
  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.
AhtiK 13y ago
Does anyone know what's wrong with the Rails asset pipeline that is mentioned in the post as one of the issues?
- codebeaker 13y ago
  There's a number of problems, but foremost is that there's no good way to "roll back" assets, and there's no concept of keeping assets that might be used by old versions of pages cached in CDNs, when they have been replaced by newer assets. This is a problem of the manifest system, and of the `assets` directory always representing the current newest state, not the collective state since the beginning of time. Maintaining state from the beginning of time would bring it's own problems, thus many of the workarounds about tracking old, and new assets are time consuming and sub optimal, and unfortunatley people need them. There's a cap task which touches `mtimes` of all referenced assets, which can typically take 5 minutes to complete. It's naïve, and stupid, but it's the only solution (that we could come up with) to a real asset pipeline problem. I'm also of the opinion that compiling assets in production as a part of your deployment process is insane, there's so much magic in the Rails asset pipeline that it's not uncommon to turn up bugs where tables don't exist, and the rails app can't initialize, or some javascript runtime environment isn't found which can leave your deployment in a broken state. I'm firmly of the opinion that assets should be compiled and checked in, but then of course you run into problems with rails serving those in development mode, rather than the development files. All these issues are fixable, but they're all indicative of tools that aren't quite mature yet, and as Capistrano sits on the boundary of where these problems come to light, it seems to fall to us to deal with it, and to educate people on what they ought to be doing. Education is no problem, I really believe that the de-facto standardisation of Rails-like deploys (i.e timestamped releases, with common linked directories, and a symlink to the current active timestamp) is an excellent result for knowing what to expect in an environment where there's hundreds of ways to get Rails apps running, but it's still not as smooth a process as it could be. I'm familiar with at least one project that's been re-written in Scala and Java because the previous version was prohibitively difficult to deploy as it was in RoR. (GrayLog2, to namedrop them)
  - kaffeinecoma 13y ago
chrismealy 13y ago
I love ruby and rails, but yeah, I'd switch to any framework in any language that made deployment stress-free. Except php.
- keypusher 13y ago
  Python with virtualenv and pip has been fairly stress free in my experience.
  - kawsper 13y ago
    I feel Python apps is quite a pain to install. I had to deal with a Graphite installation, and it consists of 50% packages from apt-get and 50% of packages from easy_install. https://gist.github.com/kaspergrubbe/5792356 https://gist.github.com/kaspergrubbe/5792356 Is this an issue with Graphite? Because I feel this setup is quite elaborate compared to using Rubygems and bundler.
    - shabble 13y ago
      That's a rather alarming install script, especially things like: sudo apt-get --assume-yes upgrade in it. But to your point, I think most of the easy_install packages could be handled by pip. The apt packages look like almost all non-python major components like rabbitmq, apache, sqlite, etc which are best provided that way. I'm not sure about Graphite itself, but at a quick glance it's not clear why it's all 'sudo python setup.py' rather than in a package.
    - gingerlime 13y ago
      From experience with both python/django and ruby/rails, I think python is generally simpler. Start with the fact that python itself is usually pre-installed on most distros, and usually a recent-enough version to get you started. Ruby on the other hand is much harder to just get installed, choosing the right (minor)version, rvm/rbenv choices etc. I tend to compile my ruby, but it's a lengthy and rather fragile process. Graphite is both a good and bad example. Good because it is really complex and documentation is a little sketchy. I've written a fabric script[1] that automates the process, and it's far from trivial. Bad example, because it's not really a single app, but a system - a collection of tools with dependencies. Even if we discount the web server (nginx or apache?), it includes things like the core "database" (whisper), the event listener (carbon, which in itself is complex depending on your setup), the graphic and processing libraries, and then graphite which is a pretty involved django app with its own sub-components. So when you say graphite, it's really a full-blown system with lots of moving parts that need to fit in together. I can't think of an equivalent example in the rails world, but any rails app with a db, caching layer, and a few other external components won't be much easier to get set up and running. [1]https://github.com/gingerlime/graphite-fabric https://github.com/gingerlime/graphite-fabric
bretthopper 13y ago
Some unsolicited advice from someone who's never run an open source project as popular as Capistrano: * Ditch v2 ASAP (seems like you've already decided on this). It's pretty obvious you aren't motivated to work on that codebase anymore. I've looked at v3 and it's much better thanks to relying on Rake tasks. * Be selfish. It's your project so if you think v3 is the way to go forward, go with it and who cares what the "community" thinks. * Seems like you already have a few people helping out, so continue and maybe make formal "core" team. There's nothing with yourself taking a step back from the heavy coding. But I believe that Capistrano would be better with your guidance than without it. codebeaker: There was no mention of Harrow in that post. Are you still working on that? I'd assume that if you were you'd continue work on Capistrano since it's based on it.
- codebeaker 13y ago
  Regarding Harrow [1] bretthopper, I absolutely am, and this is where I want to focus my work, and to be able to build a company around deployment best practices and Capistrano. Regardless of frameworks, and of technologies and platforms, I believe if I can take the load off myself with Capistrano, by turning it into the open source component of a best-practice company, and build teams of passionate, skilled support engineers, then I'll be where I want to be. Unfortunatley Harrow would suffer if I give up on Capistrano, as part of the promise of Harrow as a SaaS is that it's all guaranteed to stay compatible, and work as we've all come to expect, just with improved workflow, etc... ([1] http://www.harrow.io http://www.harrow.io, please excuse the missing graphic placeholder I've not updated the landing page in some time as I've been focusing on building the product, and the landing page performs really well without that graphic in place)
  - diminish 13y ago
    Lee, why not try the sidekiq way? A capistrano pro, and a hosted managed version or maintenance fee...
- canes123456 13y ago
  Also, charge for support. List supported platforms and charge for support for strange configurations.
alrs 13y ago
As always, it bears repeating: rvm/rbenv don't belong in production. They exist to allow developers on Macbooks to sync their version of Ruby with whatever is packaged in the Linux distro or BSD variant that runs in production. If I had a Mac I'd skip the ad-hoc Ruby environment switchers and skip straight to Vagrant.
- 3pt14159 13y ago
  I used to agree with you. Why would you take a 20 or 30 percent performance hit when you are busy shelling out tens of thousands for hardware load balancers. Then one day a rare instruction set on our colocated server (so not something super standard like linode) was specified during the compilation step of ruby and (due to an extremely subtle co-bug between ruby and the compiler). It took us fucking weeks to find this hisenbug that was somehow causing workers to drop, but only during times of very high load. Probably lost $500k worth of customers, dev time, and company moral. Now I have a different view. Keep things as simple and as "normal" as possible. That way you can always upgrade to the next version, you don't hit weird bugs when you libraries assume that Time.now is second-accurate, instead of sub-second accurate (MRI vs Enterprise Ruby). RVM is made for production (http://stackoverflow.com/a/6282260/384700 http://stackoverflow.com/a/6282260/384700) and it saves a lot of headaches to just go with the flow. As for mac dev, I agree that it is a waste of time compared to working out of Ubuntu, but designers like photoshop and Vagrant is non-trivial for them to set up, especially for people that work on multiple projects.
  - alrs 13y ago
    I'm confused. Simple and normal, to me, means "use packaged Ruby." Chasing the bleeding edge and compiling the interpreter at every release is exactly the sort of practice that introduces edge-case heisenbugs. If you need a nonstandard compile-time option you go to work on the package source, make the change, put your custom package up in your private apt/yum repo, and leave things alone until the next security update comes down the pike. Me, I consider hosting to be entirely fungible. I'd rather change vendors than mess about with custom packaging big chunks of the stack to work around weirdness. Wherever I have encountered Phusion's REE I have ripped it out, with good results.
AlexMuir 13y ago
My first thought was "I owe this guy, Capistrano is the main reason why I have spent ~ $100 per year on VPS servers and not $100 per MONTH on Heroku et al. I'd suggest Lee runs a Kickstarter type thing and I'd very happily throw in $100. But I don't think he will because it doesn't seem quite right. So here's a (wild and completely off the cuff) startup idea - a pre-emptive Kickstarter. Someone creates the project "Lee Hambley, continue working on Capistrano." and we all pledge into the pot. If Lee agrees to do it, he gets the money. If not, we don't pay anything.
- forsaken 13y ago
  Or just give them money on something like gittip. Things like this need to be sustainable, not just a flash in the pan of $10k, then going back to having nothing.
kawsper 13y ago
I am a bit sad that he feels this way about it. I have used Capistrano a lot, I built my "default" setup, compiled it into a gem, and released it here: https://github.com/kaspergrubbe/simple-capistrano-unicorn https://github.com/kaspergrubbe/simple-capistrano-unicorn and moved on with my life as a developer. I know of at least two bigger organizations that depend on Capistrano (and my gem) for their deploys. I feel like Capistrano is the way to go if you manage your own servers, and need to deploy to them. Capistrano started my Rails experience, and I am very grateful for the work put into it. But I never wrote and said "Thank you" or "Great job", maybe we need to be more vocal to the people that put in time and energy to build the software that we use a lot.
forsaken 13y ago
I just wanted to point out how poisonous our community is. It's something that I've been struggling with for a long time, and trying to slowly change. The fact that people read this article, and don't feel the need to mention his fear of releasing software just shows how broken things are. It shouldn't be an accepted fact of open source that if you release new code that might be backwards incompatible, you get vitriol for it. His quote: ... but I too cowardly to release it and make it mainstream, as Im afraid it'll destroy whatever good will for open source I have left when the flood of support questions inevitably comes in, followed by all the people who are unhappy with what I've built and feel obliged to tell me how bad I am at software.
- avenger123 13y ago
  I can't comment on the poisonous nature of the community but what I have noticed is that at some point its taken for granted that the open source solution will be very stable and solid. It seems (and this is just entirely my opinion) that it is forgotten that people are doing this out of their own goodwill and are not necessarily being paid for it and really have no contractual obligation to keep doing what they are doing. It's almost the worst of both worlds. You get all the responsibility for having your open source project be considered at the same level as a commercial solution but without it actually being a commercial solution.
- leoh 13y ago
  > I just wanted to point out how poisonous our community is. It's something that I've been struggling with for a long time, and trying to slowly change (from inside the python community). Do you mean to say that the Python community is poisonous? Or that the Ruby community is poisonous from the perspective of a Python community member?
  - avenger123 13y ago
    I didn't put too much weight on whether it was Python or Ruby. I felt it was a statement about the whole open source community rather than a particular group.
joeblau 13y ago
It's sad to see when an open source project becomes overwhelming. On one hand the project is open source, so hopefully, someone else can pick up the torch. We saw this happen in the node.js community and node's been moving along. On the other hand, based on what Lee is saying, it looks like situation is pretty bleak. I'm not a Rails user, but I feel like most of the "hot-startups" in San Francisco run a Ruby stack. From an observer looking into the community and platform though this post, I never realized how many challenges there were in that development environment.
patio11 13y ago
Thanks for creating software which has been an immense service to the community, and which I rely on quite a bit. Tangent mode on: Somebody really, really needs to write the How To Deploy Rails Without Losing Your Sanity handbook. I will buy a copy. It will sell thousands of them. A lot of the problems with people's interactions with Capistrano are environment/ops problems which have known solutions that work, but which rely on people having a great understanding of arcane trivia which is spread across conference presentations, blog posts, commit messages, and the practical experience of the best Rails teams. Unless you're prepared for an archaeological expedition every time you start a new Rails project, you're going to do something wrong. You should see the bubblegum and duct tape which I came up with, and it mostly works, but I know it is bubblegum and duct tape. Example: Non-deterministic deploys of code from (usually) un-tagged source control I feel lucky in that I was mentored by an engineer who decided to teach me, one day, Why We Tag Shit. But for the Why We Tag Shit discussion, I would be like almost every other intermediate Rails engineer, and be totally ignorant of why that was a best practice until lack of it bit me in the keister, at which point the server is down and one has to rearchitect major parts of the deployment workflow to do things the right way. Why We Tag Shit is only about a 500 word discussion, but it's one piece of organic knowledge of the hundreds you need to do things right, and it is (to the best of my knowledge) not covered in docs/QuickStarts/etc because that seems to be out of the purview of the framework proper (I guess?). I'm sure that I'm ignorant of several of the hundreds of pieces of things one needs to do to do deployment right, as evidenced by my fear every time I execute my deploy scripts. I, and I must assume many other companies, am willing to pay for an option which gets me to a non-bubblegum and duct tape outcome. Seriously, folks: there is a product here.
- raverbashing 13y ago
  I'll be downvoted by the "newer generation" but here's a pet peeve of mine The same reason "why we tag shit" is the reason downloading packages from gem/pip is not enough Who guarantees that when you do your deploy, the library you need is there? How many times did your build break because it had a glitch downloading the package? Keep a way of rebuilding and deploying your software. All of it
  - 13y ago
grandalf 13y ago
Check out fabric as a much faster alternative to Capistrano. Combined w cuisine.py it's a simple and powerful alternative to chef solo.
yannk 13y ago
"Whilst I believe strongly in Capistrano as a general purpose tool [...] I do think the future of software deployment is in small, containerised VMs and so-called PaaS, as what we're all doing right now has to end, some time." Kudos. It takes a lot of courage to admit your baby is not going to fulfill the future you had initially imagined.
stevewilhelm 13y ago
Check out 'Deploying Ruby Applications to AWS Elastic Beanstalk with Git' [1] [1] http://ruby.awsblog.com/post/Tx2AK2MFX0QHRIO/Deploying-Ruby-Applications-to-AWS-Elastic-Beanstalk-with-Git http://ruby.awsblog.com/post/Tx2AK2MFX0QHRIO/Deploying-Ruby-...
machbio 13y ago
Thanks for the awesome software.. I just started learning about capistrano recemtly, just amazed by how simple it is.. I believe when you said that PAAS will go, only reason I use heroku and dokku(from docker) is due to its easy deployment.. and for no other reason than deployment..
tomdefi 13y ago
For anyone interested in an overview of Capistrano v3, I wrote an introduction last week - https://medium.com/p/ba896a142ac https://medium.com/p/ba896a142ac
- codebeaker 13y ago
  Tom's article is a really great run down of all the awesome things that we built.
wbogg 13y ago
Everybody can earn 150$+ daily... You can earn from 4000-9000 a month or even more if you work as a full time job...It's easy, just follow instructions on this page, read it carefully from start to finish... It's a flexible job but a good earning opportunity.. go to this site home tab for more detail ..... big57.ℂℴM
joevandyk 13y ago
Really looking forward to Docker being 1.0. What you want to do is build a single package of everything your application needs (which includes the application code and all dependencies -- libc and up), then copy that package to the production servers. It shouldn't matter if your application server has Ruby 1.9.3 and you need 2.0. It shouldn't matter if the last deploy of your app needs Nokogiri compiled against libxml 2.8 and you now need 2.9. It shouldn't matter if you are running 5 different apps with 5 completely different set of dependencies on the same machine. It shouldn't matter if you need to use the asset pipeline. It shouldn't matter if github or rubygems drops out half-way through the deploy process. All the production server should get is a single package of all that your application needs, then a 'restart application' command. Docker should be able to handle all this simply.
joaomsa 13y ago
Capistrano really has saved us multiple times, sad that a vocal part of the community tends to exhibit such behavior. At our company, we develop multiple RoR apps and we've run into many of these issues (mostly related to the asset pipeline), yet none of them actual problems with Capistrano. Since it's the bridge between so many things, I can imagine why it's easy for it to become cannon fodder. We've tried to standardize many of our recipes such as local asset precompilation into a single cohesive gem (https://github.com/innvent/matross https://github.com/innvent/matross). That has saved us the trouble of debugging the same issues over and over when they inevitably pop up across applications.
deleted 13y ago
[deleted]
ChikkaChiChi 13y ago
As much as this is an open invitation to rail on the RoR community, I think this is a problem that is a lot more indicative of this brave new software culture both open source and (independent) commercial. If your tool sees any sort of uptake, it suddenly no longer is yours. The community suddenly expects you to not only to continue to modify the base code to improve functionality, but to also adhere to a sort of backwards compatability so that everything they know and loved about your baby never changes. I can't imagine how much more taxing this would be once the tools you built become integral part of other team's workflow. The burden and stresses of keeping "the world" afloat would cause many a sleepness night for people of strong constitution.

472 points by codebeaker 13y ago

I'm the OP of the mailing list post, and have maintained Capistrano for the last 5 years. I'm passionate about providing great open source tools, my business and reputation are built on Capistrano and I don't want to give it up, but it's destroying me.

mtarnovan 13y ago
As I have used Capistrano on many projects, I want to thank you for your hard work and assure you that it has been much appreciated.
beachstartup 13y ago
if you can't find a successor - just keep in mind that people don't tend to step up unless there is a vacuum. if you were to step down, someone would step up, especially in a community as large as the one you're in. if it's destroying you, leave. go on a long vacation. it's not worth it. there's no shame or guilt in taking a break or passing on your work.
gnufied 13y ago
Hey Lee, I am yet to look into v3 stuff closely, but if you think it is better why not make maintstream? Is the main reason just community backlash?
- codebeaker 13y ago
  As I wrote in the mailing list post, it'll be made mainstream this week, as I think it's a general improvement in all areas, at least it's faster, easier to debug, looks and works better, and has better out of the box compatibility with Rails (3 and 4).
nikoftime 13y ago
Hi Lee - Our company also uses Cap extensively and we really appreciate all your hard working building and maintaining it. I totally feel your pain reading responses about bugs, test coverage, etc. I urge you to consider whether you can get a couple of trusted allies or colleagues involved in putting Cap 3 out. I think it could be a huge boon to those of us who like the idea of modularized code and perhaps you can find a buffer or person who is willing to field some or all of the influx of bug reports (directly ask the community if so!)
- codebeaker 13y ago
  Tom `seenmyfate` Clements has been helping to support me over the last three months when I've been very burned out, and has really taken my vision for v3 and made it reality where I wouldn't have been able to. He'll always be around taking care of Capistrano as his company grants him some 20% free time to work on it, I trust him implicitly, and he already has deploy and unregulated commit access. Tom, if you are on HN, you're the only reason this project has been able to come as far as it has. Thank you.
  - tomdefi 13y ago
    It's been a pleasure, I'm really proud of what we've built so far. I hope that following a long and well deserved break you'll find yourself itching to return. No-one can deny you've gone above and beyond with a very demanding project, maybe with v2 retired and some additional support the overhead will come down to a much more manageable level.
gravitronic 13y ago
We use capistrano at Shopify for our main rails project and countless smaller projects. Thanks for your efforts.
sandGorgon 13y ago
Kickstarter ? I mean for something as operationally critical like Capistrano, why dont you seriously raise money on Kickstarter, outsource some of the testcases, etc. and be more productive overall. And please feel free to raise money to fix RubyGems as well ;)
- palidanx 13y ago
  I don't know how this would vibe in the open source community, but I'd definitely donate to help out a Capistrano project.
- martinkallstrom 13y ago
  Running a Kickstarter project is not recommended for someone close to burning out.
mikkelewis 13y ago
Lee, we use Capistrano at Scribd for our main Rails app, QA servers and countless other Ruby/Java services. In a world of complaints, we haven't had a single complaint about Capistrano. Thank you.
hannesfostie 13y ago
Thank you so much for Capistrano. We use it on a daily basis (several times) and built http://capo.io http://capo.io to make it easier to re-use deploy scripts. I'm going to take a closer look into the source code and try to help out with issues. It's something I've been wanting to do for a while so I hope I can at least help out a little bit here
kintamanimatt 13y ago
Maybe you need to take some time off completely if you're this burned out. Go travel and come back to software and life in a few months to a year. Maybe you'll be inspired to start something new, or maybe there will be something completely different you'll want to do. You'll always be the creator of Capistrano and for this your reputation will live on. If you've got clients that love you, your business will also thrive. I think your fear of letting go is probably unwarranted, and in any event your happiness should come first.
- npsimons 13y ago
  Have to second this; your love and dedication is too much to lose, both for the community and for yourself. Take a break, ignore the haters, stay happy.
kule 13y ago
Just wanted to add my thanks for such a great tool. I've been using cap since the rails 1.x days and it's always worked for me like a charm - I'm so grateful you stepped up to the plate to create & maintain it. Maybe you can find a way to delegate the bits you don't like about maintaining Capistrano so you don't need to directly manage it yourself? This is probably niave and maybe you are doing this already with v3 but it occurs to me if rails is the main cause of the headaches perhaps you can split that part into a cap-rails gem that is separately managed then you could hand over the reigns to someone else? Anyways, as mentioned, thank you for a great tool - I very much hope you find a solution that helps you feel good about the situation.
politician 13y ago
Thank you for all of your hard work on Capistrano. We use cap extensively at Simply Measured... as well as a "TurboGC" version of Ruby on an LTS version of Linux (hah!). Perhaps in the future something like containers will provide a better way forward, but for now cap is irreplaceable.
Axsuul 13y ago
Hey Lee, just wanted to say thanks for making Capistrano. It's awesome and it's made the world a better place.
tomphoolery 13y ago
I just want to say that I love Capistrano. Even though I don't use it all the time, I still think it's a really great way of deploying when you aren't in a container-based workflow and you just want a quick way of running remote commands from your local machine. As for your comment, "Ruby is pathologically difficult to install correctly on modern Linux distributions", I disagree wholeheartedly with this. It may be more difficult to install than a simple `apt-get`, but if you're used to compiling from source and you know what the hard dependencies are, it's really not a huge problem. ruby-install and ruby-build of course make this easier but those tools don't require the use of RVM or rbenv, especially on a machine where you know there will only be one Ruby. However, you're correct in the assumption that Ruby could be a lot easier to install if the language creators would move towards that. That said, I think there are a lot of people who are unfairly blaming you for their own misunderstandings of what these tools do and how they are used. For example, chruby or rbenv is absolutely vital on my dev machine because I work with projects using different versions of Ruby. But it's just bad practice to have a production box running multiple versions of Ruby, in my opinion. I really feel that the users you've interacted with may have been frustrated by their own misunderstanding of the tools they're using, because it's really not as hard as a lot of people make it out to be...
- pessimizer 13y ago
  Ruby is awful to install for production.
  - bradleyland 13y ago
    I compile Ruby from source for all my deployments (Debian based). I only need to apt install a handful of build deps and the build goes off without a hitch every time. Can someone direct me to the common complaints, or outline the common complaints here?
    - lost-theory 13y ago
      Your method is sane, the problem is with RVM and rbenv, which everyone uses and depend on hacky implicit shell BS (rbenv less so, but it's still there). Build from source and use the full path to the interpreter is the only sane method IMO.
kaishiro 13y ago
Lee - We're a small dev shop in the greater Boston area and we use Capistrano exclusively for our deployment process. Frankly, I'm blown away that you've taken this as far as you already have, and completely understand your stance on the community at-large. I think I'd have to echo others before me in saying that sometimes you just need to step back and grab a cocktail. Take a few months away for the sake of self preservation. It's only code :) Thanks for all you've done.
t4567 13y ago
Let's say that you decide to continue. I think that you should get advice from elsewhere than here, from someone whose professional expertise is in the emotions. Before everyone leaps to conclusions, I'd better clarify - I am not saying there's anything wrong with you - I am not excusing the crass behavior which is getting you down. What I'm saying is that there are almost certainly skills you can learn which will stop this getting to you. I don't know exactly what they are, and most people here don't either (although they will passionately sell you the hammer which worked for their particular nail). Ask an expert.
conatus 13y ago
Just to say, I love Capistrano - its a great product that I use almost every day. I introduced it at one place I worked and it took deployment time from painstaking hours to minutes. Thanks very much for your efforts and I am sorry you feel the need to step down from maintenance.
damncabbage 13y ago
Thank you so very much for your efforts. We use Capistrano at Bigcommerce to deploy our apps and components, and it's saved us from an inevitable pile of shell scripts. :-)
r7000 13y ago
I have never commented anywhere about Capistrano. But, it has been part of a toolchain that has brought me success and improved my life. Thank you very much for all you have done.

ealexhudson 13y ago

A good decision - get out while things are still positive. Not enough people are brave enough to step down at the right time (or even when it's obvious it's already the wrong time).

gnufied 13y ago

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 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 https://launchpad.net/~brightbox/+archive/ruby-ng ?

codebeaker 13y ago
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.

AhtiK 13y ago

Does anyone know what's wrong with the Rails asset pipeline that is mentioned in the post as one of the issues?

codebeaker 13y ago
There's a number of problems, but foremost is that there's no good way to "roll back" assets, and there's no concept of keeping assets that might be used by old versions of pages cached in CDNs, when they have been replaced by newer assets. This is a problem of the manifest system, and of the `assets` directory always representing the current newest state, not the collective state since the beginning of time. Maintaining state from the beginning of time would bring it's own problems, thus many of the workarounds about tracking old, and new assets are time consuming and sub optimal, and unfortunatley people need them. There's a cap task which touches `mtimes` of all referenced assets, which can typically take 5 minutes to complete. It's naïve, and stupid, but it's the only solution (that we could come up with) to a real asset pipeline problem. I'm also of the opinion that compiling assets in production as a part of your deployment process is insane, there's so much magic in the Rails asset pipeline that it's not uncommon to turn up bugs where tables don't exist, and the rails app can't initialize, or some javascript runtime environment isn't found which can leave your deployment in a broken state. I'm firmly of the opinion that assets should be compiled and checked in, but then of course you run into problems with rails serving those in development mode, rather than the development files. All these issues are fixable, but they're all indicative of tools that aren't quite mature yet, and as Capistrano sits on the boundary of where these problems come to light, it seems to fall to us to deal with it, and to educate people on what they ought to be doing. Education is no problem, I really believe that the de-facto standardisation of Rails-like deploys (i.e timestamped releases, with common linked directories, and a symlink to the current active timestamp) is an excellent result for knowing what to expect in an environment where there's hundreds of ways to get Rails apps running, but it's still not as smooth a process as it could be. I'm familiar with at least one project that's been re-written in Scala and Java because the previous version was prohibitively difficult to deploy as it was in RoR. (GrayLog2, to namedrop them)
- kaffeinecoma 13y ago

chrismealy 13y ago

I love ruby and rails, but yeah, I'd switch to any framework in any language that made deployment stress-free. Except php.

keypusher 13y ago
Python with virtualenv and pip has been fairly stress free in my experience.
- kawsper 13y ago
  I feel Python apps is quite a pain to install. I had to deal with a Graphite installation, and it consists of 50% packages from apt-get and 50% of packages from easy_install. https://gist.github.com/kaspergrubbe/5792356 https://gist.github.com/kaspergrubbe/5792356 Is this an issue with Graphite? Because I feel this setup is quite elaborate compared to using Rubygems and bundler.
  - shabble 13y ago
    That's a rather alarming install script, especially things like: sudo apt-get --assume-yes upgrade in it. But to your point, I think most of the easy_install packages could be handled by pip. The apt packages look like almost all non-python major components like rabbitmq, apache, sqlite, etc which are best provided that way. I'm not sure about Graphite itself, but at a quick glance it's not clear why it's all 'sudo python setup.py' rather than in a package.
  - gingerlime 13y ago
    From experience with both python/django and ruby/rails, I think python is generally simpler. Start with the fact that python itself is usually pre-installed on most distros, and usually a recent-enough version to get you started. Ruby on the other hand is much harder to just get installed, choosing the right (minor)version, rvm/rbenv choices etc. I tend to compile my ruby, but it's a lengthy and rather fragile process. Graphite is both a good and bad example. Good because it is really complex and documentation is a little sketchy. I've written a fabric script[1] that automates the process, and it's far from trivial. Bad example, because it's not really a single app, but a system - a collection of tools with dependencies. Even if we discount the web server (nginx or apache?), it includes things like the core "database" (whisper), the event listener (carbon, which in itself is complex depending on your setup), the graphic and processing libraries, and then graphite which is a pretty involved django app with its own sub-components. So when you say graphite, it's really a full-blown system with lots of moving parts that need to fit in together. I can't think of an equivalent example in the rails world, but any rails app with a db, caching layer, and a few other external components won't be much easier to get set up and running. [1]https://github.com/gingerlime/graphite-fabric https://github.com/gingerlime/graphite-fabric

bretthopper 13y ago

Some unsolicited advice from someone who's never run an open source project as popular as Capistrano: * Ditch v2 ASAP (seems like you've already decided on this). It's pretty obvious you aren't motivated to work on that codebase anymore. I've looked at v3 and it's much better thanks to relying on Rake tasks. * Be selfish. It's your project so if you think v3 is the way to go forward, go with it and who cares what the "community" thinks. * Seems like you already have a few people helping out, so continue and maybe make formal "core" team. There's nothing with yourself taking a step back from the heavy coding. But I believe that Capistrano would be better with your guidance than without it. codebeaker: There was no mention of Harrow in that post. Are you still working on that? I'd assume that if you were you'd continue work on Capistrano since it's based on it.

codebeaker 13y ago
Regarding Harrow [1] bretthopper, I absolutely am, and this is where I want to focus my work, and to be able to build a company around deployment best practices and Capistrano. Regardless of frameworks, and of technologies and platforms, I believe if I can take the load off myself with Capistrano, by turning it into the open source component of a best-practice company, and build teams of passionate, skilled support engineers, then I'll be where I want to be. Unfortunatley Harrow would suffer if I give up on Capistrano, as part of the promise of Harrow as a SaaS is that it's all guaranteed to stay compatible, and work as we've all come to expect, just with improved workflow, etc... ([1] http://www.harrow.io http://www.harrow.io, please excuse the missing graphic placeholder I've not updated the landing page in some time as I've been focusing on building the product, and the landing page performs really well without that graphic in place)
- diminish 13y ago
  Lee, why not try the sidekiq way? A capistrano pro, and a hosted managed version or maintenance fee...
canes123456 13y ago
Also, charge for support. List supported platforms and charge for support for strange configurations.

alrs 13y ago

As always, it bears repeating: rvm/rbenv don't belong in production. They exist to allow developers on Macbooks to sync their version of Ruby with whatever is packaged in the Linux distro or BSD variant that runs in production. If I had a Mac I'd skip the ad-hoc Ruby environment switchers and skip straight to Vagrant.

3pt14159 13y ago
I used to agree with you. Why would you take a 20 or 30 percent performance hit when you are busy shelling out tens of thousands for hardware load balancers. Then one day a rare instruction set on our colocated server (so not something super standard like linode) was specified during the compilation step of ruby and (due to an extremely subtle co-bug between ruby and the compiler). It took us fucking weeks to find this hisenbug that was somehow causing workers to drop, but only during times of very high load. Probably lost $500k worth of customers, dev time, and company moral. Now I have a different view. Keep things as simple and as "normal" as possible. That way you can always upgrade to the next version, you don't hit weird bugs when you libraries assume that Time.now is second-accurate, instead of sub-second accurate (MRI vs Enterprise Ruby). RVM is made for production (http://stackoverflow.com/a/6282260/384700 http://stackoverflow.com/a/6282260/384700) and it saves a lot of headaches to just go with the flow. As for mac dev, I agree that it is a waste of time compared to working out of Ubuntu, but designers like photoshop and Vagrant is non-trivial for them to set up, especially for people that work on multiple projects.
- alrs 13y ago
  I'm confused. Simple and normal, to me, means "use packaged Ruby." Chasing the bleeding edge and compiling the interpreter at every release is exactly the sort of practice that introduces edge-case heisenbugs. If you need a nonstandard compile-time option you go to work on the package source, make the change, put your custom package up in your private apt/yum repo, and leave things alone until the next security update comes down the pike. Me, I consider hosting to be entirely fungible. I'd rather change vendors than mess about with custom packaging big chunks of the stack to work around weirdness. Wherever I have encountered Phusion's REE I have ripped it out, with good results.

AlexMuir 13y ago

My first thought was "I owe this guy, Capistrano is the main reason why I have spent ~ $100 per year on VPS servers and not $100 per MONTH on Heroku et al. I'd suggest Lee runs a Kickstarter type thing and I'd very happily throw in $100. But I don't think he will because it doesn't seem quite right. So here's a (wild and completely off the cuff) startup idea - a pre-emptive Kickstarter. Someone creates the project "Lee Hambley, continue working on Capistrano." and we all pledge into the pot. If Lee agrees to do it, he gets the money. If not, we don't pay anything.

forsaken 13y ago
Or just give them money on something like gittip. Things like this need to be sustainable, not just a flash in the pan of $10k, then going back to having nothing.

kawsper 13y ago

I am a bit sad that he feels this way about it. I have used Capistrano a lot, I built my "default" setup, compiled it into a gem, and released it here: https://github.com/kaspergrubbe/simple-capistrano-unicorn https://github.com/kaspergrubbe/simple-capistrano-unicorn and moved on with my life as a developer. I know of at least two bigger organizations that depend on Capistrano (and my gem) for their deploys. I feel like Capistrano is the way to go if you manage your own servers, and need to deploy to them. Capistrano started my Rails experience, and I am very grateful for the work put into it. But I never wrote and said "Thank you" or "Great job", maybe we need to be more vocal to the people that put in time and energy to build the software that we use a lot.

forsaken 13y ago

I just wanted to point out how poisonous our community is. It's something that I've been struggling with for a long time, and trying to slowly change. The fact that people read this article, and don't feel the need to mention his fear of releasing software just shows how broken things are. It shouldn't be an accepted fact of open source that if you release new code that might be backwards incompatible, you get vitriol for it. His quote: ... but I too cowardly to release it and make it mainstream, as Im afraid it'll destroy whatever good will for open source I have left when the flood of support questions inevitably comes in, followed by all the people who are unhappy with what I've built and feel obliged to tell me how bad I am at software.

avenger123 13y ago
I can't comment on the poisonous nature of the community but what I have noticed is that at some point its taken for granted that the open source solution will be very stable and solid. It seems (and this is just entirely my opinion) that it is forgotten that people are doing this out of their own goodwill and are not necessarily being paid for it and really have no contractual obligation to keep doing what they are doing. It's almost the worst of both worlds. You get all the responsibility for having your open source project be considered at the same level as a commercial solution but without it actually being a commercial solution.
leoh 13y ago
> I just wanted to point out how poisonous our community is. It's something that I've been struggling with for a long time, and trying to slowly change (from inside the python community). Do you mean to say that the Python community is poisonous? Or that the Ruby community is poisonous from the perspective of a Python community member?
- avenger123 13y ago
  I didn't put too much weight on whether it was Python or Ruby. I felt it was a statement about the whole open source community rather than a particular group.

joeblau 13y ago

It's sad to see when an open source project becomes overwhelming. On one hand the project is open source, so hopefully, someone else can pick up the torch. We saw this happen in the node.js community and node's been moving along. On the other hand, based on what Lee is saying, it looks like situation is pretty bleak. I'm not a Rails user, but I feel like most of the "hot-startups" in San Francisco run a Ruby stack. From an observer looking into the community and platform though this post, I never realized how many challenges there were in that development environment.

patio11 13y ago

Thanks for creating software which has been an immense service to the community, and which I rely on quite a bit. Tangent mode on: Somebody really, really needs to write the How To Deploy Rails Without Losing Your Sanity handbook. I will buy a copy. It will sell thousands of them. A lot of the problems with people's interactions with Capistrano are environment/ops problems which have known solutions that work, but which rely on people having a great understanding of arcane trivia which is spread across conference presentations, blog posts, commit messages, and the practical experience of the best Rails teams. Unless you're prepared for an archaeological expedition every time you start a new Rails project, you're going to do something wrong. You should see the bubblegum and duct tape which I came up with, and it mostly works, but I know it is bubblegum and duct tape. Example: Non-deterministic deploys of code from (usually) un-tagged source control I feel lucky in that I was mentored by an engineer who decided to teach me, one day, Why We Tag Shit. But for the Why We Tag Shit discussion, I would be like almost every other intermediate Rails engineer, and be totally ignorant of why that was a best practice until lack of it bit me in the keister, at which point the server is down and one has to rearchitect major parts of the deployment workflow to do things the right way. Why We Tag Shit is only about a 500 word discussion, but it's one piece of organic knowledge of the hundreds you need to do things right, and it is (to the best of my knowledge) not covered in docs/QuickStarts/etc because that seems to be out of the purview of the framework proper (I guess?). I'm sure that I'm ignorant of several of the hundreds of pieces of things one needs to do to do deployment right, as evidenced by my fear every time I execute my deploy scripts. I, and I must assume many other companies, am willing to pay for an option which gets me to a non-bubblegum and duct tape outcome. Seriously, folks: there is a product here.

raverbashing 13y ago
I'll be downvoted by the "newer generation" but here's a pet peeve of mine The same reason "why we tag shit" is the reason downloading packages from gem/pip is not enough Who guarantees that when you do your deploy, the library you need is there? How many times did your build break because it had a glitch downloading the package? Keep a way of rebuilding and deploying your software. All of it
- 13y ago

grandalf 13y ago

Check out fabric as a much faster alternative to Capistrano. Combined w cuisine.py it's a simple and powerful alternative to chef solo.

yannk 13y ago

"Whilst I believe strongly in Capistrano as a general purpose tool [...] I do think the future of software deployment is in small, containerised VMs and so-called PaaS, as what we're all doing right now has to end, some time." Kudos. It takes a lot of courage to admit your baby is not going to fulfill the future you had initially imagined.

stevewilhelm 13y ago

Check out 'Deploying Ruby Applications to AWS Elastic Beanstalk with Git' [1] [1] http://ruby.awsblog.com/post/Tx2AK2MFX0QHRIO/Deploying-Ruby-Applications-to-AWS-Elastic-Beanstalk-with-Git http://ruby.awsblog.com/post/Tx2AK2MFX0QHRIO/Deploying-Ruby-...

machbio 13y ago

Thanks for the awesome software.. I just started learning about capistrano recemtly, just amazed by how simple it is.. I believe when you said that PAAS will go, only reason I use heroku and dokku(from docker) is due to its easy deployment.. and for no other reason than deployment..

tomdefi 13y ago

For anyone interested in an overview of Capistrano v3, I wrote an introduction last week - https://medium.com/p/ba896a142ac https://medium.com/p/ba896a142ac

codebeaker 13y ago
Tom's article is a really great run down of all the awesome things that we built.

wbogg 13y ago

Everybody can earn 150$+ daily... You can earn from 4000-9000 a month or even more if you work as a full time job...It's easy, just follow instructions on this page, read it carefully from start to finish... It's a flexible job but a good earning opportunity.. go to this site home tab for more detail ..... big57.ℂℴM

joevandyk 13y ago

Really looking forward to Docker being 1.0. What you want to do is build a single package of everything your application needs (which includes the application code and all dependencies -- libc and up), then copy that package to the production servers. It shouldn't matter if your application server has Ruby 1.9.3 and you need 2.0. It shouldn't matter if the last deploy of your app needs Nokogiri compiled against libxml 2.8 and you now need 2.9. It shouldn't matter if you are running 5 different apps with 5 completely different set of dependencies on the same machine. It shouldn't matter if you need to use the asset pipeline. It shouldn't matter if github or rubygems drops out half-way through the deploy process. All the production server should get is a single package of all that your application needs, then a 'restart application' command. Docker should be able to handle all this simply.

joaomsa 13y ago

Capistrano really has saved us multiple times, sad that a vocal part of the community tends to exhibit such behavior. At our company, we develop multiple RoR apps and we've run into many of these issues (mostly related to the asset pipeline), yet none of them actual problems with Capistrano. Since it's the bridge between so many things, I can imagine why it's easy for it to become cannon fodder. We've tried to standardize many of our recipes such as local asset precompilation into a single cohesive gem (https://github.com/innvent/matross https://github.com/innvent/matross). That has saved us the trouble of debugging the same issues over and over when they inevitably pop up across applications.

deleted 13y ago

[deleted]

ChikkaChiChi 13y ago

As much as this is an open invitation to rail on the RoR community, I think this is a problem that is a lot more indicative of this brave new software culture both open source and (independent) commercial. If your tool sees any sort of uptake, it suddenly no longer is yours. The community suddenly expects you to not only to continue to modify the base code to improve functionality, but to also adhere to a sort of backwards compatability so that everything they know and loved about your baby never changes. I can't imagine how much more taxing this would be once the tools you built become integral part of other team's workflow. The burden and stresses of keeping "the world" afloat would cause many a sleepness night for people of strong constitution.