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
Best Answer
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 :-)
gem install capistrano
(note, typically this doesn't belong in your Gemfile)capify .
Createsapp/Capfile
andapp/config/deploy.rb
load 'deploy/assets'
myusername@github.com: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 samerequire "bundler/capistrano"
at the topset :deploy_to, <remote installation path>
maybe"/var/www"
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:
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
andcap 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) callstouch app/tmp/restart.txt
to cause the server to restart.Better?