Jacob Vosmaer

My work at GitLab (2013-2023)

I worked at GitLab for nearly 10 years and watched the company grow from a small startup to well over 1000 people. I started out in support and infrastructure (as "Senior Service Engineer") but I spent most of my time in software engineer roles. Some things I worked on, in chronological order:

• Omnibus GitLab: packaging for GitLab. In my opinion, GitLab owes much of its success to its popularity as self-hosted software. Prior to Omnibus installing GitLab was cumbersome and so was keeping it updated. Omnibus made and continues to make the lives of administrators of GitLab installations much easier. Also see these presentation slides from 2014.
• GitLab.com SaaS infrastructure. In my first two years at GitLab I was the main person doing system administration for all GitLab company servers including GitLab.com. I worked on several infrastructure redesigns and data migrations. By the time the company started to hire for specialist Infrastructure roles I specialized on Development instead.
• Developer productivity: I was the initial developer and maintainer of GitLab Development Kit, a set of tools that lets both internal developers and community contributors develop and run GitLab on their local computers. I was guided by my experience with Omnibus and GitLab.com system administration in designing these tools.
• I made sure Git push and pull via HTTP became a first-class GitLab feature. GitLab was originally meant to be used only with Git over SSH. Support for the Git HTTP protocol never worked well in Ruby on Rails because of request timeouts. I solved this problem by adding a companion web service written in Go called GitLab Workhorse to GitLab.
• Gitaly: GitLab's Git RPC service. GitLab was originally designed to run on a single server, with all its server side components having direct access to all the hosted Git repositories. This design was at odds with the ever growing scale of GitLab.com. For a long time we dealt with this by storing repositories on NFS servers but this created reliability problems that got worse over time. The Gitaly project was started to solve this by developing a Go RPC service that could run on the NFS servers, giving the rest of the application access to the repositories via application-specific gRPC calls rather than NFS file access. I was involved with the initial build-out of the RPC service as (unofficial) lead developer, which took about 2 years, and stayed with the team for some time after that to work on new Git RPC features.
• In my final 3 years at GitLab I was with the Scalability team in the Infrastructure department. I did some platform engineering and observability work there but I mainly focused on performance engineering: looking for saturation problems caused by real-world traffic at GitLab.com scale and addressing these by making application improvements. My personal highlight is the work we did on server-side caching for CI Git traffic.