Apr 22, 2019 - Eric Brinkman

GitLab 11.10 Release

GitLab 11.10 released with Pipelines on the Operations Dashboard, Pipelines for Merged Results, and Multi-line Merge Request Suggestions

GitLab 11.10 released with Pipelines on the Operations Dashboard, Pipelines for Merged Results, Multi-line Merge Request Suggestions, and much more!

Easily see pipeline health across projects

GitLab continues to add features to provide visibility into the DevOps lifecycle. This release enhances the Operations Dashboard with a powerful feature that provides an overview of pipeline status.

This is handy even when looking at a single project's pipeline, but is especially valuable when using multi-project pipelines - common when you have a microservices architecture and you need to run a pipeline to test and deploy code housed in multiple different project repositories. Now you can get instant visibility at a glance into the health of all of your pipelines on the Operations Dashboard, no matter where they run.

Run pipelines against merged results

Over time it’s possible for your source and target branches to diverge, which can result in the scenario where both source and target pipelines pass, but the combined output fails. Now, you can run pipelines against the merged result prior to merging. This allows you to quickly catch errors that would only surface if you had rebased often, allowing for much quicker resolution of pipeline failures and more efficient usage of GitLab Runners.

Further streamline collaboration

With GitLab 11.10, we provide even more features to simplify collaboration and developer workflows. In a previous release, we introduced merge request suggestions, allowing a reviewer to suggest a one-line change in a merge request comment that can be readily committed from within the comment thread interface. Our users loved it and wanted more. Now, you can suggest a multi-line change, specifying which existing lines to remove, and introducing multiple lines of additions. Thank you for contributing improvement suggestions!

And so much more…

So many great features are available in this release, like Scoped Labels, a more thorough Container Registry cleanup, Composable Auto DevOps, and the ability to purchase additional CI Runner minutes. Read on to learn about them all!

GitLab 11.10 released with Pipelines on the Operations Dashboard, Pipelines for Merged Results, and Multi-line Merge Request Suggestions via @ericbrinkman Click to tweet!

Join us for an upcoming event

MVP This month's Most Valuable Person (MVP) is awarded to Takuya Noguchi

This month’s MVP goes to Takuya Noguchi. Takuya made many contributions to GitLab, including fixing bugs, cleaning up both backend and frontend technical debt, as well as making UI improvements. Thank you!

11.10 Key improvements released in GitLab 11.10

Pipelines on the Operations Dashboard

Pipelines on the Operations Dashboard

SaaS

Self-Managed

The Operations Dashboard in GitLab is a powerful feature allowing users to have an overview of project information throughout the entire GitLab instance. You add individual projects, one by one, so it’s flexible to whichever specific projects are of interest.

With this release, we added pipeline status information to the Operations Dashboard. This helps teams view the pipeline health of all the projects that they care about, together in a single interface.

Documentation Issue

Pipelines for Merged Results

Pipelines for Merged Results

SaaS

Self-Managed

When working in a feature (source) branch, it’s normal to have it diverge over time from the target branch if you aren’t rebasing frequently. This can result in a situation where both the source and target branch’s pipelines are green and there are no merge conflicts, but the combined output will result in a failed pipeline due to an incompatibility between the changes.

By having your merge request pipeline automatically create a new ref that contains the combined merge result of the source and target branch, then running the pipeline against that ref, we can better ensure that the combined result will be valid.

Please note that if you are using merge request pipelines (in any capacity) and you use private GitLab runners that are version 11.8 or older, you will need to upgrade them to avoid running into the issue described in gitlab-ee#11122. Users of GitLab’s shared Runner fleet are not impacted.

Documentation Issue

Suggest changes to multiple lines

Suggest changes to multiple lines

SaaS

Self-Managed

Collaborating on merge requests often involves spotting problems and suggesting a solution. In GitLab 11.6, we introduced support for suggesting a change to a single line.

With 11.10, changes can now be suggested to multiple lines when leaving a comment on a merge request diff, and accepted with a single click, by any user with write permissions to the source branch. This new feature avoids the copy/paste workflow of old.

Documentation Issue

Scoped Labels

Scoped Labels

SaaS

Self-Managed

Scoped Labels enable teams to apply mutually exclusive labels (that share the same scope) on an issue, merge request, or epic, solving the use cases of custom fields and custom workflow states. They are configured simply using a special double colon syntax in the label title.

