The solution is pretty simple, if you use git. This quicky will show you how I’m currently doing it.
Multiple remote repos
All our projects have their origin on our own servers, and then either have “github” or “rubyforge” remotes for public changes. This works very well, especially allowing the team here to work on ideas for a couple of days and deploy to a staging/production server for review. Only once we’re happy do we push the code back to the public.
Basic idea is that our public master branches should always be deployable. Nothing sucks more than getting a OSS project and it doesn’t work out the box…
Enter the deploy branch
We all have a tracked “deploy” branch, which exist only in our private repos, not on Github/RubyForge. This deployment branch was used just for our capistrano recipes. As of this week I decided to through hoptoad in the mix as well, which great reward already.
The principle is so simple, hopefully the flow below explains the process.
Master is either your code, or a clone of someone else’s, and the deploy branch contains your modifications for your environment. In our case its capistrano recipes and hoptoad, but could include New Relic’s RPM as well (or anything else).
The deploy branch should have only additions, and no other changes are made to the deploy branch ever. If you accidently merge deploy back to master, you’ll have a tough time undoing the damage.
Well, if you maintain your own remote repo of another project, then make sure that repo has your deploy branch at configure capistrano like such:
set :branch, "deploy"
If you don’t want to maintain your own remote repo, but want a local deploy branch, you’ll have to switch to copy deployment recipe (something like this):
set :deploy_via, 'copy' set :copy_strategy, :export set :copy_cache, true set :copy_exclude, ['.git'] set :repository, '.'
BIG FAT DISCLAIMER: I’ve never used the above copy strategy myself, so I cannot vouch for it!
Well, this neat feature of git allows us to deploy and run our OSS projects as if we were the only users. Sensitive information is not exposed to the world, but is still recorded by hoptoad. It allows us to get the real exceptions as they happen in the wild, without guessing what happened when some logs a “It doesn’t work!!” ticket.