Get the DevOps platform

In GitLab, to ensure strict code review, you can require a minimum number of users to approve of a merge request before it is able to be merged. You can undo an approval by removing it after the fact.

Draft multiple comments in a merge request code review, before reviewing and submitting them together all at once. This allows you to review code in consistent, and self-contained sessions, instead of as individual comments.

Assign Code Owners to files to indicate the team members responsible for code in your project using a CODEOWNERS file. Code owners are assigned automatically as merge request approvers, can be set as required and shown when viewing files. Sections allow each team to configure their own code owners configuration independently, allowing multiple teams to look after common parts of the codebase.

Find bottlenecks in your code review process by understanding how long open merge requests have been in review.

Keep master green. A special pipeline runs on the results of merged code before merging into master to detect changes that may be green on a branch but will fail master when merged.

Full Code Quality reports are available on the pipeline page, showing areas of the codebase that do not meet the organization’s preferred style or standards.

Review Apps let a developer share their work in progress with their team or a broader audience quickly as they implement a change and request feedback. Being able to leave comments on the Merge Request from the Review app shortens the feedback cycle and creates a single source of truth to track change requests. This feature enables designers, Product Managers, and other stakeholders to comment on the changes to the look and feel / user experience of a change just as easily and quickly as developers working in the MR.

Visualize the history and current status of pipelines across projects and groups all in a single dashboard that can be customized for each user.

With multi-project pipeline graphs you can see how upstream and downstream pipelines are linked together for projects that are linked to others via triggers as part of a more complex design, as it is for micro-services architecture.

Ensure an orderly and efficient flow of changes in a pipeline to target branches by queueing up pipelines in parallel, each building off the merge result of the previous pipeline. Squash-and-Merge is also supported together with Merge Trains.

Connect your projects hosted on external services (like GitHub or Bitbucket) and leverage the power of GitLab CI/CD pipelines to build, test, and deploy your applications easily.

Manage the deployments and connection to your Kubernetes clusters in a secure and compliant way, driven by code.

The GitLab Environments Dashboard provides a cross-project environment-based view that lets you see the big picture of what is going on in each environment. From a single location, you can now track the progress as changes flow from development to staging, and then to production (or through any series of custom environment flows you can set up). With an at-a-glance view of multiple projects, you can instantly see which pipelines are green and which are red, allowing you to diagnose if there is a block at a particular point, or if there’s a more systemic problem you need to investigate

Define custom LICENSE, .gitignore, Dockerfile and .gitlab-ci.yml templates for a Group to make consistency easier.

Provides an overview of all the projects that are making use of the instance or group Kubernetes cluster, including the deployments/environments that have been provisioned and the numbers of pods used by each environment.

Visualize multiple epics and milestones across time in a roadmap view.

Issue board lists that pull in issues in a given milestone

Assign scoped labels mutually exclusively when they have the same scope.

Assign more than one person to an issue at a time.

Plan and track features and work group level epics that collect issues together. Easily create and assign Issues directly from the Epic itself

Multiple Group Issue Boards, similar to Multiple Project Issue Boards

Promote an issue to epic to continue collaboration at a higher-level work abstraction.

Associate a board with a milestone, labels, an assignee, and a weight

Make sure the right people review merge requests with approval rules by specifying lists of eligible approvers, the minimum number of approvals for each, and which target branches they protect. This makes it easy to request review from different teams like Engineering, UX and Product.

Coordinate the order in which merge requests are merged within the same project and/or across different projects.

Reject new code and commits that don’t comply with company policy.

When a project needs multiple sign-offs, you can require every merge request to be approved before merging. With Required Merge Request Approvals you can set the number of necessary approvals and predefine a list of specific approvers. In turn, guarantee the quality and the standards of your code.

Extend the base functionality of protected branches and choose which users can push or merge to a protected branch.

Specify which person, group, or account is allowed to deploy to a given environment, allowing further protection and safety of sensitive environments.

Group owners can prevent new members from being added to projects within a group.

Having Geo replicated server(s) can make local pulls go more quickly, but without support for Geolocation-aware DNS, developers need to reconfigure their tools manually to point to their nearest geo replicated server. Users using Geolocation-aware DNS can be transparently directed to the closest server available and can access repository data faster.

Fail over in minutes to another data-center.

Maintenance mode allows systems administrators to perform maintenance operations, such as preparing for a scheduled failover, with minimal disruption to end users.

Configure replicated Git storage with automatic failover, strong consistency, and read distribution for improved fault tolerance and performance.

When development teams are spread across two or more geographical locations, but their GitLab instance is in a single location, fetching and cloning large repositories can take a long time. Built for distributed teams, GitLab Geo allows for read-only mirrors of your GitLab instance, reducing the time it takes to clone and fetch large repos and improving your collaboration process.

GitLab Premium includes support for scaling GitLab services across multiple nodes to manage demands on your system and provide redundancy. GitLab has developed reference architectures so you can easily determine the optimal architecture for your needs.

Supports distributed teams by running multiple registry instances across several regions and syncing between data centers.

Distribute read-only queries among multiple PostgreSQL database servers and reduce the load on the primary database to increase responsiveness.

Forward your logs to a central system.