Suppose you wanted a custom field in issues to track the platform operating system that your features target. And each issue should only target one platform. You would create labels platform::iOS, platform::Android, platform::Linux, and others, as necessary. Applying any one of these labels on a given issue would automatically remove any other existing label that starts with platform::, as desired.

Suppose you have the labels workflow::development, workflow::review, and workflow::deployed, representing workflow states of your particular team. If an issue already has the label workflow::development applied, and a developer wanted to advance the issue to workflow::review, they would simply apply that label, and the workflow::development label would automatically be removed, as desired. This behavior already exists when you move issues across label lists in an issue board representing your team’s workflow. But now team members who may not be working in an issue board directly, would still nonetheless be able to advance workflow states consistently in issues themselves.

Documentation Issue

More thorough Container Registry cleanup

More thorough Container Registry cleanup

SaaS

Self-Managed

In normal use of the Container Registry with CI pipelines, typically you will end up pushing many iterative revisions to the same tag. Due to the way Docker Distribution is implemented, the default behavior is to preserve all revisions in the system – this ends up consuming a lot of space under this usage pattern. By using the -m parameter with registry-garbage-collect, administrators now have an easy way to wipe out these historical revisions and free up valuable storage space.

Documentation Issue

More thorough Container Registry cleanup

Purchase add-on CI Runner minutes

Purchase add-on CI Runner minutes

SaaS

Self-Managed

Users on GitLab.com’s paid plans (Gold, Silver, Bronze) can now purchase additional CI Runner minutes. Previously, users were limited by the minutes quota included in their plan. This improvement enables users to proactively purchase minutes in addition to their free minutes, which reduces the potential for any interruptions in service due to stopped pipelines.

The current price is $8 for 1,000 minutes and there is no cap to how many add-on minutes you can buy. Your add-on minutes will only begin to be used once your monthly quota has been used and whatever add-on minutes are left at the end of the month will roll over. In a future release, we aim to extend this to Free plans as well.

Documentation Issue

Composable Auto DevOps

Composable Auto DevOps

SaaS

Self-Managed

Auto DevOps enables teams to adopt modern DevOps practices with little to no effort. Starting in GitLab 11.10 each job of Auto DevOps is being made available as an independent template. Using the includes feature of GitLab CI, users can include only certain stages of Auto DevOps while continuing to use their own custom gitlab-ci.yml. This will enable teams to include just the desired jobs while taking advantage of any updates made upstream.

Documentation Issue

Automatically manage group members on GitLab.com using SCIM

Automatically manage group members on GitLab.com using SCIM

SaaS

Self-Managed

Until now, managing group membership on GitLab.com was a manual effort. You’re now able to use SAML SSO and manage group membership with SCIM, allowing your organization to create, remove, and update users on GitLab.com.

This is especially useful for enterprises who typically manage large numbers of users with centralized identity providers. Now, you’re able to use a provider like Azure Active Directory as the single source of truth – and feel confident that your users will be provisioned and de-provisioned automatically based on your identity provider, not by hand.

SaaS

Self-Managed

Previously, SAML-based SSO for groups required that a user sign in with both their GitLab user credentials and their identity provider. Now, a user will be able to use SSO to immediately sign in with a GitLab user linked to the configured group.

This removes the need to sign in twice, making SAML SSO more convenient and useful for enterprises using it on GitLab.com.

Documentation Issue

Sign in to GitLab.com with your own SAML provider

11.10 Other improvements in GitLab 11.10

Child Epics roadmap

Child Epics roadmap

SaaS

Self-Managed

In a previous release, we added Child Epics – the ability to have epics of epics – to help teams manage work breakdown structures. Child epics are shown in the epic page of the parent epic.

With this release, you can now see a roadmap view of the child epics in the parent epic page itself. This helps teams see the timeline view of those child epics, allowing you to manage time dependencies.

Documentation Issue

Filter merge requests by target branch

Filter merge requests by target branch

SaaS

Self-Managed

Git workflows for releasing or deploying software often involve multiple long-running branches, either for backporting fixes to older versions (e.g. stable-11-9) or moving through a QA process to product (e.g. integration), but finding the merge requests that target these branches can be difficult among many open merge requests.

The merge request list for projects and groups can now be filtered by the target branch of the merge request, making it simpler to find the merge request you are looking for.

