We’re thrilled to share that workspaces are now generally available and ready to improve your developer efficiency!

By creating secure, on-demand remote development environments, you can reduce the time you spend managing dependencies and onboarding new developers and focus on delivering value faster. With our platform-agnostic approach, you can use your existing cloud infrastructure to host your workspaces and keep your data private and secure.

Since their introduction in GitLab 16.0, workspaces have received improvements to error handling and reconciliation, support for private projects and SSH connections, additional configuration options, and a new administrator interface. These improvements mean that workspaces are now more flexible, more resilient, and more easily managed at scale.

You can now enforce whether GitLab administrators are required to use two-factor authentication (2FA) in their self-managed instance. It is good security practice to use 2FA for all accounts, especially for privileged accounts like administrators. If this setting is enforced, and an administrator does not already use 2FA, they must set up 2FA on their next sign-in.

A typical software project relies on a variety of dependencies, which we call packages. Packages can be internally built and maintained, or sourced from a public repository. Based on our user research, we’ve learned that most projects use a 50/50 mix of public and private packages. Package installation order is very important, as using an incorrect package version can introduce breaking changes and security vulnerabilities into your pipelines.

Now you can add one external Java repository to your GitLab project. After adding it, when you install a package using the dependency proxy, GitLab first checks for the package in the project. If it’s not found, GitLab then attempts to pull the package from the external repository.

When a package is pulled from the external repository, it’s imported into the GitLab project. The next time that particular package is pulled, it’s pulled from GitLab and not the external repository. Even if the external repository is having connectivity issues and the package is present in the dependency proxy, pulling the package still works, making your pipelines faster and more reliable.

If the package changes in the external repository (for example, a user deletes a version and publishes a new one with different files) the dependency proxy detects it. It invalidates the package, so GitLab pulls the newer one. This ensures the correct packages are downloaded, and helps reduce security vulnerabilities.

The Issue Analytics report now contains information on the number of closed issues in a month to allow for a detailed velocity analysis. With this valuable addition, GitLab users can now gain insights into trends associated with their projects, and improve the overall turn-around time and value delivered to their customers. The Issue Analytics visualization contains a bar chart with the number of issues for each month, with a default time span of 13 months. You can access this chart from the drill-down in the Value Streams Dashboard.

We added a new DORA Performers score panel to the Value Streams Dashboard to visualize the status of the organization’s DevOps performance across different projects. This new visualization displays a breakdown of the DORA score (high, medium, or low) so that executives can understand the organization’s DevOps health top to bottom.

The four DORA metrics are available out-of-the-box in GitLab, and now with the new DORA scores organizations can compare their DevOps performance against industry benchmarks or peers. This benchmarking helps executives understand where they stand in relation to others, and identify best practices or areas where they might be lagging behind.

To help us improve the Value Streams Dashboard, please share feedback about your experience in this survey.