GITLAB-CI - Infrastruktura procesów gitlab-ci¶

Info

W dzisiejszym artykule przedstawię, jak zorganizować i zautomatyzować procesy CI/CD w GitLab, bazując na strukturze projektu, który implementuje różne komponenty i etapy pipeline'u. Omówię kluczowe elementy, takie jak analiza statyczna kodu, testy jednostkowe, walidacja konfiguracji, budowanie artefaktów oraz wdrażanie aplikacji. Wszystko to z pominięciem katalogu _old, który zawiera przestarzałe lub zarchiwizowane dane.

Kod źródłowy projektu znajduje się tutaj.

Struktura Projektu¶

Tip

Taki podział komponentów jest bardzo dobry pod kątem odpowiedzialności różnych zespołów i ułatwia zarządzanie procesami CI/CD.

pl.rachuna-net/cicd/
├─ gitlab-ci                 # repozytorium z generycznymi procesami ci
├─ gitlab-profile
└─ components                # grupa zawierająca komponenty (`ci/cd catalog`)
    ├── build
    ├── container
    ├── deploy
    ├── integration-test
    ├── publish
    ├── sast
    ├── unit-test
    ├── validate
    └── versioning

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.

Rozdzielenie odpowiedzialności¶

Każdy komponent odpowiada za konkretny etap procesu CI/CD, co pozwala przypisać odpowiedzialność za jego rozwój i utrzymanie do odpowiedniego zespołu. Dzięki temu zespoły mogą skupić się na swoich specjalizacjach, co zwiększa efektywność i jakość pracy.

Example

integration-test:

Zespół testerów odpowiada za rozwój i utrzymanie testów integracyjnych. Dzięki temu mają pełną kontrolę nad tym, jak testy są definiowane i wykonywane.

unit-test:

Zespół deweloperów może odpowiadać za komponent testów jednostkowych, ponieważ to oni najlepiej znają kod i jego strukturę.

deploy:

Zespół DevOps zarządza procesem wdrażania, co pozwala im na optymalizację i dostosowanie pipeline'ów do infrastruktury.

Modularność i ponowne użycie¶

Każdy komponent jest niezależny i może być używany w różnych projektach. Dzięki temu można łatwo ponownie wykorzystać komponenty w różnych pipeline'ach. Zmiany w jednym komponencie (np. sast dla analizy bezpieczeństwa) nie wpływają na inne części systemu.

Skalowalność¶

Podział na komponenty pozwala na skalowanie zespołów i procesów. Nowe zespoły mogą łatwo przejąć odpowiedzialność za istniejące komponenty lub tworzyć nowe. W miarę rozwoju organizacji można dodawać kolejne komponenty bez wpływu na istniejące.

Łatwiejsze zarządzanie i utrzymanie¶

Każdy komponent jest odpowiedzialny za jedną rzecz (zgodnie z zasadą Single Responsibility Principle). Dzięki temu zmiany w jednym komponencie są łatwiejsze do zarządzania i testowania. Problemy są szybciej identyfikowane, ponieważ każdy komponent ma jasno określoną odpowiedzialność.

Przejrzystość i współpraca¶

Taki podział ułatwia współpracę między zespołami. Każdy zespół wie, za co jest odpowiedzialny i jakie komponenty są w jego zakresie. Komponenty są jasno zdefiniowane, co ułatwia komunikację między zespołami.

Kluczowe Etapy Pipeline'u¶

1. Walidacja Konfiguracji¶

Komponenty takie jak validate odpowiadają za sprawdzanie poprawności konfiguracji. Przykładowo, plik validate/docs/terraform.md opisuje, jak używać terraform fmt i terraform validate do walidacji kodu Terraform.

2. Testy Jednostkowe¶

Testy jednostkowe są kluczowym elementem każdego pipeline'u. Dokumentacja w unit-test/docs/terraform.md opisuje, jak uruchamiać terraform plan w celu analizy zmian w infrastrukturze.

3. Analiza Statyczna Kodów (SAST)¶

Komponent SAST, opisany w sast/docs/sonarqube-scanner.md, integruje się z SonarQube, aby przeprowadzać analizę statyczną kodu. Wymaga on dostępu do platformy SonarQube oraz obrazu kontenera sonar-scanner.

4. Budowanie i Publikowanie Artefaktów¶

Proces budowania i publikowania artefaktów jest opisany w build/docs/packer.md. Używane są narzędzia takie jak packer, które walidują i budują obrazy maszyn wirtualnych.

5. Wdrażanie¶

Komponent deploy odpowiada za wdrażanie aplikacji i infrastruktury. Dokumentacja w tym zakresie jest dostępna w katalogu deploy.

Standaryzacja i Checklisty¶

W każdym z komponentów znajdują się szablony merge requestów, takie jak sast/.gitlab/merge_request_templates/CodeReview.md. Szablony te zawierają checklisty, które pomagają weryfikować jakość kodu i zgodność ze standardami.

Podsumowanie¶

Struktura projektu oraz zastosowane komponenty pozwalają na pełną automatyzację procesów CI/CD w GitLab. Dzięki modularnemu podejściu każdy etap pipeline'u jest łatwy do zarządzania i rozszerzania. Mam nadzieję, że ten artykuł pomoże Ci w organizacji własnych procesów CI/CD.