Co się dzieje po tym, jak GitLab pobierze kod?

Po pobraniu kodu (klonowaniu repozytorium), GitLab CI/CD uruchamia pipeline — zestaw zadań (jobs) i etapów (stages), zdefiniowanych w pliku .gitlab-ci.yml w katalogu głównym repozytorium.

Główne etapy typowej pipeline po pobraniu kodu:

1. Stages: Pipeline dzieli się na etapy, które są wykonywane kolejno. Zadania w jednym etapie mogą być wykonywane równolegle.
2. Jobs: Każde zadanie jest wykonywane na osobnym Runnerze. Runner to agent, który pobiera zadanie z GitLab CI/CD i je wykonuje.
3. Commands: Wewnątrz każdego zadania wykonywane są komendy określone w sekcji script w .gitlab-ci.yml. Komendy te mogą obejmować:
   • Budowę projektu (np. kompilacja kodu, pakowanie artefaktów).
   • Uruchamianie testów (jednostkowych, integracyjnych itp.).
   • Sprawdzanie jakości kodu (linting, analiza statyczna).
   • Tworzenie obrazów Docker.
   • Deployment (wdrożenie) w środowiskach testowych, staging lub produkcyjnych.
   • Inne niezbędne działania.
4. Dependencies (Zależności): Zadania mogą zależeć od wyników poprzednich zadań, używając słowa kluczowego needs.
5. Artifacts (Artefakty): Wyniki wykonywania zadań (np. skompilowany kod, raporty z testów, obrazy Docker) mogą być zapisywane jako artefakty, dostępne do pobrania lub używane w kolejnych zadaniach.
6. Caching (Buforowanie): Zależności lub tymczasowe pliki mogą być buforowane pomiędzy uruchomieniami zadań, aby przyspieszyć wykonanie.
7. Reporting (Raportowanie): Wyniki wykonania (sukces/porażka), logi i artefakty są dostępne w interfejsie GitLab.

Przykładowa struktura .gitlab-ci.yml:

stages: # Definicja etapów
  - build
  - test
  - deploy

build_job: # Definicja zadania
  stage: build # Przynależność do etapu
  script: # Komendy do wykonania
    - echo "Buduję projekt..."
    - mvn package # Przykład komendy build z Maven
  artifacts: # Zapisywanie artefaktów
    paths:
      - target/*.jar

test_job:
  stage: test
  script:
    - echo "Uruchamiam testy..."
    - mvn test # Przykład komendy do uruchomienia testów
  needs: # Zależność od poprzedniego zadania
    - build_job

deploy_job:
  stage: deploy
  script:
    - echo "Wdrażanie aplikacji..."
    - docker build -t my-app . # Przykład budowania obrazu Docker
    - docker push my-app # Przykład wysyłki obrazu do repozytorium
  only: # Warunek wykonania zadania
    - main # Tylko przy commitcie na gałęzi main

W ten sposób, po pobraniu kodu, GitLab CI/CD orchestruje wykonanie zdefiniowanego przez użytkownika procesu, skupiającego się na budowie, testowaniu i wdrażaniu aplikacji.