GitLab 13.0 hievt das Anforderungsmanagement auf die Applikationsebene
Das Major Release für 2020 verspricht Nutzern mehr Kontrolle über Entwicklungs- und Release-Prozesse sowie bei Sicherheit und Compliance.
Im Zuge der planmäßigen monatlichen Updates hat GitLab jetzt das diesjährige Major Release 13.0 der gleichnamigen Versionsverwaltungsplattform vorgelegt. Die Überarbeitungen konzentrieren sich auf das Verwalten und Kontrollieren der Entwicklungs- und Software-Release-Prozesse, engere Zusammenarbeit in Projektteams sowie die Sicherheits- und Compliance-relevanten Funktionen. Unter anderen hat GitLab das in Version 12.10 als eigene Kategorie etablierte Anforderungsmanagement weiter ausgebaut und zusätzliche Optionen für den Umgang mit Schwachstellen integriert.
Anforderungsmanagement für Applikationen
Nutzer sind nicht länger auf externe Tools für das Anforderungsmanagement angewiesen, seit GitLab die notwendigen Voraussetzungen dafür im vorangegangenen Release geschaffen hat. Während sich Anforderungen bereits auf Projektebene erstellen und anzeigen ließen, geht GitLab nun einen Schritt weiter und ergänzt die Möglichkeit, spezifische Anforderungen für die Anwendungen eines Nutzers zu erstellen und zu verwalten. In Zukunft soll außerdem die Rückverfolgbarkeit zwischen den Anforderungen sichergestellt werden, um Compliance und Vollständigkeit nachvollziehbar zu gestalten.
Über die sogenannten Feature Flags können Entwickler neue Funktionen ihrer Anwendung in den Release-Prozess integrieren und weitgehend gefahrlos auf die etwaigen Auswirkungen spezieller Features live testen. Dazu lassen sich neue Funktionen über die Feature Flags dynamisch aktivieren und deaktivieren. In künftigen GitLab-Releases sollen sich Feature Flags zudem auch aus Merge Requests erstellen und nach ihrem Status filtern lassen. Darüber hinaus sollen Nutzer die Möglichkeit erhalten, auf Feature Flags basierende A/B-Tests durchführen zu können.
Mehr Sicherheit und Compliance
Als integrale CI-Elemente stellt GitLab Nutzern unter anderem Sicherheitsfunktionen wie Static Application Security Testing (SAST), Secrets Detection und Dynamic Application Security Testing (DAST) zur Verfügung. In Version 13.0 erweitert sich das Angebot unter anderen um SAST für das .NET-Framework – inklusive erweitertem Support für Offline-Umgebungen –, DAST-Scans für REST-APIs sowie die Suche nach Secrets über die gesamte Commit-Historie hinweg.
Da GitLab offiziell als CNA (Common Vulnerabilities and Exposures (CVE) ID Numbering Authority) zugelassen ist, können Nutzer unmittelbar CVEs beantragen – sowohl für GitLab selbst als auch sämtliche auf GitLab.com gehosteten Projekte. In Zukunft sollen sich CVE IDs sogar direkt aus dem UI heraus anfordern lassen.
Breaking Changes im GitLab Runner
Unter den Neuerungen in GitLab 13.0 finden sich einige Breaking Changes, die vor allem den GitLab Runner betreffen. So werden beispielsweise Windows 1803 und Fedora 29 nicht mehr unterstützt und aus dem Shell Executor heraus steht Windows Batch cmd nicht mehr zur Verfügung. GitLab hatte bereits in Version 11.11 angekündigt, zugunsten von PowerShell auf die cmd-Shell verzichten zu wollen.
Umstellungen sind auch im Hinblick auf Docker-Services erforderlich, denn der bisher noch zulässige Flag --docker-services fällt weg, sodass eine Option wie gitlab-runner register --docker-services postgres nicht mehr als gültiger Array von Strings erkannt wird, um den Dienst zu aktivieren. Anwender müssen daher auf die in GitLab Runner 12.7 eingeführte Möglichkeit, einen Dienst-Alias aus der Konfiguration im Docker-Executor zuzulassen, umsteigen. Hilfestellung leistet dabei ein Migrationsbeispiel.
Einen kompakten Überblick der einzelnen Neuerungen in GitLab 13.0 bietet das Video mit Scott Williamson, einzelne Aspekte beleuchten die Kick-off-Videos zum Major Release. Generelle Informationen zur GitLab-Plattform finden sich auf der Website. (map)
