### Open source & Cost {: .panel-heading}

> 13:00. _The open source version of GitLab [[CE]] is 100% free. You can install it on your own server._ They decided to go for [GitLab EE Starter][ee] for having certain great features available only on EE, such as [Multiple Issue Boards][boards], and [fast-forward merge][ff]. > 14:26. _[GitLab EE] is not terribly expensive, and we're also supporting open source development._

### Continuous Integration and Continuous Deployment {: .panel-heading}

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][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][ci-cd] 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][pipes], 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._

### Their impression {: .panel-heading}

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 {: .panel-heading}

> 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._ 26:40. They appreciate having the [Issue Boards], [Todos], and [Time Tracking][tt] in one single platform, tied together with their code. > 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][slash] 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][tt]], 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!_

### The transition {: .panel-heading}

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][docs]!_ With [GitLab Importer][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"..._

### Bottom Line {: .panel-heading}

There's one thing they are missing: squash-merge. Good news for y'all: we have something like that [coming][squash] soon! At 33:44 they also mention burndown charts, and there is [an issue][burndown] 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!_ 🙌