Thank you, Hiroyuki Sato, for the contribution!

Documentation Issue

Sort Wiki pages by created date

Sort Wiki pages by created date

SaaS

Self-Managed

A project’s Wiki allows teams to share documentation and other important information conveniently, side by side with source code and issues. In this release, the list of pages in a Wiki can be sorted by created date and title, allowing users to locate recently created content quickly.

Documentation Issue

See Load Balancer metrics in your Grafana dashboard

See Load Balancer metrics in your Grafana dashboard

SaaS

Self-Managed

Ensuring your GitLab instance stays healthy is critical. We’ve previously given you default dashboards to review in our bundled-in Grafana instance. Starting with this release, we now include additional dashboards to monitor your NGINX load balancers.

Documentation Issue

Multiple queries per chart

Multiple queries per chart

SaaS

Self-Managed

GitLab allows you to create charts to visualize the metrics you are collecting. Often, such as when you want to see the maximum and average value of a metric, it’s crucial to be able to visualize multiple values on the same chart. Starting with this release, you can now do so.

Documentation Issue

Enrich Container Scanning report with more metadata

Enrich Container Scanning report with more metadata

SaaS

Self-Managed

This release enriches the Container Scanning report with more metadata, adding impacted component (a Clair feature) to the existing metadata: priority, identifier (with a link on mitre.org), and affected layer (ex: “debian:8”).

Documentation Issue

Multi-module Maven projects support for Dependency Scanning

Multi-module Maven projects support for Dependency Scanning

SaaS

Self-Managed

This release enables multi-module Maven projects for GitLab Dependency Scanning. Previously, if a sub-module had a dependency with another sub-module sibling, it could not resolve the download from the Maven Central repository. Now a multi-module Maven project is created with two modules and a dependency between the two modules. The sibling dependency is now available in the local Maven repo, permitting the build to continue.

Documentation Issue

Allow users to change the path for cloning in CI

Allow users to change the path for cloning in CI

SaaS

Self-Managed

By default, the GitLab Runner clones the project to a unique subpath of the $CI_BUILDS_DIR. However, for some projects, such as Golang projects, there may be a requirement to have the code cloned to a specific directory to be built.

In GitLab 11.10, we’ve introduced a variable called GIT_CLONE_PATH that allows users to specify the specific path that the GitLab Runner will clone to before starting the job.

Documentation Issue

Enable/disable Auto DevOps at the Group level

Enable/disable Auto DevOps at the Group level

SaaS

Self-Managed

Enabling Auto DevOps for your GitLab.com project provides an easy way to get started with modern DevOps workflows, from build all the way to deploy.

Starting with GitLab 11.10 we’ve added the ability to enable/disable Auto DevOps for all the projects that are part of any given group.

Documentation Issue

Update Kubernetes deployments label selector

Update Kubernetes deployments label selector

SaaS

Self-Managed

Deploy boards provide an easy way to gain insight into your Kubernetes deployments.

As part of this release, we’re updating the way labels are matched to deployments; deploy boards will now match by app.example.com/app and app.example.com/env or app. This will allow us to prevent conflicts when doing filtering and risk incorrect deploys associated to the project.

Additionally, starting in GitLab 12.0 we will remove ‘app’ label matching from Kubernetes deployment selector and will instead match only on app.example.com/app and app.example.com/env.

Documentation Issue

Group Runners for group-level clusters

Group Runners for group-level clusters

SaaS

Self-Managed

Group-level clusters now support the installation of GitLab Runner. Group-level Kubernetes runners will appear for child projects as group runners tagged with the labels cluster and kubernetes.

Documentation Issue

Add control for `git clean` flags for GitLab CI/CD jobs

Add control for `git clean` flags for GitLab CI/CD jobs

SaaS

Self-Managed

By default, GitLab Runner runs a git clean as part of the process of checking out your code while running a job in GitLab CI/CD. In GitLab 11.10, we’re adding the ability for users to control the flags passed to the git clean command. This will help teams who have dedicated runners or are building projects from large mono repositories to manage the checkout process prior to executing their scripts. The new variable GIT_CLEAN_FLAGS defaults to -ffdx and accepts all the possible options of the git clean command.

Documentation Issue

External Authorization in Core

External Authorization in Core

SaaS

Self-Managed

