Deploying a third-party Rails application - like Gitlab

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.

1git 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.

1git remote add origin git@git.ariejan.net:my_git_server.git
2git push origin master
3cap 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?

1git 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.

1git merge upstream/master

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

1git push origin master
2cap 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.

Written by