GitLab behält die monatliche Release-Kadenz neuer Features und Verbesserungen bei. Mit Version 10.6 wird unter anderem die Integration von Kubernetes vertieft. Continious Integration und Continious Delivery sind ebenfalls mit dabei und es gibt nun mehr Möglichkeiten für Maintainer und Features, die bisher nur zahlenden Nutzern vorbehalten waren. Wir haben uns angesehen, was die aktualisierte Fassung der Webanwendung für die Versionsverwaltung sonst noch an Bord hat.
Coole CI- und CD-Integration für GitLab
Continious integration (CI) und Continious Delivery (CD) sind aus dem Alltag vieler Entwickler nicht mehr wegzudenken. Um dieser Entwicklung entgegenzukommen, bietet GitLab 10.6 ab sofort die Möglichkeit, sowohl bei GitHub, als auch externen Repos, mit CI und CD zu arbeiten. Für selbst gehostete GitLab-Projekte gibt es die Integration ab dem Status Premium (nach Libre und Starter), für Open-Source-Projekte auf Gitlab.com ist sie auf allen Stufen verfügbar. Dazu bietet GitLab.com 50.000 freie CI-Pipeline-Minuten pro Monat. Außerdem wird die Integration ein Jahr lang für alle GitHub.com-Nutzer mit 2000 Freiminuten bereitgestellt. Daneben können eigene Runner genutzt und der Plan natürlich jederzeit hochgestuft werden.
Kubernetes wird besser angeknüpft
Bereits mit Version 10.4 wurden die Integrationen für Kubernetes-Cluster und GKE eingeführt, mit 10.6 soll die Integration von Kubernetes weiter vertieft werden. So sollen sich Runner mit nur einem Klick mit Kubernetes-Clustern verbinden lassen und Cluster direkt von GitLab aus überwacht werden. Dort sollen sich sich auch die IP-Adressen von Ingress-Controllern nachvollziehen lassen.
Mehr Macht für Maintainer
Für Maintainer des Upstreams gibt es einen Leckerbissen: So soll es mit der neuen Version von GitLab möglich sein, kleinere – und größere – Fixes und Commits vorzunehmen, bevor ein Merge durchgeführt wird; auch ein Rebase soll möglich sein. Autoren des Source-Branch eines Merge können seit Version 10.6 Maintainern auch Schreibzugriff auf den Source-Branch gewähren. So können Nutzer mit Merge-Erlaubnis für den Branch des Upstream-Projekts auf den Sourch-Branch der Merge-Request pushen. Allerdings muss diese Funktion für den jeweiligen Branch aktiviert werden.
Ganz offen über Probleme reden
Ein Feature, das bisher nur für Premium- und Ultimate-Nutzer verfügbar war, gibt es jetzt auch für Libre- und Starter-Projekte: das Group Issue Board. Zwar gibt es nur ein Board pro Gruppe für die beiden unteren Instanzstufen, aber laut GitLab soll das Board bereits eine große Verbesserung für den Workflow sein. Dasselbe gilt für Free- und Bronze-Instanzen auf GitLab.com. Auch dort wird es ein Board pro Gruppe geben, mehrere Boards bleiben Nutzern mit Silver- und Gold-Account vorbehalten.
Kleine Änderungen und Deprecations
Neben diesen größeren Änderungen sind diverse kleinere Anpassungen und Verbesserungen sowie eine erweiterte Sprachunterstützung für Filipino, Indonesisch und Türkisch an Bord. Außerdem gibt es zwei Deprecations. Die Reduktion der Mattermost-Konfigurationsoptionen innerhalb von gilab.rb wird erst mit Version 11.0 fällig. Die Legacy gitlab-Helm-Chart ist ebenfalls veraltet, GitLab empfiehlt die Nutzung der Betaversion des gitlab-omnibus-Helm-Chart. Zukünftig sollen beide Charts durch ein „Cloud native GitLab Chart“ ersetzt werden. Fälligkeitsdatum für die Deprecation ist der 22. März 2018.
Alle Änderungen im Detail finden sich im umfangreichen Blogpost zum Release auf der Website von GitLab.
