#3,171 in Computers & technology books
Use arrows to jump to the previous/next product
Reddit mentions of Deploying Rails: Automate, Deploy, Scale, Maintain, and Sleep at Night (The Facets of Ruby)
Sentiment score: 1
Reddit mentions: 1
We found 1 Reddit mentions of Deploying Rails: Automate, Deploy, Scale, Maintain, and Sleep at Night (The Facets of Ruby). Here are the top ones.
Buying options
View on Amazon.comor
Used Book in Good Condition
Specs:
Height | 9 Inches |
Length | 7.5 Inches |
Number of items | 1 |
Weight | 1.1 Pounds |
Width | 0.8 Inches |
Every dev could have an account and personal RVM or Rbenvs installed and whatnot for publically demoing an idea on an alternate port or just to monitors logs or whatever (just be mindful of their resource usage if that's something you want), but sudoers should be limited to people you have confidence in maintaining the system. The more vital uptime is, the less people who should have system access (maintain a trail of responsibility).
Capistrano should be a sufficient starting point for a straightforward single Rails app being deployed to a VPS. I would opt to run the app under it's own user account and manage your Ruby version through RBenv and not bother dealing with installing new Rubies (and gems) system-wide and the permission issues that comes with. Passenger supports running a site as a specific user, and you just have to set the Ruby path when configuring.
You can give everyone you want to allow to deploy to production their own private SSH key for the 'deployer' account and turn off password logins for that account entirely, and then everyone can deploy without needing to hand out a single set of credentials (and you can revoke access to anyone who becomes a problem by removing their SSH key from the deployer account and keeping the ./.ssh directory owned by a different admin user).
There's actually entire books dedicated to this topic though, and it's hard to give blanket advice since it's so contingent on your app's design, the mutual trust in the developer's abilities, etc. When you start having scheduled tasks and queues, and background jobs deployment configuration can get pretty hairy (which is why people love PaaS solutions).