Secure environments may require checking with an additional external authorization resource to permit project access. We added support for this additional layer of access control in 10.6, and we’ve heard requests from the community to move this functionality to Core. We’re happy to do this for External Authorization and bring this additional level of security to Core instances, since it’s a feature cared about by individual contributors.

Documentation Issue

GitLab Runner 11.10

GitLab Runner 11.10

We’re also releasing GitLab Runner 11.10 today! GitLab Runner is the open source project that is used to run your CI/CD jobs and send the results back to GitLab.

Most interesting changes:

List of all changes can be found in GitLab Runner’s CHANGELOG.

Documentation

Performance improvements

Performance improvements

We continue to improve the performance of GitLab with every release for GitLab instances of every size. Some of the improvements in GitLab 11.10 are:

Performance improvements

Merge request popovers

Merge request popovers

SaaS

Self-Managed

In this release, we introduce enriched popovers when hovering over a merge request link. While we previously only displayed the title of the merge request, you can now view the merge request status, CI pipeline status, title, and short URL.

In future releases, we plan to add additional important information like assignees and milestones and bring popovers to issues too.

Documentation Issue

Push and merge when pipeline succeeds

Push and merge when pipeline succeeds

SaaS

Self-Managed

Trunk-based development claims that long-running branches should be avoided in favor of small, short-lived, single-owner branches. For the smallest changes it is not uncommon to push directly to the target branch, but this runs the risk of breaking the build.

In this release, GitLab supports new Git push options to open a merge request automatically, set the target branch, and enable merge when the pipeline succeeds via the command line, at the moment that you push to your branch.

Documentation Issue

Improved integration with external monitoring dashboards

Improved integration with external monitoring dashboards

SaaS

Self-Managed

GitLab can access multiple Prometheus servers (at the environment, project and soon group levels) but the complexity of multiple endpoints can be difficult or unsupported by common dashboarding tools. In this release teams can now interact with a single Prometheus API interface, making integration with services like Grafana much simpler.

Documentation Issue

Monitor resources requested by your cluster

Monitor resources requested by your cluster

SaaS

Self-Managed

GitLab can assist you by monitoring the Kubernetes cluster you use for your staging and production applications. Starting in this release, you can monitor the requested CPU and Memory resources by your cluster helping you spot potential application impacts before they happen.

Monitor resources requested by your cluster

Documentation Issue

SAST for Elixir

SAST for Elixir

SaaS

Self-Managed

We are continuing to add support for more languages and depth in our security scans. With this release, we enable security scanning for projects created using Elixir, now broadened to projects created using the Phoenix framework.

Documentation Issue

Show DAST results in the Group Security Dashboard

Show DAST results in the Group Security Dashboard

SaaS

Self-Managed

We have added Dynamic Application Security Testing (DAST) results in the Group Security Dashboard to accompany results already present for SAST, Container Scanning, and Dependency Scanning.

Documentation Issue

Add metrics report type to merge requests

Add metrics report type to merge requests

SaaS

Self-Managed

GitLab already provides several report types to be included directly into the merge request – from Code Quality and Unit Test reports from the Verify stage to SAST and DAST from the Secure stage.

While those specific report types are very valuable, there is also value in providing a primitive that can be used across many different types of use cases. In GitLab 11.10 we are shipping metrics reporting directly in the merge request that expects a simple key/value pair of metrics. This will allow users to track any changes, including custom metrics, over time and how they change with a given merge request. Use cases such as memory usage, specialized load testing, and other code health statuses can be converted to simple metrics that will then be exposed directly in the MR alongside the other built-in reports.

Documentation Issue

Simple masking of protected variables in logs

Simple masking of protected variables in logs

SaaS

Self-Managed

GitLab provides several ways to protect and limit the scope of variables in GitLab CI/CD. However, there are still ways that variables can leak into build logs, either intentionally or unintentionally.

GitLab takes risk management and audit seriously and continues to add features to help with compliance efforts. In GitLab 11.10, we’ve added the ability to mask certain types of variables if they are found in the job trace logs, adding a level of protection against accidentally leaking the content of those variables into the logs. Also, GitLab will now automatically mask many of the built-in token variables.

Documentation Issue

Simplified and improved license page

Simplified and improved license page

SaaS

Self-Managed

To improve the user experience and make handling license keys easier, we’ve redesigned the license page in the admin panel and emphasized the most important elements of the page.

Documentation Issue

