Transcript: Why Codepen moved from GitHub to GitLab

In episode #114 of Codepen’s podcast Chris Coyier, Rachel Smith, and Tim Holman talk a lot about the differences between GitHub and GitLab, why they decided to make the change, and how the team managed the switch.

Spoiler: Yup, they replaced GitHub, Codeship, Trello and time tracking with one open source tool, and this is impressive!

Below is my partial and inaccurate transcript:

Control

1. It is difficult to get the code out of GitHub and put it to our VPC(private network). Pulling and pushing code requires a bunch of deployment keys.
2. Can’t use internal resources.
3. It was about gaining control
4. We just spawned up another Amazon EC2 instance with GitLab, and all of our code now lives there
5. With GitHub, we had to extract our code and put it into our infrastructure. GitLab — is just a part of our infrastructure.

Uptime

1. When GitHub is down, everybody is just walking around with a cup of coffee
2. The worst part is when your CI is tied to GitHub
3. It makes no sense to make your internal staging server to depend on external thing(GitHub)
4. It is still git, and you can work locally, but if your deployment depends on 3rd party services, that sucks
5. Usually, your CI & CD infrastructure had to depend on a centralized thing like GitHub or GitLab. When it is down, we’re screwed.

Higher Security (Code in our own network)

1. We’re not a target for hackers. No way to access our code anymore.
2. Our code is now locked down inside our VPC(private network)
3. If one day there will be a security incident on GitHub, it means that everyone’s private code is exposed

Certainty

1. You don’t necessary get 100% uptime when you host GitLab by yourself
2. If there’s something wrong, you can fix it by yourself.
3. If GitHub is down or under DDoS, you may or may not be able to push your code for the undetermined amount of time. Zero control — the worst feeling that you can have: Hey, I really can’t do anything at all.

Is GitLab copycatting GitHub or not?

1. It was a clone of GitHub at the beginning
2. In the last year, they pulled ahead of GitHub in a feature set that they provide
3. CI & CD is a major difference. Typically you had to have two services for that. GitLab does not require this. With GitHub, you can do it only with 3rd party services.

Deployment

1. When everything is now on the same local network, we can make a step further and not only use CI for testing but also deploy with it.
2. You can do it with other services too, but GitLab makes it really simple.
3. Before we had command-line deployments, which means no control on who has deployed what and when to which server.
4. With GitLab it is all visible — I see who made the last deploy to production
5. In case of regression, it is very easy to see who has touched what, and what was going on with that production build
6. Before it was hard to say, because it was done from developer’s machines, and there was no record of it.
7. We do not deploy from our machines anymore
8. Both automatic operation on every push plus manual steps, which previously were separate little personal bash scripts: spare some disk space, see what version is pushed to production, etc
9. With GitLab it is now shared knowledge visible through UI — now they are manual steps in our pipeline. It allows anyone in our team to perform those actions
10. Rollback is a way easier with automated pipeline — you just go to an old build that I know was working, and rerun it
11. With GitLab you don’t get deployment and the rest of it out of the box. You have to build this thing by yourself by yourself. You’ve given a set of tools, which gives visibility to steps, which you have to write by yourself. Out of the box, you have the ability to do whatever you want to do and get these steps really visible to your entire team.
12. We switched not because of “ugh, GitHub sucks.” No. We just did some analysis and chose the best option.
13. There’s a lot of potential, how we can improve the way we deliver our code to staging and production. And it is completely doable. You don’t need to wait for some 3rd party service to start providing you continuous deployment. Our team is ready now to trust the system, and know that they can just modify this step and get this other thing happen in the pipeline process.

Cost

1. GitHub EE is really expensive
2. GitLab CE is 100% free
3. Differences between CE and EE is not that big.
4. GitLab EE is not terribly expensive, and when you pay for it, it means that you’re supporting Open Source development. That’s a pretty big reason.
5. GitHub $1000/year + Codeship $1000/year → $1600/year with self-hosted GitLab EE(servers+license) = $400 savings

Speed and Agility

1. But the main spending is the time required for configuration and support.
2. With GitLab you spend a bit more time in the beginning to configure everything, but in the long term, it saves you a lot, because of the speed and agility it gives to you. Whatever we want to do — we can do.
3. We’re not bounded by someone else’s continuous deployment setup.

Kanban boards

1. No need to use Trello anymore. GitLab has a very similar and in some way a little bit more robust solution.
2. We use GitLab Issue Board for Actionable tasks, Trello is now more for ideas generation.
3. As a developer, having everything in one place is really good.

Time tracking

1. We started to track time and monitor where our time is spent.
2. We can be more deliberate about what do we spend our time on. And GitLab issues allows us to add time estimates and time tracked to them. It was a big plus for us with GitLab.
3. Pretty simple to update the time. Doing time-tracking with special commands in issue comments felt weird at the beginning, but it is also very effective. It is just minimum amount of effort you can spend on it, comparing to using a separate tool, or timesheets or whatever.

Project Management

1. As for issues, assign them priority, and people, and milestones, and time estimates.
2. It feels like a pretty Grown up management of a thing. That is pretty interesting. GitLab as a tool is working well.
3. Btw we use time tracking not to measure people’s performance, and we just use it to estimate how long it is going to take to complete a feature.

Migration process

1. We decided not to use GitLab migration tool, and that was a mistake. We had to migrate issues and labels manually. Just use the migration tool!
2. It could be done pretty easy. If you’re not taking into account CI stuff configuration, then it’s one-and-done thing.
3. GitLab is incredibly impressive software. Though I have a feeling that it is not that polished as GitHub in some places.

Make sure to check out this “Before-After” comparison table:

GitHub vs self-hosted GitLab