Gitlab-CI

Infrastruktura procesów gitlab-ci

Pipeline składa się z jobów (zadań) pogrupowanych w stage (etapy), np. build, test, deploy. GitLab CI uruchamia je w określonej kolejności, a wykonanie może odbywać się na GitLab Runnerach – agentach uruchamiających zadania.

Dzięki GitLab CI/CD możliwe jest ciągłe dostarczanie (CD), czyli automatyczne wdrażanie aplikacji na produkcję lub do środowisk testowych. Obsługuje kontenery, chmury i infrastruktury on-premise, ułatwiając zarządzanie cyklem życia oprogramowania.

---
config:
  theme: neo
  layout: dagre
  look: neo
---
flowchart LR
 subgraph s5["Przestrzeń CI/CD"]
        n18["gitlab-ci"]
        n19["components"]
  end
    n18 --> n19
    s5 --> n11["containers"]
    n11 --> n22["Job"]
    n23["Run pipeline"] --> s5
    n24["Event"] --> n23
    n18@{ shape: rect}
    n19@{ shape: procs}
    n11@{ shape: procs}
    n22@{ shape: lean-r}
    n23@{ shape: in-out}
    n24@{ shape: event}
     n22:::Pine
     n23:::Pine
    classDef Aqua stroke-width:1px, stroke-dasharray:none, stroke:#46EDC8, fill:#DEFFF8, color:#378E7A
    classDef Sky stroke-width:1px, stroke-dasharray:none, stroke:#374D7C, fill:#E2EBFF, color:#374D7C
    classDef Pine stroke-width:1px, stroke-dasharray:none, stroke:#254336, fill:#27654A, color:#FFFFFF

Architektura projektu gitlab-ci w pl.rachuna-net/cicd

Projekt zawiera

pl.rachuna-net/cicd
├─ gitlab-ci                 # repozytorium z generycznymi procesami ci
├─ gitlab-profile            # Dokumentacja techniczna
└─ components                # grupa zawierająca komponenty (`ci/cd catalog`)
    ├── ast                  # Komponent do analizy pod kątem bezpiecezństwa (Application Security Testing).
    ├── containers           # Komponent odpowiedzialny za budowanie i publikacje kontenerów.
    ├── infrastructure       # Komponent odpowiedzialny za zarządzanie infrastrukturą.
    ├── prepare              # Komponent do przygotowania procesu CI/CD.
    ├── release              # Komponent do zarządzania wersjami i publikacji bibliotek i aplikacji na środowiska produkcyjne
    └── validate             # Komponent do automatycznej walidacji jakości i poprawności kodu w procesach CI/CD.

Projekt jest podzielony na logiczne komponenty, z których każdy odpowiada za określony etap w procesie CI/CD. Oto główne katalogi i ich funkcje:

• components: Zawiera komponenty odpowiedzialne za różne zadania, takie jak analiza statyczna kodu (SAST), testy jednostkowe, walidacja konfiguracji, budowanie i publikowanie artefaktów.
• gitlab-ci: Zawiera konfiguracje pipeline’ów, w tym pliki YAML definiujące etapy i zadania.
• gitlab-profile: Dokumentacja i skrypty wspierające konfigurację GitLab CI/CD.

Dlaczego taki układ jest korzystny?

Taki podział projektu pl.rachuna-net/cicd zapewnia:

1. Czytelność i modularność

   • Każdy komponent ma jasno określoną odpowiedzialność (np. containers tylko dla kontenerów, validate tylko dla walidacji kodu).
   • Ułatwia to nowym członkom zespołu szybkie odnalezienie się w strukturze – nie muszą przeszukiwać jednego, wielkiego pliku .gitlab-ci.yml.

2. Reużywalność procesów

   • Komponenty działają jak katalog CI/CD – można je wielokrotnie wykorzystywać w różnych projektach.
   • Na przykład prepare lub release mogą być użyte zarówno w projekcie backendowym, jak i frontendowym, bez potrzeby pisania wszystkiego od nowa.

3. Łatwa konserwacja i rozwój

   • Modyfikacja lub poprawka w jednym komponencie (np. ast) nie wpływa bezpośrednio na inne procesy – minimalizuje to ryzyko przypadkowych błędów.
   • Komponenty można rozwijać niezależnie, wprowadzając nowe funkcjonalności w sposób kontrolowany.

4. Skalowalność

   • Wraz z rozwojem organizacji można dodawać kolejne komponenty (np. performance-tests, security-audit) bez przebudowy całej architektury.
   • Każdy komponent może być utrzymywany przez inny zespół lub osobę, co umożliwia równoległy rozwój.

5. Standaryzacja procesów

   • Dzięki centralizacji komponentów wszystkie projekty w organizacji korzystają z tych samych procedur CI/CD, co zwiększa spójność i przewidywalność procesów.
   • Aktualizacja standardów (np. zmiana polityki wersjonowania w release) jest natychmiast dostępna dla wszystkich projektów.

6. Łatwe wdrożenie nowych projektów

   • Aby dodać CI/CD do nowego repozytorium, wystarczy włączyć potrzebne komponenty z katalogu – nie trzeba od zera pisać pipeline’ów.

Wady i ograniczenia takiego układu

Choć architektura oparta na modułowych komponentach CI/CD ma wiele zalet, wiąże się też z pewnymi wyzwaniami. Wymaga dyscypliny w utrzymaniu zgodności wersji komponentów pomiędzy projektami, aby uniknąć sytuacji, w której różne repozytoria korzystają z niekompatybilnych wersji tego samego procesu. Centralizacja logiki powoduje również, że błąd w jednym komponencie może wpłynąć na wiele projektów jednocześnie, jeśli zostanie wdrożony bez odpowiedniego testowania. Dodatkowo w większych organizacjach może pojawić się konieczność koordynacji prac między zespołami rozwijającymi poszczególne komponenty, co może spowalniać wdrażanie zmian.