Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Capistrano, Rails 3.2, standard recipes?

I've been developing Rails for a while, but somehow avoiding using capistrano until now.

Trying to figure out how to get started, I've gotten confused about the best capistrano recipe for a fairly 'standard' rails 3.x with asset pipeline deploy. Perhaps because looking around on Google, one finds 'answers' from various parts of history, with different historical periods when different things were built into cap.

I've got an app I keep in git, rails 3.2, with asset pipeline, deployed to only a single host with passenger.

Thinking about it, I basically need cap to:

  • deploy from git?
  • make a tag in git for the deploy (and/or use a deploy branch? Whatever is most standard in cap, if there is such a thing)
  • bundle install --deployment
  • rake db:migrate
  • rake assets:precompile
  • touch tmp/restart.txt

Oh crap, one more possibly weird thing:

  • think I'm going to use a system-wide rbenv install on the deploy server. Not sure what that entails.

What's the most standard, easy, simple, maintainable way to have cap do all these things? Is there anything I'm missing? If some of what I've specified is not standard, I'm happy to use the standard best practice instead (with maybe an exception or two, I really want a git tag for each deploy, even if that's not a standard best practice, although I'd think it would be, have gotten confused looking at docs how it works)

Is there an easy answer here?

EDIT: Yes, I've looked at the Cap wiki. It may be because I'm slow, but I've found answers to NONE of my questions there. There isn't even a 'getting started' document. There is no documentation of what a default out of the box cap recipe actually does. etc.

update: I wrote my own guide aftering figuring it out. https://gist.github.com/2161449

like image 500
jrochkind Avatar asked Mar 19 '12 16:03

jrochkind


1 Answers

Well, not having to use capistrano is a blessing :-). I grew to dislike it, but in fairness, it has gotten a lot better, and the doc here https://github.com/capistrano/capistrano/wiki/ addresses most of your issues -- the section on RVM might suffice as an alternative to rbenv. Your configuration should pretty much work with an out-of-the-box capfile.

EDIT: yeah, you'll need to do the tagging yourself, but the key is to think of the methods you write in the capfile as just system commands (remembering you probably don't have your normal shell path and other environment). Follow the examples of other git commands and you'll be fine.

EDIT: Better answer (maybe :-)

  • Go here: https://github.com/capistrano/capistrano/wiki/2.x-From-The-Beginning
  • gem install capistrano (note, typically this doesn't belong in your Gemfile)
  • cd
  • capify . Creates app/Capfile and app/config/deploy.rb
  • You're using the asset pipeline, so in Capfile uncomment load 'deploy/assets'
  • Now, look at the deploy.rb
    • application name is a name like "my_application"
    • repository is the URL to your source control repo, e.g. [email protected]:yourrepo/yourproj.git
    • scm: git (right? If not, same idea: URL above and this for SVN, or whatever)
    • role :web "www.example.com" and since your :db and :app are all on one box, those are the same
    • you're using Passenger, so uncomment the lines as directed.
    • not sure but you might have to require "bundler/capistrano" at the top
    • you'll need a set :deploy_to, <remote installation path> maybe "/var/www"
    • follow the other steps in the guide
    • hypothetically after these and the steps I missed, check all of this in, and make sure your app is checked in (and pushed if git), and do the cap deploy:setup

Hypothetically, setup will configure your server accordingly. Most likely error here is that your current machine needs permissions to ssh to the remote machine, and the remote machine needs access to the source control repository. Public keys are your friend.

After this, the workflow is:

  • make changes
  • test locally
  • commit, and push to git
  • cap deploy migrations (the migrations part is only necessary if you have done any)

Most organizations have some sort of staging or test servers. Look for "multistage" to get it so you can do cap test deploy and cap staging deploy etc.

To deploy a branch (and I think a tag) on git it's cap -S <branch/tagname> deploy (make sure it's capital S, might be lowercase).

Once you get this going, there are probably things you'll want to do before or after the deploy -- for example sending email, regenerating a sitemap, backing up the database and so on. Use the before or after hooks to write your own tasks.

So the worst part of capistrano is that all the doc assumes you know what the hell it does. In a nutshell, it uses ssh (ruby's net-ssh) to execute commands on a remote server from whatever local workstation you deploy from. It looks at the head of your source tree (or tag or branch if specified), pulls that into a new location on your server, does anything else (migrations, asset precompilation) and gets the app ready; once it looks good, it changes a symbolic link (e.g. /var/www/current to point to the new location and then (in the case of Passenger) calls touch app/tmp/restart.txt to cause the server to restart.

Better?

like image 69
Tom Harrison Avatar answered Oct 13 '22 23:10

Tom Harrison