GitLab - CI/CD: Unterschied zwischen den Versionen

GitLab

Allgemeine Informationen

Anleitung
Informationen
Betriebssystem	Alle
Service	GitLab
Interessant für	Angestellte, Studierende und Gäste
HilfeWiki des ZIM der Uni Paderborn

no displaytitle found: GitLab - CI/CD

Mit GitLab CI/CD bietet GitLab bei der Softwareentwicklung Module für:

Continuous Integration (CI)
Continuous Delivery (CD)
Continuous Deployment (CD)

bereit. Weitere Informationen über dieses Konzept finden Sie im GitLab Wiki.

GitLab CI/CD einrichten[Bearbeiten | Quelltext bearbeiten]

GitLab CI/CD wird über die Datei .gitlab-ci.yml konfiguriert. Die Datei muss dafür im Root-Verzeichnis des GitLab Repositories liegen und wird von GitLab automatisch erkannt.

Sie können die Datei in der GitLab Weboberfläche erzeugen, indem Sie über den Dialog + > New File > .gitlab-ci.yml eine Vorlage auswählen.

GitLab stellt hier einige Templates bereit, mit denen Sie arbeiten können. Wählen Sie hier ein Template aus, welches Ihrer Anwendung am nächsten kommt.

Pipelines[Bearbeiten | Quelltext bearbeiten]

Piplines sind die Top-Level Komponenten für CI/CD. Eine Pipeline kann mehrere Stages beinhalten. Stages definieren, wann etwas ausgeführt werden soll. Sie werden innerhalb der Pipline in angegebener Reihenfolge ausgeführt (z.B. Build, Test, Deploy Stage, Deplay Production). Was ausgeführt werden soll wird über sogenannte Jobs definiert. Wenn ein Runner alle Jobs einer Stage erfolgreich abschließen, wird mit der nächsten Stage fortgefahren. Sind alle Stages erfolgreich abgeschlossen wurde die Pipline erfolgreich durchlaufen.

Arten von Pipleline Konfiguartionen

Da es unterschiedliche Anforderung an die Möglichkeiten einer Pipeline in der Softwareentwicklung gibt, stellt GitLab unterschiedliche Pipline Konfigurationen zur Verfügung:

einfache Pipelines, die Stages nacheinander abarbeiten
Pipelines die für Merge-Requests ausgeführt werden
Pipelines für Merge-Results, die nach einem Merge ausgeführt werden
Multi-Project Pipelines können mehrere Projekte zusammen ausführen
Parent-Child Pipelines, bei denen eine Parent Pipeline mehrere Child Pipelines ausführen kann

Stages[Bearbeiten | Quelltext bearbeiten]

Mithilfe von Stages wird definiert, wann etwas in einer Pipeline ausgeführt werden soll. Stages können in der .gitlab-ci.yml-Datei vorab definiert werden. Hierzu fügen Sie am Anfang ihres Scripts die Punkt stages ein:

stages:
- build
- test
- deploy

Jobs[Bearbeiten | Quelltext bearbeiten]

In Jobs werden innerhalb der .gitlab-ci.yml-Datei definiert, was der GitLab Runner ausführen soll. Es können beliebig viele Jobs in einer Pipeline definiert werden, ein Job muss mindestens den Punkt script beinhalten.

Beispiel einer minimalen Konfiguration:

job1:
  script: "script-fuer-die-einrichtung"
	
job2:
  script: "script-fuer-die-tests"

Sie können die Jobs einzelnen Stages zuordnen, indem Sie diesen innerhalb des Jobs unter dem Punkt stages angeben:

stages:
- build
- test

job1:
  stage: build
  script: "script-fuer-die-einrichtung"
	
job2:
  stage: test
  script: "script-fuer-die-tests"

Weitere GitLab CI/CD Beispiele finden Sie unter CI/CD-Beispiele im GitLab Wiki.

