The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
This strategy is a work in progress, and everyone can contribute. Please comment and contribute in the linked issues and epics. Sharing your feedback directly on GitLab.com is the best way to contribute to our strategy and vision.
Gitaly is the service responsible for the storage and maintenance of all Git repositories in GitLab. Git repositories are essential to GitLab, for Source Code Management, Wikis, Snippets, Design Management, Web IDE, and every stage to the DevOps lifecycle to the right of Create - Verify, Release, Package, Release, Configure, Monitor, Secure, and Protect - depend on the project repositories. Because the majority of GitLab capabilities depend on that information stored in Git repositories, performance and availability are of primary importance.
GitLab is used to store Git repositories by small teams and large enterprises with many terabytes of data. For this reason, Gitaly has been built to scale from small single server GitLab instances, to large high availability architectures. The recent release of Gitaly Cluster is a major achievement in improving fault tolerance and performance, and is the foundation on which we are continuing to iterate to improve Gitaly for large instances.
Continued investment in large software projects over many years can result in extremely large Git repositories. Contributing to the development of features like partial clone in Git, and improving Gitaly and GitLab for these enterprise scale repositories is an ongoing area of investment.
Gitaly provides multiple interface to read and write Git data:
Systems Administrators directly interact with Gitaly when installing, configuring, and managing a GitLab server, particularly when high availability is a requirement. Today systems administrator must create and manage an NFS cluster to configure a high availability GitLab instance, and manual manage the failover to new Gitaly nodes mounted on the same NFS cluster. Once a HA Gitaly reaches minimal viability, it will be possible to eliminate the NFS cluster from architecture and rely on Gitaly for replication. At HA Gitaly continues to mature, automatic failover, automatic Gitaly node rebalancing and horizontal scaling read access across replicas will deliver 99.999% uptime (five 9's) and improved performance without regular intervention. Systems Administrators will have fewer applications to manage as other version control systems are retired as the last projects are migrated to GitLab.
Developers will benefit from increasing performance for repositories of all shapes and sizes, on the command line and in the GitLab application as performance improvements continue. Once support for monolithic repositories reaches minimal and continues maturing, developers will no longer be split between Git and legacy version control systems, as projects consolidate increasingly on Git. Developers that heavily use binary assets, like Game Developers, will at long last be able to switch to Git and eliminate Git LFS by adopting native large file support in Git.
The performance and availability of Gitaly is matter of importance for GitLab Administrators. The inability to access Git repositories on a GitLab server is an outage event, and for a large instance would prevent thousands of people from doing their job. The recent release of Gitaly Cluster is a major achievement in improving fault tolerance and performance. Continued iteration is need to further improve fault tolerance, performance, and complete roll out to GitLab.com.
Git is the market leading Version Control System (VCS), but many organizations with extremely large projects continue to use centralized version control systems like CVS, SVN, and Perforce. These organizations have often widely adopted Git, but isolated large legacy repositories remain elsewhere. Improvements to Git like partial clone and spare checkout, to Gitaly, GitLab will make it possible to standardize on Git for extremely large repositories, and allow organizations to consolidate on Git.
In progress: Gitaly Clusters: strong consistency
When a developer pushes changes to GitLab, if a success signal is returned, GitLab should have more than one copy of this data to prevent data loss. Strong consistency is the highest priority after shipping the eventually consistent MVC.
In progress: Incremental repository backups
Backing up GitLab instances with massive amounts of Git data is slow and difficult. The built-in backup script can't cope with large amounts of Git data. Workarounds include disk snapshots and rsync, and even then backups may take many many hours, and are likely to be inconsistent. A frequent request is point in time recovery from backups.
Partial Clone is built-in to Git and available in GitLab 13.0 or newer. Scalar is compatible with partial clone, and Microsoft is contributing to its improvement based on their learnings from the GVFS protocol.
Divergent solution for CDN Offloading
While we recognize that a lot of good work has gone into independent solutions, we are committed to work with the Git community on a CDN approach. We intend to support, implement, and contribute to this solution as it be comes available. This is currently being explored in our Support Git CDN offloading epic.
Gitaly is a non-marketable category, and is therefore not assigned a maturity level.
Customers and prospects evaluating GitLab (GitLab.com and self hosted) benchmark GitLab's performance against GitHub.com, including Git performance. The Git performance of GitLab.com for easily benchmarked operations like cloning, fetching and pushing, show that GitLab.com similar to GitHub.com.
Perforce competes with GitLab primarily on its ability to support enormous repositories, either from binary files or monolithic repositories with extremely large numbers of files and history. This competitive advantage comes naturally from its centralized design which means only the files immediately needed by the user are downloaded. Given sufficient support in Git for partial clone, and sufficient performance in GitLab for enormous repositories, existing customers are waiting to migrate to GitLab.
The version control systems market is expected to be valued at close to US$550mn in the year 2021 and is estimated to reach US$971.8md by 2027 according to Future Market Insights which is broadly consistent with revenue estimates of GitHub ($250mn ARR) and Perforce ($130mn ARR). The opportunity for GitLab to grow with the market, and grow it's share of the version control market is significant.
Git is the market leading version control system, demonstrated by the 2018 Stack Overflow Developer Survey where over 88% of respondents use Git. Although there are alternatives to Git, Git remains dominant in open source software, usage by developers continues to grow, it installed by default on macOS and Linux, and the project itself continues to adapt to meet the needs of larger projects and enterprise customers who are adopting Git, like the Microsoft Windows project.
According to a 2016 Bitrise survey of mobile app developers, 62% of apps hosted by SaaS provider were hosted in GitHub, and 95% of apps are hosted in by a SaaS provider. These numbers provide an incomplete view of the industry, but broadly represent the large opportunity for growth in SaaS hosting on GitLab.com, and in self hosted where GitLab is already very successful.
Users do not see Gitaly as a distinct feature or interface of GitLab. Git performance is the most significant user facing area where improvements are frequently requested, however the source of the performance problem can vary significantly.