Saying goodbye to GitHub

Here at Old St Labs we’re always looking for ways to improve the way we work. We are a small team so improving the way we develop and test product is paramount. We decided to say goodbye to GitHub and this post details our reasons and what we’ve learnt along the way.

We just want to make it clear that we love GitHub and we think what they have done for our community is fantastic. As we have grown we started to find problems in our deployment pipeline that set us on a hunt for alternatives.

Where it all began

Our development processes are centred around Continuous Integration. Testing is a first class citizen throughout our product development lifecycle. We deploy several times per day, for this reason ensuring that changes are well tested is paramount.

We made the leap into continuous integration coming from a rather crude use of fabric. This was something a few of us had experience with which made it a good choice in the early stages of the product. As the team grew so did our efforts into testing.

We wanted to get our test suite running as a pre requisite to deployments which is when we signed up for circle-ci. We continued to deploy via fabric providing the tests passed on circle-ci. We opted to continue with this approach so that we had time to adjust to this change in process. After a few more weeks testing, we started deploying to production. Our continuous integration system (CI) system was born.

Can you smell ice?

After a while, with continuous integration in place, we started to have reservations about certain aspects of the system.

1. During a certain period GitHub were having to mitigate constant DDOS attacks. Our entire deployment process hinged on GitHub which was pretty frustrating during these outages. We noticed builds not starting on circle-ci in a few cases as web hooks got lost or never sent

2. Our infrastructure sits on top of AWS inside of a VPN. Security is a big thing for us in the enterprise space. We had scoured the web and found Freight, a tool from the team behind Sentry, which acted as the deployment API. Even though it solved a lot of problems for us, the fact that we had part of the infrastructure open so builds could triggered made us nervous. (we should note that freight was pre-production release during our use and it was even great then)

3. As the number of builds ramped up we noticed a significant slow down in our ability to get changes live. We were running a single container on circle-ci which just wasn’t enough. The hefty $50 price tag for extra containers didn’t appeal either (especially given their average performance).

4. GitHub’s change in pricing model was also a contributing factor to our decision to leave. We had more team members than private repos. Paying $9 for team members that only review issues seemed excessive.

Saying hello to GitLab

A friend of ours had recently been implementing an interesting architecture with docker. We had also been exploring what docker had to offer so we got together to nerd out and chat all things dev-ops. He mentioned that they had decided to switch to a self hosted GitLab installation and began reeling off the long list of benefits. We were immediately sold.

A few members of the team had worked with GitLab before but it was clear it had come a long way since then. So what was all the excitement about?

GitLab community edition comes with an integrated CI system! This was a massive sell point for us. We could self host the entire thing inside of our VPN and stop exposing APIS to allow external services to trigger deployments. GitLab’s multi-runner has been great to use, it’s feature packed and best of all its been extremely stable.

Having your code, pull-requests and build information all in one place is a really great thing. Having all the information in one place has helped to keep the development and QA teams aligned.

Another huge factor in our decision making is the fact that GitLab is totally free. It’s testament to our community that something as feature rich as GitLab is free for people to use!

Whilst maintaining the GitLab service was a consideration, we felt that being able to react to issues was better than our process completely collapsing during GitHub outages.

All in all we have been extremely happy with our decision. We’ would certainly recommend it to anyone looking to take more control from their CI processes.