Um den Status eines Jobs einzusehen gehen Sie in der linken Menüleiste auf den Punt CI/CD und wählen Sie eine Pipeline aus. In der Übersicht werden Ihnen nun die Stages der Pipeline und die jeweiligen Jobs angezeigt. Hinter jedem Job befindet sich ein Icon, welches den Status des Jobs anzeigt. Klicken Sie auf einen Job um, das Log einzusehen.

Variablen[Bearbeiten | Quelltext bearbeiten]

Falls Sie in ihrem Script Elemente haben, die Sie an mehreren Stellen verwenden, können Sie diesen in Variablen abspeichern, um Sie an diesen Stellen aufzurufen.

GitLab bietet eine Reihe an vordefinierten Variablen, die Sie in ihrem Script einsetzen können. Eine Liste dieser Variablen finden Sie unter Predefined Variables im GitLab Wiki.

Sie können aber auch selbst Variablen festlegen. Dazu können Sie innerhalb des Scripts den Punkt variables einfügen und darunter per Key: Value ihre Variablen festlegen.

variables:
  FINISHED: "Job wurde abgeschlossen"

job1:
  script: 
    - "script-fuer-die-einrichtung"
    - echo $FINISHED
	
job2:
  script: 
    - "script-fuer-die-tests"
    - echo $FINISHED

Eine andere Möglichkeit bietet GitLab in der Weboberfläche, um Passwörter und Zugangsdaten abzuspeichern. Sie können unter Settings > CI/CD' > Variables Variablen festlegen, welche Sie in ihrem Script aufrufen können. Die Werte dieser Variablen tauchen in ihrem Script dann nicht in Klartext auf sind so geschützt.

Environments & Deployment[Bearbeiten | Quelltext bearbeiten]

Ein Environment beschreibt in GitLab CI/CD wohin Code deployed wird (z.B. development, testing, staging, production). Sie können ein Environment unter dem Punkt Operations > Environments > New environment anlegen. Tragen hierzu den Namen und die URL des Servers ein. Eine weitere Möglichkeit ist es in der gitlab-ci.yml-Datei innerhalb eines Jobs den Punkt environment einzufügen und hier den Namen und die URL des Servers anzugeben:

stages:
- build
- test
- deploy

job1:
  stage: build
  script: "script-fuer-die-einrichtung"
  environment:
    name: development
	url: https://dev.beispiel.com
	
job2:
  stage: test
  script: "script-fuer-die-tests"
  environment:
    name: testing
	url: https://test.beispiel.com
  
job3:
  stage: deploy
  script: "deploy-script"
  environment:
    name: production
	url: https://deploy.beispiel.com

Weitere Informationen zu diesem Thema finden Sie im GitLab Wiki unter Environments.

Runner[Bearbeiten | Quelltext bearbeiten]

Ein Runner ist erforderlich, um die Jobs einer GitLab CI/CD Pipeline auszuführen. Um einen GitLab Runner zu installieren gibt es folgende Möglichkeiten:

als Container
deb/rpm-Pakete
manueller Download der Binaries

Folgende Betriebssysteme werden offiziell unterstützt:

CentOS
Debian
Ubuntu
RHEL
Fedora
Mint
Windows
macOS
FreeBSD

Für eine genaue Installationsanleitung verweisen wir an dieser Stelle an das GitLab Runner Wiki, da dies hier zu weit führen würde.

An dieser Stelle würden wir gerne auf den Cloudcomputing Dienst des ZIM verweisen. Dort können Sie ihre GitLab Runner einrichten und ausführen.

Nachdem ein Gitlab Runner installiert wurde muss dieser registriert werden. Dazu gehen Sie in der GitLab Weboberfläche auf der linken Seite auf Settings > CI/CD, dort finden Sie unter dem Punkt Runners die Register URL und den Registrierungs-Token für den Runner. Diese tragen Sie in ihrem GitLab Runner ein, wenn Sie den Befehl gitlab-runner register ausführen.

Bei der Registrierung eines Runners müssen Sie auch den Executer des Runners angeben. Zur Auswahl stehen hier:

SSH
Shell
Parallels
VirtualBox
Docker
Docker Machine (auto-scaling)
Kubernetes

