#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.

Deploying Rails: Automate, Deploy, Scale, Maintain, and Sleep at Night (The Facets of Ruby)
Buying options
View on Amazon.com
or
Used Book in Good Condition
Specs:
Height9 Inches
Length7.5 Inches
Number of items1
Weight1.1 Pounds
Width0.8 Inches

idea-bulb Interested in what Redditors like? Check out our Shuffle feature

Shuffle: random products popular on Reddit

Found 1 comment on Deploying Rails: Automate, Deploy, Scale, Maintain, and Sleep at Night (The Facets of Ruby):

u/evilduck ยท 3 pointsr/rails

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).