We were so glad to hear that CodePen switched to GitLab!
Read through the ins and outs of their move! 😃
I'm a big fan of CodePen. Their product is awesome: it's intuitive, beautiful, works like a charm, and it's really easy to use. Their community's work is evolving – we could spend hours playing around with pens like this, created by Jase Smith:
When I heard that they had switched to GitLab, I was thrilled! Yaaay! CodePen, welcome to GitLab!
Listen to their podcast, which details why they moved and how it went. If you'd rather read, we've included some of the highlights below.
Source: Codepen Radio - 114 - GitLab
5:18. The first thing they talked about is "control".
7:45. They can't rely on a third-party service to deploy their code. Whenever there's downtime, there's nothing they can do about it. With a self-hosted GitLab instance, they have the ability to exercise control over their server and everything else.
10:00. Because it's self-hosted, they feel much more protected from hacker attacks and system breaches. They have their own private network space in which they run GitLab.
12.35. We have control, we have code in our own network, we have higher security.
Open source & Cost
13:00. The open source version of GitLab [CE] is 100% free. You can install it on your own server.
14:26. [GitLab EE] is not terribly expensive, and we're also supporting open source development.
Continuous Integration and Continuous Deployment
15:40. Finally, they don't need to rely on third-party services to apply Continuous Integration to test and deploy their code. GitLab CI does this job, and it's built-in in GitLab.
16:34. Because this CI runs internally, and because we have access to our own VPC and resources inside of it, like Docker stuff, and AWS EFS stuff, we can actually take a step further and not just test our stuff, but grab it and deploy it.
16:58. In our case, [GitLab] give you tools to make Continuous Integration, Continuous Testing and Continuous Deployment really, really simple. And that, to me, is the biggest sell of them all. That's simply not available on GitHub.
They also enjoy not having to deploy from the command line, as it was impossible to track.
17:15. They love our Pipelines, where the entire team can see what's going on and who's doing what. The steps are visible.
17:27. It's very clear, in GitLab, whether a build on staging has actually been pushed to production. So, if I'm going to deploy something to production, I can very easily see who has moved that into master since the last production deploy.
They also love the rollback button: no pain, all gain. Now it's easy to roll back changes.
19:18. I feel more comfortable, for sure.
23:20. Overall, GitLab brought them speed, security and agility.
23:37. Whatever we want to do, we can do, and we're not bound by someone else's Continuous Deployment setup.
Project Management: everything in one place
24:56. We were using Trello boards to organize our tasks, but very recently we've decided to move our project's specific tasks into GitLab [Issue Boards]. And that's because Trello is really good, in my opinion, for idea generation and quickly getting up cards for a lot of ideas you have. But the fact that the cards are so easy to add, at any point anywhere, kind of hurt us when we were trying to plan dev-work for a project, because we had duplicate cards, and the cards weren't tied to any specific pull request or issue in the codebase. So, it's kind of wish-washy having project planning over in Trello. (…) We've decided to switch to GitLab for actionable tasks related to getting up a project finished within CodePen.
28:07. Let's start looking at all of the things that are required to go into a feature and all, and assign them priorities, and people, and milestones, and time estimates, and stuff, and it feels like a really grown-up management of a thing, and it's pretty interesting!
29:10. They mentioned how cool it is to perform a slash command to add how long it's going to take to complete the implementation of a feature, right from an issue comment.
29:50. We are, as a group, sick of not having an understanding of how long it's going to take to complete a feature or whatever. If we use [Time Tracking], we'll know, or we'll be a lot closer to it! And further, we're going to be more accurate on what those time estimates are going to be, and we can plan around that, and not feel so wishy-washy about these big important things that we're doing. So we get that! That comes in the GitLab package as well, so it's kind of like we replaced GitHub, Codeship and Trello with one open source tool! This feels kind of cool!
30.45. They feel they made a mistake by not using the importer tool to import their projects: they simply pushed to GitLab like a separate remote. By doing so, they left some issues and wikis behind and had to transfer them manually.
31:24. This is biggest warning I have for everyone: read the documentation!
With GitLab Importer, you can just import your projects from GitHub directly from the UI, which means pushing a button.
31:45. It's just a button, essentially. You just have to give access to your GitHub account via keys, and once you've done that, GitLab will actually pull in all of your repos, and say "Which ones do you want to import?" and you just go "import", "import", "import"…
There's one thing they are missing: squash-merge. Good news for y'all: we have something like that coming soon!
At 33:44 they also mention burndown charts, and there is an issue for that with a lot of traction.
34:03. My final feeling about GitLab is it's incredibly impressive work. Like, holy crap, this is really good software! High five team! 🙌
CodePen is using GitLab EE Starter, self-hosted on AWS together with all their structure.
Cover image: screenshot of About CodePen.