Welchen Executer Sie auswählen hängt von der Art Ihres Projekts, der Umgebung und weiterer Faktoren ab. Eine Entscheidungshilfe bietet das GitLab Runner Wiki unter Selecting the executer.

Weitere Informationen zur Registrierung eines Runners finden Sie im GitLab Runner Wiki unter GitLab Runner.

Ist der Runner erfolgreich registriert, wird dieser unter Settings > CI/CD > Runners angezeigt und mit einem grünen Icon als laufend gekennzeichnet.

Cache und Artifacts[Bearbeiten | Quelltext bearbeiten]

GitLab CI/CD bietet die Möglichkeit die Laufzeit einzelner Jobs zu verkürzen, indem Abhängigkeiten und Build-Artifacts zwischengespeichert werden können.

Cache: Um Abhängigkeiten des Projekts zwischen zu speichern
- Der Cache kann die Laufzeit von Jobs verkürzen, indem er heruntergeladene Abhängigkeiten zwischen speichert und diese bei Bedarf wieder bereitstellt, so dass diese nicht erneut herunter geladen werden müssen.

Artifacts: Um Resultate einer Stage weiterzureichen
- Artifacts sind Dateien, die während eines Jobs erzeugt werden. Sie können zwischen den Stages weitergereicht werden und später über die Weboberfläche heruntergeladen werden. Die Artifacts sind nicht außerhalb einer Pipeline verfügbar und können auch nicht innerhalb von Jobs weitergereicht werden.

Um zum Beispiel die Abhängigkeiten eines Python Projektes zu cachen geben Sie diese in der gitlab-ci.yml-Datei unter cache: an:

cache:
  paths:
    - .cache/pip
	- venv

Weitere Beispiele finden Sie im GitLab Wiki unter Common Use Cases

Um Artifacts in ihrem Projekt zu definieren, tragen Sie diese unter dem Punkt artifacts: in ihrem Script ein.

artifacts:
  paths:
    - /output/meineAnwendung.exe
  expire_in: 1 week

Mit dem Keyword expire_in geben Sie an, wie lange GitLab die Artifacts speichern soll. Bitte beachten Sie die folgenden Beschränkungen.

Wichtige Links[Bearbeiten | Quelltext bearbeiten]

https://git.uni-paderborn.de
https://git.uni-paderborn.de/help

Bei Fragen oder Problemen wenden Sie sich bitte telefonisch oder per E-Mail an uns:

Tel. IT: +49 (5251) 60-5544 • Tel. Medien: +49 (5251) 60-2821 • E-Mail: zim@uni-paderborn.de

Das Notebook-Café ist die Benutzerberatung des ZIM - Sie finden uns in Raum I0.401

Wir sind zu folgenden Zeiten erreichbar:

	Mo-Do	Fr
Vor-Ort-Support	08:30 - 16:00	08:30 - 14:00
Telefonsupport	08:30 - 16:00	08:30 - 14:00

Das ZIM:Servicecenter Medien auf H1 hat aktuell zu folgenden Zeiten geöffnet:

Mo-Do	Fr
08:00 - 16:00	08:00 - 14:30

@@ Zeile 151: / Zeile 151: @@
 Für eine genaue Installationsanleitung verweisen wir an dieser Stelle an das [https://docs.gitlab.com/runner/install/ GitLab Runner Wiki], da dies hier zu weit führen würde.
 <br>
-<bootstrap_alert color=info>An dieser Stelle würden wir gerne auf den [https://hilfe.uni-paderborn.de/Cloudcomputing Cloudcomputing] Dienst des IMT verweisen. Dort können Sie ihre GitLab Runner einrichten und ausführen.
+<bootstrap_alert color=info>An dieser Stelle würden wir gerne auf den [https://hilfe.uni-paderborn.de/Cloudcomputing Cloudcomputing] Dienst des ZIM verweisen. Dort können Sie ihre GitLab Runner einrichten und ausführen.
 </bootstrap_alert>