GitLab CI/CD¶

GitLab CI/CD kann bei iterativen Code-Änderungen eure Anwendungen automatisch erstellen, testen, bereitstellen und überwachen. Dies verringert die Gefahr, dass ihr neuen Code auf der Grundlage fehlerhafter Vorgängerversionen entwickelt. Dabei sollen von der Entwicklung bis zu seiner Bereitstellung von Code-Änderungen wenige oder gar keine menschlichen Eingriffe erforderlich sein.

Die drei wichtigsten Ansätze für diese kontinuierliche Entwicklung sind:

Continuous Integration

führt eine Reihe von Skripten sequentiell oder parallel aus, die eure Anwendung automatisch erstellt und testet, z.B. nach jedem git pull in einem Feature-Branch. Damit soll es weniger wahrscheinlich werden, dass ihr Fehler in eure Anwendung einbringt.

Wenn die Überprüfungen wie erwartet funktionieren, könnt ihr einen Merge Request stellen; schlagen die Überprüfungen fehl, könnt ihr die Änderungen ggf. zurücknehmen.

Siehe auch

Kontinuierliche Integration

Continuous Delivery

geht einen Schritt weiter als Kontinuierliche Integration und stellt die Anwendung auch kontinuierlich bereit. Dies erfordert jedoch noch einen manuellen Eingriff, um die Änderungen manuell in einem Deployment Branch bereitzustellen.

Siehe auch

Continuous Deployment

führt auch die Bereitstellung der Software auf die Produktiv-Infrastruktur automatisch durch.

Aktivieren von CI/CD in einem Projekt¶

Wählt in der oberen Leiste Menü ‣ Projekte und sucht euer Projekt.
Wählt in der linken Seitenleiste Einstellungen ‣ Allgemein.
Erweitert Visibility, project features, permissions.
Aktiviert im Abschnitt Repository die Option CI/CD.
Wählt Änderungen speichern.

CI/CD-Pipelines¶

Pipelines sind die wichtigste Komponente der Continuous Integration, Delivery und Deployment.

Pipelines bestehen aus:

Jobs: legen fest, was zu tun ist, z.B. Kompilieren von Code oder Testen.

Siehe auch

Jobs
Stages: legen fest, wann die Jobs ausgeführt werden sollen, z.B. die Phase test, die nach der Phase build ausgeführt werden soll.

Siehe auch

Stages

Jobs werden von sog. Runners ausgeführt. Mehrere Jobs in einem Stage werden parallel ausgeführt, sofernes genügend gleichzeitige Runner zur Verfügung stehen.

Wenn alle Jobs in einem Stage erfolgreich sind, fährt die Pipeline mit dem nächsten Stage fort.

Schlägt ein Job in einem Stage fehl, wird der nächste Stage normalerweise nicht ausgeführt, und die Pipeline wird vorzeitig beendet.

Im Allgemeinen werden Pipelines automatisch ausgeführt und erfordern nach ihrer Erstellung keinen Eingriff. Es gibt jedoch auch Fälle, in denen ihr manuell in eine Pipeline eingreifen könnt.

Eine typische Pipeline kann aus vier Stages bestehen, die in der folgenden Reihenfolge ausgeführt werden:

Eine build-Stage mit einem Job namens compile.
Eine test-Stage mit zwei parallelen Jobs namens unit-test und lint.
Eine staging-Stage mit einem Job namens deploy-to-stage.
Eine production-Stage mit einem Job namens deploy-to-prod.

Die zugehörige .gitlab-ci.yml-Datei könnte dann so aussehen:

image: "docker.io/ubuntu"

stages:
  - build
  - test
  - staging
  - production

compile:
  stage: build
  script:
    - echo "Compiling the code..."
    - echo "Compile complete."

unit-test:
  stage: test
  script:
    - echo "Running unit tests... This will take about 60 seconds."
    - sleep 60
    - echo "Code coverage is 0%"

lint:
  stage: test
  script:
    - echo "Linting code... This will take about 10 seconds."
    - sleep 10
    - echo "No lint issues found."

deploy-to-stage:
  stage: stage
  script:
    - echo "Deploying application in staging environment..."
    - echo "Application successfully deployed to staging."

deploy-to-production:
  stage: production
  script:
    - echo "Deploying application in production environment..."
    - echo "Application successfully deployed to production."

Pipelines anzeigen¶

Ihr findet die aktuellen und historischen Pipeline-Runs auf der Seite CI/CD ‣ Pipelines eures Projekts. Ihr könnt auch auf Pipelines für einen Merge-Request zugreifen, indem ihr zu deren Registerkarte Pipelines navigiert. Wählt eine Pipeline aus, um die Seite Pipeline-Details zu öffnen und die Jobs anzuzeigen, die für diese Pipeline ausgeführt wurde. Von hier aus könnt ihr eine laufende Pipeline abbrechen, Jobs in einer fehlgeschlagenen Pipeline erneut versuchen oder eine Pipeline löschen.

Siehe auch