Open Sourcery

It came down on me like a ton of bricks when I deployed the audit updates to our production PowerDNS on Rails setup, hoptoad isn’t installed and any errors would just be gone and forgotten.

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.

Capistrano config?

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!

Results?

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.

Just as a quick update on the PowerDNS on Rails project, I’ve just pushed several updates to Github that most profoundly includes support for audits. Other smaller changes are also included, including plugin updates (HAML) and upgrading Rails to 2.0.4. As always, these updates have been running in production for a couple of hours already and has solicited some review from our support staff. Undoubtably there will be a lot of tweaks to the feature in the coming days…

Next on the radar is authentication tokens, allowing to give users one-time access to a specific domain for performing updates.

We’ll keep you posted!

Jeff has a great article on the Ruby Olympics, and I couldn’t help to add my 2c to the discussion, so here goes:

Consume Podcasts

I’m an avid listener of (and got mentioned on) the Rails Envy Podcast. I also follow the Ruby on Rails podcast, the Web 2.0 show and the Boagworld podcast.

Podcasts are great way to get information in manageable dosis. I spend close to 2 hours every day commuting, and I’ve decommissioned my car radio altogether so I can just listen to these podcasts and other random audio clips. The value you gain from these shows are unbelievable.

Open Source something

I don’t mean build the next Rails. I published ActiveRecord::Tableless for two reasons, the first being that the original source disappeared of the face of the internet. The second, and most important reason was that I needed something (even if it was so small), to put outside and receive critique for. Those last couple of moments before you publish a gem can be a killer, it really makes you doubt the quality of your code, your documentation, your blog’s project page, all that and more.

It is also very rewarding, especially with bigger projects like PowerDNS on Rails, when people start forking your code and contribute patches. Even ActiveRecord::Tableless got some patches, I couldn’t believe it.

Spread out

Jeff also noted how important it is to learn Ruby, not Rails. I’m fortunate enough that Rails is the lessor part of my day to day work, and Ruby is the biggest part. I’m not dissing Rails, merely indicating that a lot my work arounds glueing independent systems and architectures together. More recently I’ve gotten extremely intrigued by XMPP and the possiblities it holds.

I’ve written my own crawlers, and burned my fingers. I’ve written jabber bots for distributed process, also burnt my fingers. I’ve been privileged enough to play with some bug EC2 deployments. I give regular lectures at tertiary institutions around Gauteng, South Africa, and have recently met the guys behind the eschaton plugin on a trip to Cape Town.

Dare to move outside your comfort zone, it is rewarding.

In close

Being a true Ruby olympian does require you to have various skills. Don’t try to master them all, but master some. In time as you improve and learn your interests will adjusts and your skills improve. In the end its all Ruby, so exposing yourself to the world beyond Rails is really priceless.

Let the games begin.

Today I finally had to “extract” a project from one of our biggest repos as part of a git migration plan. I’ve converted most of the other smaller projects in the same repo over using just their trunk, and it has worked without any noticeable issues. Now the project in question has several active branches and important tags. Our repo layout is something to be a shamed of, and git-svn likes “standard” subversion layouts.

I found this thread on KernelTrap, where one user has a similair layout to ours and faced the exact same predicament. The thread is interesting, and the people offer some good tips and advice. Although most of them just seemed “wrong”.

I proceeded to get a copy of our live repo onto my laptop for a simple test. Using a quick svnadmin dump/load combo I had a copy to play with. I sat with a team member, and several svn manipulations later we had restructured that project’s layout to be more svn-like. I then commenced to use the standard git-svn import tool and it pulled in all the branches, tags and trunk for the project in without breaking a sweat.

So, importing from svn with full history from a non-standard repo layout isn’t a daunting task after all.

Just one friendly warning though, if possible, get rid of as many unused branches and tags as possible before importing into git. The full history can get very messy in some cases, and in others a clean slate will be welcomed by the team…

Hope this helps someone else to jump ship easily