Nowy GitLab 12.2: skomplikowane zależności międzyprojektowe przestają być straszne

Adam Golański , 03.09.2019 r.
github1

Rozwijany początkowo jako narzędzie do zarządzania kodem źródłowym GitLab, już od dawna uważany jest za kompletne rozwiązanie do devopsów. Co tu jeszcze można dodać? Najwyraźniej jednak można. Najnowsze wydanie 12.2 ma pomóc zespołom w optymalizacji ich potoków, usprawnić współpracę i lepiej zarządzać współzależnościami między projektami. I nie są to tylko marketingowe hasła.

Kolejność ma znaczenie

Do tej pory GitLab pozwalał na określenie zależności zadań poprzez określanie kolejnych etapów pracy. Coraz bardziej złożone zależności między zadaniami w potokach ciągłej integracji będą w wersji 12.2 lepiej obsłużone za sprawą wsparcia dla skierowanych acyklicznych grafów (DAG). Ma to zastosowanie najczęściej w sytuacji budowania na wiele platform i złożonych sieci zależności, np. w systemach operacyjnych czy wdrażaniu niezależnych, lecz powiązanych ze sobą mikroserwisów.

Wsparcie dla DAG pozwala teraz programistom zdefiniować warunki wstępne pracy za pomocą słowa kluczowego

needs:
. Pozwoli ono na równoczesne wykonanie poszczególnych etapów potoku, gdy tylko wymagane przez nie zadania zostaną zrealizowane.

W budowaniu złożonych systemów pomoże też w nowym GitLabie możliwość zarządzania zależnościami między projektami dla żądań scalenia. Programiści będą mogli określić kolejność, według której dane żądanie scalenia ma być zastosowane, gdy zawiera zmiany obejmujące wiele projektów. Doprowadzić ma to do sytuacji, w której nie będzie się już umieszczało wielu projektów w jednym repozytorium, tylko dlatego aby uniknąć komplikacji wynikających ze scaleń w niewłaściwej kolejności.

Jedno miejsce dla projektantów i programistów

Ciekawą nowością, choć póki co eksperymentalną, jest zarządzanie designem, otwierające nowe możliwości współpracy pomiędzy programistami i projektantami. Pozwala ono na powiązanie zasobów projektowych, takich jak szkice i makiety, z konkretnymi tematami. Ułatwia to koordynację pracy wszystkich interesariuszy, w tym projektantów, deweloperów i menedżerów produktów – będą korzystać z jednego, autorytatywnego źródła zasobów.

Znalazło się też coś dla korzystających z Kubernetes. Możliwe stało się udostępnienie tego samego klastra różnym środowiskom projektowym (np. dev i stage). Każde z nich dostaje oczywiście swój własny zbiór uprawnień, więc bez obawy że dojdzie do kolizji, efektywniej można wykorzystywać zasoby i łatwiej tym wszystkim zarządzać. Każde środowisko projektowe działa bowiem w odrębnej przestrzeni nazw Kubernetes.

Oprócz tych zmian, nowy GitLab wprowadza m.in. możliwość wprowadzania nowych funkcji widocznych tylko dla wskazanych użytkowników, wymuszenie zatwierdzeń bezpieczeństwa dla wskazanych żądań scalenia, ograniczenia członkostwa w grupie dla adresów mailowych tylko w określonej domenie. Z kompletną listą nowości można zapoznać się na blogu projektu.

Najnowsze oferty pracy:

Polecane wpisy na blogu IT: