The centralised approach: Not great for contact-tracing apps, but sensible for alert management in GitLab 13.1

The centralised approach: Not great for contact-tracing apps, but sensible for alert management in GitLab 13.1

Repository management cum DevOps platform GitLab has put improved alert management and code quality in the center of version 13.1, its latest monthly release.

After they’ve made the jump to the new release, users across tiers will have the option to bring together alerts from multiple services in an Alert Management interface. Within the interface, they’ll be able to get more information about an alert, create Incident Issues from it, and assign someone to look into what caused a warning, amongst other things. 

The DevOps slinger has planned upcoming versions that make further tweaks, including a display of relevant metrics and logs connected to the alerts shown, an Alert Integration Builder for better integration with additional monitoring tools, and ways to associate runbooks.

Another new feature available to all users aims to help teams create more inclusive services, by showing developers how a merge request will affect the accessibility of an application’s web interface. Speaking of merge requests, the MR reviews feature has been moved to the core of GitLab, making it available to all users. The feature was introduced in an earlier version to allow reviewers to submit multiple comments at once. This approach has the advantage of not pushing notifications for every typo found to the author of the request.

On top of that, reviewers can now look into definitions when checking code without having to fall back on external tools. To enable this functionality, teams have to add “a new job to the project’s .gitlab-ci.yml file, which specifies an LSIF report”. An additional code coverage graph is supposed to give users a better idea of how much of a code base is checked during tests and how this percentage has changed over time, thus ensuring code coverage targets are hit.

Comment threads discussing design details can be marked as “resolved” in 13.1, granting a better overview of what’s still to do, organisations can add expiration dates of SSH keys via /user/keys and /users/:id/keys, and CI/CD variables can be set at instance-level if needed. More information on new features can be found in GitLab’s blog about the release.

Premium/silver and ultimate/gold users can look forward to a new UI for setting feature flag strategies across environments. GitLab 13.1 also includes a new strategy called lists that allows admins to create and modify lists of user IDs which can then be used to roll out new features to those people only. 

Additional security features restricted to ultimate/gold subscribers cover tasks like exporting vulnerabilities lists from group security dashboards, static application security scanning for Helm charts, and policy management for container network policies.

The release follows the typical schedule of releases on the 22nd of each month, but comes just days after the company announced acquisitions to make fuzzy testing a more integral part of its platform.