GitLab CI/CD und Pages

Veröffentlicht am 19. Januar 202223. Januar 2022 von fbahr and Julius Hohlfeld

GitLabs Continuous Methodologies

Inhaltsverzeichnis

Allgemeines
Workflow
GitLab CI/CD
- GitLab Pipelines
- GitLab Stages
- GitLab Jobs
GitLab Pages
Quellen

Allgemeines

Die Akronyme CI und CD stehen für:

Continuous Integration
Continuous Delivery
Continuous Deployment

Continuous Integration ist eine Technik innerhalb der agilen Softwareentwicklung, um kohärente Software schneller zu entwickeln. Dahinter verbirgt sich die Idee, dass Teammitglieder ihre entwickelten Features regelmäßig integrieren und diese Integration durch ein automatisches Bauen und Testen der Software verifiziert wird. Das Ziel dabei ist es, Integrationsfehler schneller und frühzeitiger zu identifizieren und somit die Integration von kohärenter Software zu einem non-event zu machen.

Continuous Delivery ist eine Technik innerhalb der agilen Softwareentwicklung, die darauf abzielt, Software nach bestimmten Prinzipien zu entwickeln, sodass diese zu jedem Zeitpunkt released werden kann. Das Ziel dabei ist es, auf Kundenanfragen jederzeit den aktuellen Entwicklungsstand releasen zu können, ohne dass weitere Entwicklungsschritte vorgenommen werden müssen. Wichtig dabei ist, dass die Produktionsbuilds nicht automatisiert veröffentlicht werden, sondern lediglich vorhanden sind.

Continuous Deployment ist eine Technik innerhalb der agilen Softwareentwicklung, die auf Continuous Integration und Continuous Delivery basiert und zusätzlich jede Änderung an der Software nach erfolgreichem Durchlaufen der Produktions-Pipeline als neustes Produktionsbuild veröffentlicht.

Daraus lässt sich folgende Hierarchie der Begriffe ableiten:

Continuous Integration < Continuous Delivery < Continuous Deployment

Workflow

GitLab CI/CD

GitLab präsentiert einige Tools, um die oben beschriebenen kontinuierlichem Methoden abzubilden. GitLab ermöglicht dabei mit den sogenannten GitLab Runnern Jobs innerhalb einer Pipeline laufen zu lassen und somit automatisiert die eigene Software zu bauen, zu testen, zu deployen und zu überwachen. Die Runner können entweder, wie GitLab, selbst gehostet und zur Verfügung gestellt werden oder es werden auf sogenannte Shared Runners zurückgegriffen, die allen Nutzern von GitLab zur Verfügung stehen.

Kernelemente dieser Tools sind innerhalb von GitLab Pipelines, Stages, Jobs und die GitLab Pages.

Um die Kernelemente und Tools zu verwalten und zu konfigurieren, verwendet GitLab eine YAML-File, die den Namen .gitlab-ci.yaml erhalten muss. Innerhalb dieser Konfigurationsdatei kann festgelegt werden, welche Struktur und Jobs eine Pipeline aufweist. Dabei können vordefinierte Variablen verwendet und Entscheidungen, die der GitLab Runner bei bestimmten Bedingungen treffen soll, spezifiziert werden.

GitLab Pipelines

Pipelines bilden die Top-Level Komponente und bestehen aus Stages und Jobs. Pipelines können dabei verschiedenen Status haben. Sie sind entweder pending (ausstehend), running (laufend), done (fertig, erfolgreich) oder failed (fehlgeschlagen). Dabei weist eine Pipeline granular betrachtet folgende Verhaltensweisen auf: Wenn alle Jobs innerhalb einer Stage erfolgreich sind, geht der Runner innerhalb der Pipeline zur nächsten Stage über, solange bis alle Stages abgeschlossen sind. Wenn irgendein Job fehlschlägt, so wird die Pipeline angehalten und die gesamte Pipeline als fehlgeschlagen betrachtet. Der Zustand pending ist der initiale Startzustand der solange gilt, bis ein GitLab Runner mit der Bearbeitung der Pipeline angefangen hat.

GitLab Stages

Stages dienen zur Gruppierung von Jobs und beschreiben innerhalb einer Pipeline eine sequentielle Ausübung dieser Jobs. Sie definieren ebenso innerhalb einer Pipeline gewisse Phasen.
Jobs laufen dabei, falls genügend GitLab Runner zur Verfügung stehen, parallel ab. Mit der Hilfe von Stages können in der Konfigurationsdatei Abhängigkeiten innerhalb der Pipeline spezifiziert und somit einen gerichteten, azyklischen Graphen (DAG) aufgebaut werden. Stages können mithilfe des stages–Keyword definiert werden.

