GitLab calls on first responders to ‘triage incidents’ as version 13.3 hoves into view

GitLab calls on first responders to ‘triage incidents’ as version 13.3 hoves into view
Gitlab Logo

In tune with its usual release rhythm, the team behind DevOps platform GitLab has pushed version 13.3 of its product out, featuring a handy way of creating multiple jobs, better security testing on all tiers, and some improvements for Kubernetes users.

Since GitLab tries to stick to what it calls a “community stewardship commitment”, which  ideally ensures the open source version includes everything essential for running a large repository setup, it used the release to make its static application security testing analysers available across tiers. Commercial users on the highest subscription level will know SAST already. As a perk, however, they are treated to additional setup support in this release, which is meant to help them configure this particular form of testing quicker. 

But there are more areas in which security improved for teams on the ultimate/gold tier. Gold-card holders are now, for example, able to conduct dynamic application security testing scans when needed and not just in the context of a pipeline. GitLab 13.3 is also the first version to incorporate the fuzz testing capabilities the company acquired through buying Peach Tech and Fuzzit earlier this year. Through it, ultimate/gold users are now able to test their Go and C/C++ apps by feeding it random inputs. Like this, they should have an easier time finding mishaps which would have been hard to get to otherwise before making the step into production.

Another aspect of keeping a system secure is keeping a watch on it, which is why monitoring is another focal point of v13.3. “We are now allowing you [..] to create and triage incidents inside GitLab” VP of product management, Anoop Dawar mentions as an example in a call with DevClass. “Imagine if you are a responder responsible for maintaining the availability or reliability of a service for your customers. You want to be able to quickly see the list of your active incidents to make sure ongoing problems are being responded to and teams are meeting their SLO”. 

To help with this, GitLab 13.3 features a dedicated list of triage incidents for a better overview, a way to fit alerts with a link to the log of the matter or metric that made it fire, and capabilities to let users add runbooks to alerts, so that it’s easier for the person on-call to react quickly.

A small but really neat feature that deserves to be pointed out is a matrix syntax for configuring a pipeline that generates multiple jobs with different variables. This should save users some typing work, when for example building a variety of debug versions for a number of architectures for testing purposes. The whole thing is realised via a matrix keyword which can be used along with parallel, while the different values of a variable are noted in square brackets.

According to Dawar, the Kubernetes-related goodies of the release mainly have to do with configuration. One of them is a Kubernetes agent, which Dawar describes as a “GitOps style integration between GitLab and any Kubernetes cluster”. It will “remove a lot of limitations and open possibilities for many deep integrations with Kubernetes because now we will have a presence and active component in the cluster”.

“The other piece that’s Kubernetes-related,” Dawar told DevClass, “is the GitLab Terraform Flow. GitLab administrators can now use Terraform to attach Kubernetes clusters, to run CI jobs, or to deploy releases at an instance level.” 

Earlier versions allowed this only on the level of project groups. To make sure users stay on top of the health of their pods, GitLab 13.3 also includes a dedicated dashboard for that, which – once connected to a Prometheus instance – displays metrics ranging from CPU usage to network behaviour.

Other changes worth investigating are for example functions to build and publish packages, which are now available across tiers. The user interface is also said to display details and metadata, so that, once a package has been published via GitHub “you can look at which branch and commit was actually responsible for the package right there” Dawar points out.