Just-in-time Kubernetes resource creation

Just-in-time Kubernetes resource creation

SaaS

Self-Managed

GitLab’s Kubernetes integration takes advantage of RBAC security by creating a service account and a dedicated namespace for each GitLab project. Starting with this release, to maximize the efficiency with which these resources are created, they will be created only when they are needed for deployment.

When a Kubernetes deployment takes place, GitLab CI will create the resources prior to deployment.

Documentation Issue

Show function invocation count for Knative functions

Show function invocation count for Knative functions

SaaS

Self-Managed

Functions deployed with GitLab Serverless will now include the number of invocations received for the particular function. Showing the number of invocations requires Prometheus to be installed on the cluster where Knative is installed.

Show function invocation count for Knative functions

Documentation Issue

Allow Developers to create projects in groups in Core

Allow Developers to create projects in groups in Core

SaaS

Self-Managed

We added a configurable option to allow the Developer role to create projects in groups back in 10.5, and we’re adding this option to Core. Creating projects is a key capability for productivity in GitLab, and moving this option to Core helps reduce barriers when members of an instance want to work on something new.

Documentation Issue

Fix returned `project_id` in blob search API with Elasticsearch

Fix returned `project_id` in blob search API with Elasticsearch

SaaS

Self-Managed

We fixed a bug in the blob search API with Elasticsearch that was incorrectly returning 0 for project_id. You will need to reindex Elasticsearch to get the correct project_id values after installing this version of GitLab.

Documentation Issue

Omnibus improvements

Omnibus improvements

The following improvements have been made to Omnibus in GitLab 11.10:

GitLab 11.10 includes Mattermost 5.9.0, an open source Slack-alternative whose newest release includes a new Integrations Directory, a simple way to migrate data from Hipchat, and much more. This version also includes security updates and upgrading is recommended.
GitLab dashboards are now pre-loaded in the bundled Grafana, making it even easier to begin monitoring your instance of GitLab.
We have added support to clean up old container images from the Docker registry.
We have updated ca-certs to 2019-01-23.

Documentation

GitLab chart improvements

GitLab chart improvements

The following improvement has been made to GitLab charts:

Support for Elasticsearch has been added.

Documentation

Deprecations Deprecations

GitLab Geo will enforce Hashed Storage in GitLab 12.0

GitLab Geo will enforce Hashed Storage in GitLab 12.0

GitLab Geo requires Hashed Storage to mitigate race conditions on secondary nodes. This was noted in gitlab-ce#40970.

In GitLab 11.5, we added this requirement to the Geo documentation in gitlab-ee#8053.

With GitLab 11.6, sudo gitlab-rake gitlab:geo:check checks that Hashed Storage is enabled, and all projects are migrated. See gitlab-ee#8289. If you are using Geo, please run this check and migrate as soon as possible.

In GitLab 11.8, a permanently dismissable warning is displayed on the Admin Area › Geo › Nodes page if the above checks are not resolved: gitlab-ee!8433.

In GitLab 12.0, Geo will enforce the Hashed Storage requirement. See gitlab-ee#8690.

Planned removal date: Jun. 22, 2019

Ubuntu 14.04 support

Ubuntu 14.04 support

GitLab 11.10 will be the last release with support for Ubuntu 14.04.

Canonical has announced that standard support for Ubuntu 14.04 will end on April 2019. We recommend that users upgrade to one of the currently supported LTS versions – Ubuntu 16.04 or Ubuntu 18.04.

Planned removal date: May 22, 2019

Limit maximum number of pipelines created by a single push

Limit maximum number of pipelines created by a single push

Previously, GitLab would create pipelines for the HEAD of every branch included in a push. That makes sense for developers that may be pushing more than one change at a time (say to a feature branch, and the develop branch).

However, when pushing a large repository with many active branches – perhaps to move, mirror, or fork it from another location - it does not make sense to create a pipeline for every branch. Starting in GitLab 11.10, we will create a maximum of 4 pipelines during a push operation.

Planned removal date: May 22, 2019

Deprecate legacy code paths GitLab Runner

Deprecate legacy code paths GitLab Runner

Since GitLab 11.9, GitLab Runner has been using a new method for cloning/fetching the repository. Currently, GitLab Runner will use the old method if the new one is not supported. Please see this issue for additional details.

