Ariejan.net has moved and is now available at https://www.devroom.io

Deploying a third-party Rails application - like Gitlab

18 November 2011

We all know how to deploy our own Rails projects. (If not, read this guide.) But how do you handle deploying a third-party application that may require some customisation on your part?

A good example would be Gitlab

Gitlab is an open source Github clone, build using Ruby on Rails. It’s a nice project that uses Gitosis under the hood to manage your git repositories. There are several good installation guides available on the web, but they all assume you want to deploy gitlab verbatim - without any modification or configuration

I have also setup Gitlab, but I want to use capistrano and unicorn. I also want to tweak some configuration. In some rare cases I want to fix an annoying bug and not wait for the Gitlab team to pull it.

Doing a git pull on my remote server just won’t cut it.

Fork! Fork!

What I did was clone Gitlab and use the same principles describe in my Contributing to open source with Github to apply my own changes and merge any upstream changes when they are available.

Here’s how I set everything up.

First, clone the official Gitlab repository and name it upstream.

git clone --origin upstream https://github.com/gitlabhq/gitlabhq.git my_git_server

Next I made all the changes I want. I updated config/gitosis.yml and unicorn to Gemfile and setup Capistrano.

I then pushed this to my own git server. This is the same server Capistrano will use to pull changes from.

git remote add origin git@git.ariejan.net:my_git_server.git
git push origin master
cap deploy

That’s all there is to deploying Gitlab from my own repository.

Merging upstream changes

Now, the Gitlab crew is pushing out new features at an amazing rate. So, how do I get those new features (and the occasional bug fix) into my copy of Gitlab for deploying?

git fetch upstream

Remember how we named the official Gitlab repository upstream earlier? With this fetch we get all changes from their repository (but we don’t apply them to anything yet).

Then, merge the upstream changes with your own branch.

git merge upstream/master

There may be merge conflicts, just resolve them and commit your merge. Then again to deploy:

git push origin master
cap deploy

Why do this?

The reason I use this approach is that it’s easy to merge upstream changes and have my own customizations and deployment tools at the same time.