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.
Last updated: 2021-05-05
| Section | Stage | Maturity | Last Reviewed |
|---|---|---|---|
| Dev | Create | Loveable | 2020-12-15 |
The Source Code Management direction page belongs to the Source Code group of the Create stage, and is maintained by Sarah Waldner, who can be reached at swaldner@gitlab.com.
This direction 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.
Source Code Management provides the core workflows and controls for teams to collaborate using Git to build great software, including repository view, protected branches, code owners, merge request approvals, and mirroring.
The primary performance indicator (PI) for our group is the number of unique users writing to a project Git repository. We want to ensure all the features in our group provide a great experience that ultimately will allow everyone to contribute more often. A great experience in our group is a critical starting point for this.
Aligning with our SaaS first and product depth direction, we are also working to make performance our secondary indicator (see related issue). The intent here is to track the most heavily used services in our group and track how they improve over time. We firmly believe speed is the killer feature and as such will work to provide a speedy experience to set a great stage for new and existing users.
See more detail in the Create:Source Code PI page section.
Source code management targets mainly software engineers but also anyone who is contributing to any types of project. To that end, we target all the user personas we describe in our handbook, with a special focus on the following:
Sasha (Software Developer): targets full time contributors to all types of projects (commercial, OSS, data science, etc.). These users expect and need a high level of reliability and speed in their interactions with both project files and Git.
Delaney (Development Team Lead): targets users who often times have elevated roles which allow for the management of project settings, such as access control, security, commit strategies, and mirroring.
Devon (DevOps Engineer): targets engineers tasked with supporting and enabling software teams. Their tasks often revolve around platform creation and maintenance, where GitOps] workflows are crucial.
The Source Code Management category is expansive and encompasses a broad set of features. Which features are leveraged, how they are leveraged, and to what extent greatly depends on the size of development team and the complexity of the product that they are building. We find that as the team size grows, as does the complexity of the software product. For these reasons, it is challenging to define a single user journey that captures how our users move through Source Code. That being said, there are five main buckets we can use to group the jobs to be done of our users. Understanding this general workflow helps to focus product development and discovery when exploring how to streamline the Source Code experience
We intend to define and document the user journeys our specific personas take and how those differ based on the size of the development and the industry in which they work.
The Source Code category of GitLab offers the features where the creative process begins. Here authors will not only consume existing project contents but will also author new content that will eventually move through the DevOps lifecycle. Additionally, many of the features in Source Code are consumed in the Code Review stage of the software developement lifecycle. Consider the following examples:
Because of this close relationship, the Source Code Management group must work closely with the Code Review group in order to ensure the developer experience is cohesive and efficient. This experience is core to providing a great first impression for users.
Building great software depends on teams working well together. Teams can rarely be divided into areas of complete independence. As cross-functional security, compliance and growth teams are formed, or new services and libraries are created, effective coordination and collaboration is a must. This is true whether using a single monolithic repository, or spread across numerous smaller services and libraries.
Teams require the controls to protect production while making it easy for everyone contribute. This means providing more granular and dynamic controls so that low risk changes can be made easily, and only the highest risk changes require the strictest controls.
When building software, teams greatly benefit from using open-source projects and may even submit contributions upstream. However, the balance of contribution vs. consumption is askew, partly because of a lack of controlled upstream workflows. Particularly from closed projects.
Upstreaming contributions from private repositories to a public upstream should be simple and safe, even for conservative organizations. Whether the upstream repository is on the same GitLab server, is hosted on GitHub.com, or managed via a mailing list.
GitLab maintains a set of Product Principles, some of which are more critical to be aware of in the Source Code category. Here they are, and why the are critical:
GitLab's success has translated into tremendous user growth, both for our self-managed and SaaS offerings. While working on supporting scale and performance, we have identified great opportunities to focus on.
In 2021 we are placing special emphasis on strengthening our SaaS offering by focusing on ensuring feature parity with our market leading self-managed offering. For the Source Code group, this means focusing on delivering solutions that are scalable, performant, and secure. We will focus on the following areas throughout the year:
Performance: Ensure GitLab.com performs well at scale as well as provides a great developer experience on key workflows and actions. Focus on resolving existing failure scenarios and technical debt.
Security: Industry leading security to safeguard user's data.
Infradev: Protect GitLab.com's availability from infrastructure failure.
Framework for Source Code Rules
GitLab offers a number of controls that can be implemented as safeguards. These controls can be put in place to keep changes from having a negative or enforce adherence to policies. Integrating features like protected branches, approval rules, code owners (approvals) and soon “status checks” should have an experience that easy to set up, maintain, and consume downstream.
For large repositories (especially monorepos) code owners files can get quite large. Keeping things organized is harder, especially ensuring that entries in one part of the file will not override entries in another part of the file. Also, readability for new users coming on board is difficult. Finally, changes to the file by multiple parties can create merge conflicts that need to be reconciled manually between multiple parties. We also know that large organizations with many projects and large projects need to enforce review policies so that they can ensure the correct teams and individuals review changes that impact them. File owners will be automatically added to related Merge Requests (separate feature), but it is also necessary to add controls to prevent changes directly to important branches without approval. We will be continuing to iterate on the first version of codeowners https://gitlab.com/groups/gitlab-org/-/epics/77. Specifically starting with supporting multiple codeowners file.
Improvements to protected branches
Sensitive information sometimes accidentally pushed to Git repositories. Although it is possible to safeguard against this in various ways it isn't possible to succeed every time. Sensitive information is a broad definition that could include trade secrets in the form of lab results from testing an experimentally drug, or personal information of a real person that was used to replicate and fix a bug. Unlike passwords, this information can't be rotated and needs to be permanently removed from the repository. There are tools for removing information from a Git repository like git filter-branch and https://rtyley.github.io/bfg-repo-cleaner/ but this is incomplete because GitLab uses refs to make sure that the commits in a merge request and diffs that have been commented on are not removed, so that future developers can read discussions about the previous code changes.
Improve commit list and details
Providing relevant metadata for commits allows developers and release managers to determine which merge requests carry the relevant code for a certain change. This is an important part of the release cycle which allows effective packaging and deployment.
Limiting which branches a user can read in a Git repository is possible in a basic sense, by only advertising a subset of refs, but it is not possible to guarantee that unreachable objects will not be sent to the client. This means that branch read access controls would be very weak, since they could not prevent exfiltration of data they do not have permission to read.
Path-level read access controls
From a commit, Git expects all trees and blobs to be reachable. Although Git supports partial clone and spares checkout, which allow data to be excluded from fetch and checkout, Git expects to be able to fetch missing objects on demand. Deliberately excluding objects by path is likely to cause unexpected failures.
This category is currently at the Loveable maturity level (see our definitions of maturity levels).
However, specific aspects are not yet loveable:
Important competitors are GitHub and Perforce, and increasingly Azure DevOps.
For public open source projects, GitHub is our primary competitor, with millions of active users having chosen GitHub before the first version of GitLab ever existed.
In most source code management capabilities GitLab compares favorably to GitHub, the most notable exception being the maturity of forking workflows which GitHub pioneered. GitHub has a highly polished and fast product, which makes tasks like browsing and managing projects fast and easy.
For users of SVN (Apache Subversion) intending to migrate to Git, GitHub is a significant competitor, particularly because GitHub supports hosting SVN repositories.
Perforce competes with GitLab primarily on its ability to support enormous repositories, however, Perforce also competes on the basis of being a Centralized Version Control System. This means that Perforce not only supports granular write permissions, but granular read permissions on a branch and file path basis. While fine grained read permissions are important to some customers, large monolithic repositories may be split into smaller repositories allowing read controls and easier management.
Large file support (see Gitaly direction) is an ongoing area of interest because it blocks certain segments of software development from using Git.
Similarly extremely large repository support (see Gitaly direction) is also an area of interest for the same reason.
The most frequent category of request is for improved support for finer grained controls, so that policies can be enforced at key points in the workflow, and more permissive permissions can be granted at other times.