In GitLab 11.0 we changed how the metrics server is configured for GitLab Runner. metrics_server will be removed in favor of listen_address in GitLab 12.0. Please see this issue for additional details.

In 11.3, GitLab Runner started supporting multiple cache providers; this resulted in new settings for S3 specific configuration. In the documentation, there is a table of what changed, and how to migrate to the new configuration. Please see this issue for additional details.

These paths will no longer be available in GitLab 12.0. As a user, you don’t have to change anything apart from making sure the GitLab instance is running 11.9+ when upgrading to GitLab Runner 12.0.

Planned removal date: Jun. 22, 2019

Deprecate entrypoint feature flag for GitLab Runner

Deprecate entrypoint feature flag for GitLab Runner

In 11.4 GitLab Runner introduced a feature flag FF_K8S_USE_ENTRYPOINT_OVER_COMMAND in order to fix issues like #2338 & #3536.

In GitLab 12.0, we will switch to the correct behavior as if the feature flag was turned off. Please see this issue for additional details.

Planned removal date: Jun. 22, 2019

Deprecate support of Linux distribution that reached EOL for GitLab Runner

Deprecate support of Linux distribution that reached EOL for GitLab Runner

Some Linux distributions in which you could install GitLab Runner have reached End of Life support.

In GitLab 12.0, GitLab Runner will no longer distribute packages to those Linux distributions. A full list of distributions which are no longer supported can be found in our documentation. Thanks, Javier Jardón for your contribution!

Planned removal date: Jun. 22, 2019

Remove legacy GitLab Runner Helper commands

Remove legacy GitLab Runner Helper commands

As part of our effort to support a Windows Docker executor, we had to deprecate some old commands that are used for the helper image.

In GitLab 12.0, GitLab Runner will start using the new commands. This only affects users who are overriding the helper image. Please see this issue for additional details.

Planned removal date: Jun. 22, 2019

Remove legacy git clean mechanism from GitLab Runner

Remove legacy git clean mechanism from GitLab Runner

With GitLab Runner 11.10 we’re introducing a way to configure how git clean command is being executed by Runner. Additionally, the new cleanup strategy removes the usage of git reset and moves the git clean command after the checkout step.

Since this is a behavior change that may affect some users, we’ve prepared a FF_USE_LEGACY_GIT_CLEAN_STRATEGY feature flag. When set to true it will restore the legacy cleanup strategy. More about how to use feature flags in GitLab Runner can be found in the documentation

In GitLab Runner 12.0, GitLab Runner will drop support for the legacy cleanup strategy and remove the ability to restore it with a feature flag. Please see this issue for additional details.

Planned removal date: Jun. 22, 2019

System Info section in the admin panel

System Info section in the admin panel

GitLab presents information about your GitLab instance at admin/system_info, but this information can be inaccurate.

We’re removing this section of the admin panel in GitLab 12.0 and recommend using other monitoring capabilities.

Planned removal date: Jun. 22, 2019

Support for Prometheus 1.x in Omnibus GitLab

Support for Prometheus 1.x in Omnibus GitLab

With GitLab 11.4, the bundled Prometheus 1.0 version is deprecated in Omnibus GitLab. Prometheus 2.0 is now included. However, the metrics format is incompatible with 1.0. Existing installations can upgrade to 2.0 and optionally migrate their data using an included tool.

With GitLab 12.0, any installation not yet running Prometheus 2.0 will be automatically upgraded. Metric data from Prometheus 1.0 will not be migrated and will be lost.

Planned removal date: Jun. 22, 2019

Removals and breaking changes Removals and breaking changes

The complete list of all removed features can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

Changelog Changelog

Please check out the changelog to see all the named changes:

Installing Installing

If you are setting up a new GitLab installation please see the download GitLab page.

Updating Updating

Check out our update page.

Questions? Questions?

We'd love to hear your thoughts! Visit the GitLab Forum and let us know if you have questions about the release.

GitLab Subscription Plans GitLab Subscription Plans

Free
Free-forever features for individual users
Premium
Enhance team productivity and coordination
Ultimate
Organization wide security, compliance, and planning

Try all GitLab features - free for 30 days

Cover image licensed under Unsplash

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.

Share your feedback

Take GitLab for a spin

See what your team could do with The DevSecOps Platform.

Get free trial

Have a question? We're here to help.

Talk to an expert

GitLab 11.10 Release