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 Codepen Radio - 114 - GitLab, which details why they moved and how it went. If you'd rather read, we've included some of the highlights below.
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-managed GitLab instance, they have the ability to exercise control over their server and everything else.
12.35. We have control, we have code in our own network, we have higher security.
14:26. [GitLab EE] is not terribly expensive, and we're also supporting open source development.
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:37. Whatever we want to do, we can do, and we're not bound by someone else's Continuous Deployment setup.
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!
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"...
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-managed on AWS together with all their structure.
Cover image: screenshot of About CodePen.