Typically, a Ruby on Rails web-app (or any stack on JVM, .Net, Python, Node.js or PHP) needs to be deployed on two or more remote servers, at least one for staging and one for production.
This is an updated version of the tip as we were migrating to Rails 4 and Capistrano 3
Since we're using git, we have at least three branches
- master where everything that is working and ready for deployment are
- staging for version to be tested on staging server
- production for the production-ready codebase
master ->(mergeto)-> staging ->(mergeto)-> production
This process won't raise any merging issue as the workflow is linear and git will do it by fast forwarding the commit points. All the issues happens when merging various dev branches to master, but that's another story :)
When comes time to deploy frequently, it became annoying to repeat the
git checkout ... then
git merge then
git push then
cap deploy sequence.
I created a simple bash script to abstract all those steps.
The time saving scripts
#!/usr/bin/env bash git add . && git commit -am "$1" && git push origin master && git checkout staging && git merge master && git push origin staging && git checkout master && cap staging deploy
Save this under RAILS_ROOT/bin/deploystaging and make it executable
chmod u+x bin/deploystaging
The same for production
#!/usr/bin/env bash git checkout production && git merge staging && git push origin production && git checkout master && cap production deploy
Save this one under RAILS_ROOT/scripts/deployproduction and make it executable
chmod u+x deployproduction
Now after working on any branch and merged changes to master, all tests green, do
cd RAILS_ROOT ./bin/deploystaging "Commit message here" #OR ./bin/deployproduction
Capistrano 3 is smart enough to detect any pending migration so no need anymore to flag migrations like on Capistrano 2.
That's all, have a nice deploy !