GitLab Jobs

Jobs bilden die atomaren Bestandteile einer Pipeline und definieren die Aktionen, die vom GitLab Runner ausgeführt werden sollen (keyword scripts). Die Aktionen sind dabei Kommandozeilenbefehle. Wie bereits erwähnt, können diese zu Stages gruppiert werden (keyword stage). Ebenfalls können für jeden Job Bedingungen spezifiziert werden, wann dieser Job ausgeführt werden soll (keywords except/only). Oft wird dies auf den Namen des Branches reduziert, das bedeutet, ein Job läuft nur dann, wenn ein Commit auf den jeweils spezifizierten Namen ausgeführt wird. Entstehende Dateien innerhalb eines Jobs und einer Stage können gespeichert und so dem Entwickler per Download und automatisiert der nächsten Stage zur Verfügung gestellt werden (keyword artifacts). Dafür muss angegeben werden, welche Dateipfade zu den Artefakten gezählt werden (keyword paths). Ebenso kann spezififziert werden, wann und wie lange Artefakte hochgeladen werden sollen (keywords expire_in und when).

GitLab Pages

GitLab Pages ist ein weiteres Tool von GitLab, welches Nutzern ermöglicht, statische Webseiten mithilfe der GitLab CI/CD Pipeline zu publizieren. Somit wird ein kostenloses Publizieren direkt vom eigenen Repository aus möglich. Ein Nachteil stellt jedoch die Einschränkung dar, dass lediglich per Static Site Generator erzeugte oder in plain HTML/JavaScript geschriebene Webseiten veröffentlicht werden können. Daraus resultiert, dass keine komplexen Web-Applikationen, die auf ein Back-End und Datenbanken zurückgreifen, per GitLab Pages publiziert werden können.

Abgesehen von diesem Nachteil ist es möglich, die eigene Webseite unter der Domäne *.gitlab.io oder einer eigenen Domäne, falls vorhanden, zu deployen. Wird die Domäne von GitLab verwendet, so wird automatisch aus dem Benutzernamen die Domäne generiert (<benutzername>.gitlab.io). Zur Veröffentlichung greift GitLab Pages auf die Konfigurationsdatei .gitlab-ci.yml zurück, in der ein Job namens pages spezifiziert werden muss. Somit erkennt GitLab, dass die Dateien im Repository veröffentlicht werden sollen und kopiert alle Dateien innerhalb des public-Ordners auf den GitLab Pages Server. Die Webseite wird bei der GitLab Domäne dabei automatisch verschlüsselt und per HTTPS ausgeliefert.

GitLab CI/CD Konfigurationsdatei

‣ Click to expand

image: node:17 # defines the docker image

stages: # stages of pipeline
  - build
  - test
  - deploy
  - cleanup

build-component-library: # first job
  stage: build # in stage build
  tags: # set specific gitlab runner
    - docker
  artifacts: # files that should be saved
    paths: # path of files
      - dist
      - node_modules
  script: # scripts to execute
    - ./bin/check-package-lock.sh
    - npm run init
    - npm run build
  except: # control when jobs are added to pipeline -> except when it should not run
    - triggers # when pipeline is triggered by an api endpoint

lint:
  stage: test
  tags:
    - docker
  script:
    - npm run prettier:check
    - npm run lint
  except:
    - triggers

unit-test:
  stage: test
  tags:
    - docker
  script:
    - npm run test
  except:
    - triggers

integration-test:
  stage: test
  tags:
    - docker
  script:
    - npm run integration-test
  artifacts: # files that should be saved
    paths: # path of files
      - e2e/report
    expire_in: 1 week # expire after 1 week
    when: always # upload nomatter if the job fails or not (on_success, on_failure)
  except:
    - triggers

pages:
  stage: deploy
  tags:
    - docker
  artifacts:
    paths:
      - public
  script:
    - npm run convert-readme-to-html
    - npm run build
    - mkdir -p public
    - mv dist/* public/
  except:
    - triggers
  only: # control when jobs are added to pipeline -> only when it should run
    - main # runs when the branch name equals master

clean:
  stage: cleanup
  tags:
    - docker
  script:
    - ./bin/cleanup.sh
  needs:
    - ["pages"]
  except:
    - triggers
  only:
    - main