Kubernetes-Upgrade, Label-Funktion und etliches mehr

GitLab 8.6 mit Kubernetes-Support und neuer Label-Funktion
Kommentare

Im steten Monatstakt geht es weiter: Exakt 30 Tage nach Erscheinen von GitLab 8.5 kommt jetzt das 8.6er-Upgrade mit neuem Deployment-Feature für Googles Kubernetes, einer neuen Funktion zur besseren Informationsverwaltung sowie weiteren Security- und Design-Updates.

Mit bemerkenswerter Kontinuität liefert das Entwicklerteam der Open Source Repository-Verwaltung GitLab seine monatlichen Versionsupgrades. Konnten sich die Programmierer in der letzten Version über Erfolge in Sachen Performance freuen, hat man sich jetzt vor allem auf Bedienbarkeit und Deployment konzentriert.

Kubernetes-Support für GitLab CI

Auch wenn Docker Swarm seine Performance-Muskeln (in irreführender Weise?) spielen lässt, scheint es Googles Container Cluster-Manager Kubernetes nicht an Interessenten zu mangeln. Grund genug, um dem Continuous Integration-System von GitLab, GitLab CI, ein entsprechendes Feature zu spendieren. Dazu wird „Spread“, ein Command Line-Tool der Firma Redspread, das Command Line-Deployments auf Kubernetes ermöglicht, in GitLab CI integriert. Die Wahl fiel auf Spread, weil es Projektverzeichnisse liest und Kubernetes-Objekte automatisch erzeugt bzw. updatet, daher mit den automatisierten Deployments von GitLab CI harmoniere, so die Entwickler.

Labels

Version 8.6 führt außerdem sogenannte Labels ein, die – vergleichbar mit Google Alerts –Neuigkeiten zu einem bestimmten Thema aggregieren. Sobald das vom User ausgewählte Label in einem Issue erwähnt wird, wird der Nutzer darüber benachrichtigt. So soll es insbesondere bei größeren Projekten leichter fallen, auf dem neuesten Stand zu bleiben und nicht im Strom der Informationen unterzugehen bzw. etwas zu übersehen.

Confidential Issues und External User

Von nun soll es darüber hinaus möglich sein, vertrauliche (confidential) Issues innerhalb eines Projekts zu erstellen, die nur für Teammitglieder des Projekts und den Urheber des Issues sichtbar sind. Das gilt auch, wenn das Projekt öffentlich oder intern ist. Eine Funktion, die gerade bei sensiblen Themen sinnvoll sei, etwa wenn auf Sicherheitslücken hingewiesen wird.

In diesen Themenbereich spielt eine weitere Funktion hinein, nämlich die des externen Nutzers. Immer mehr Organisationen arbeiteten mit internen Projekten, aber nutzten die Hilfe von Drittanbietern. Diese brauchen Zugang zu GitLab, aber nicht zu besagten internen Projekten. Indem man bestimmte User als „external“ markiert, könne man ihnen nun den Zugang untersagen.

Weitere Neuerungen

Daneben wurden noch einige Features eingebaut, die hauptsächlich der Nutzerfreundlichkeit dienen:

  • überarbeitete Dropdown-Menüs
  • die Möglichkeit, Issues zu löschen statt nur zu schließen
  • Issues können zwischen Projekten verschoben werden
  • Commits, in denen eine JIRA-Issue erwähnt wird, werden als Link inkl. Commit Message in besagtem Issue aufgeführt
  • Gruppen kann jetzt ebenfalls ein Sichtbarkeitslevel verliehen werden
  • die Slack-Alternative Mattermost 2.1 wird in GitLab 8.6 mit neuen Android-, Linux- und Mac-Apps ausgeliefert

Wie immer entnimmt man alle weiteren Änderungen – diesmal vor allem zur Performancesteigerung – am besten dem Changlog. Erwähnenswert ist, dass Migrationen notwendig werden und insbesondere bei größeren Instanzen, die mit PostgreSQL arbeiten, etwas Zeit und daher Downtime benötigen können. Zusätzlich müssen PostgreSQL-Nutzer von nun an die pg_trgm-Extension aktivieren.

Wer mit Elasticsearch arbeitet, wird außerdem dazu aufgefordert, das Delete-By-Query-Plugin zu installieren. Und wer von einer GitLab-Version niedriger als 8.0 upgraden möchte und CI aktiviert hat, muss erst das Update auf Version 8.0 durchführen und von dort aus weitermachen.

 

Aufmacherbild: Large modern warehouse with forklifts von Shutterstock / Urheberrecht: Maxim Blinkov

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -