This is the product vision for Gitaly. Gitaly is a Git RPC service for handling all the Git call made by GitLab.
Please read through to understand where we're headed and feel free to jump right into the discussion by commenting on one of the epics or issues, or by reaching out directly to our product manager leading this area: James Ramsay (E-Mail | Twitter)
Until recently the GitLab application relied on direct disk access to Git repositories, performing Git operations with either Rugged (libgit2 wrapper) or by shelling out to Git directly. At scale, this meant using NFS to make the repositories available to every application server. NFS adds latency and has opaque failure modes which are hard to debug in production. Furthermore, using multiple interfaces for Git makes instrumentation and caching difficult.
In late 2016, GitLab began building Gitaly, a gRPC service that would become the interface through which the GitLab application interacts with Git repositories. In mid 2018, GitLab completed this process for GitLab.com and unmounted NFS from GitLab.com application servers.
The Gitaly project is in the final stages of removing every last direct Git call from the GitLab application and supporting tools and scripts.
High Availability
Gitaly nodes are currently a single point of failure for GitLab deployments. In support of large GitLab deployments and Cloud Native deployments it is critical that Gitaly implement support for high availability.
Performance
Fast read and write access to Git repositories is an essential feature of GitLab and neccessary for the performance of the GitLab application that uses and presents data stored in Git throughout the application.
We follow the same prioritization guidelines as the product team at large. The public backlog for Gitaly can be viewed here, and can be filtered by labels or milestones. If you find something you are interested in, you're encouraged to jump into the conversation and participate. At GitLab, everyone can contribute!