Blog Insights How we use GitLab to build GitLab
July 7, 2015
3 min read

How we use GitLab to build GitLab

Have you ever wondered how GitLab employees use GitLab? Well read this article and get the inside scoop!

dog-food.jpeg

Have you ever wondered how GitLab employees use GitLab? Before I worked here, I always wondered how some products are used for their own creation. This actually has a name and it's called dogfooding.

Some months ago I went to an event in Facebook Headquarters and it called my attention that they use Facebook for everything, including registering guests and getting feedback. Most companies have certain technical departments that will work on making everything more “user friendly” or less technical for the rest of the company. In GitLab, we all try to learn how to use our platform and do everything that’s technical ourselves. That allows us to test our product and have more confidence in it.

Using GitLab.com

We use GitLab.com for any work that can be done in the open. That includes our GitLab website, GitLab CE, and more. We add Issues and Merge Requests for anything related to this. It is a public repository, so everybody can contribute to it (not only employees).

GitLab.com

dev.GitLab.org

We have a different platform for GitLab development. The idea is for our developers and team to work there with things that are sensitive because customers or security issues are involved. We have different projects for different purposes; Documentation, Organization, our different services, etc. Still, we try to work as much as possible in the open.

Once you become part of the GitLab team, you are granted access to the beta site dev.GitLab.org. At the beginning it’s a little bit confusing to be using both sites and knowing when to use each; but with time, it becomes more natural. I personally decided to customize each site with a different color so that it wouldn't be confusing anymore. We can use our beta site for tests and all of our version release actions. It is updated daily with the latest version, so that we are constantly testing it. Our new logo was tested there before it was released. We all agreed that it looked very nice.

dev.gitlab.org

Our employee Handbook

Our onboarding is very simple and accessible for anyone. Since we are open source, it is public and once you become part of the team, you should read it and if you have any questions, you may use Slack to ask. It’s very simple and easy to use. If it’s written, I guess there’s no confusion.

Handbook

Communication

We use Slack for general information, emails for non-urgent information, and Issues for things that need to be improved or solved. We usually mention people and then we let the people assign the issues to themselves.

The way we use issues is very interesting because we add them in the repository that is mostly related to the subject the issue is about. We add all the links and information that we have and mention the people involved. Everybody comments, we work on the issues and then we link to the Merge Request where the issue is solved.

The improvements are added through Merge Requests and we link the issue where the improvement is suggested, if it applies.

To help improve our communication and to work on our team building, every year, there's an event that the entire team will attend. It's a great opportunity to integrate the team and to get to know each other in person. This year, we are all going to OSCON in The Netherlands. It will be a great opportunity to interact and share some quality time with the team.

OSCON

So, how do you use the product at the company where you work at?

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert