GitLab - Wie arbeite ich mit GitLab: Unterschied zwischen den Versionen

ZIM HilfeWiki - das Wiki
Zeile 10: Zeile 10:
 
{{Draft}}
 
{{Draft}}
 
Bei GitLab handelt es sich um ein Online-Repository für Programmier-Projekte, ähnlich wie der Online-Dienst GitHub. Der wichtigste Unterschied ist aber, dass man Projekte nicht öffentlich machen muss. Der Code bleibt also in der Uni und kann ausschließlich mit gewünschten Personen gemeinsam bearbeitet werden. Darüberhinaus bietet GitLab einen Online-Codeeditor an.
 
Bei GitLab handelt es sich um ein Online-Repository für Programmier-Projekte, ähnlich wie der Online-Dienst GitHub. Der wichtigste Unterschied ist aber, dass man Projekte nicht öffentlich machen muss. Der Code bleibt also in der Uni und kann ausschließlich mit gewünschten Personen gemeinsam bearbeitet werden. Darüberhinaus bietet GitLab einen Online-Codeeditor an.
 +
 +
<bootstrap_alert color=info>Dieses Wiki bezieht sich auf den GitLab Dienst des IMT. Studierende und Mitarbeiter aus den Bereichen Elektrotechnik, Informatik und Mathematik verwendet bitte den [https://cs.uni-paderborn.de/rechnerbetrieb-irb/dienste/git GitLab Dienst] des [https://cs.uni-paderborn.de/rechnerbetrieb-irb Informatik Rechnerbetriebs]. Über den IRB erhalten Sie auch Support für ihre Anfragen.
 +
</bootstrap_alert>
  
 
==Die wichtigsten Rahmendaten==
 
==Die wichtigsten Rahmendaten==
Zeile 150: Zeile 153:
 
Hier können Sie aus den Vorlagen eine Lizenz auswählen oder selbst eine Lizenz einfügen. Klicken Sie anschließend auf ''Commit changes'' um die Lizenz dem Projekt hinzuzufügen.
 
Hier können Sie aus den Vorlagen eine Lizenz auswählen oder selbst eine Lizenz einfügen. Klicken Sie anschließend auf ''Commit changes'' um die Lizenz dem Projekt hinzuzufügen.
 
[[Datei:Screenshot_GitLab_Add_license_02.png|600px|thumb|none|Lizenz Vorlagen]]
 
[[Datei:Screenshot_GitLab_Add_license_02.png|600px|thumb|none|Lizenz Vorlagen]]
 +
 +
==GitLab CI/CD==
 +
Mit GitLab CI/CD bietet GitLab bei der Softwareentwicklung Module für:
 +
*Continuous Integration (CI)
 +
*Continuous Delivery (CD)
 +
*Continuous Deployment (CD)
 +
<br>
 +
bereit. Weitere Informationen über dieses Konzept finden Sie im [https://docs.gitlab.com/ee/ci/introduction/ GitLab Wiki].
 +
 +
===GitLab CI/CD einrichten===
 +
GitLab CI/CD wird über die Datei <code>.gitlab-ci.yml</code> 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===
 +
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.
 +
<br>
 +
[[Datei:Screenshot_GitLab_CI_CD_Pipeline.png|none|GitLab CI/CD Pipeline]]
 +
 +
 +
'''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===
 +
Mithilfe von Stages wird definiert, wann etwas in einer Pipeline ausgeführt werden soll. Stages können in der <code>.gitlab-ci.yml</code>-Datei vorab definiert werden. Hierzu fügen Sie am Anfang ihres Scripts die Punkt <code>stages</code> ein:
 +
<source>
 +
stages:
 +
- build
 +
- test
 +
- deploy
 +
</source>
 +
 +
===Jobs===
 +
In Jobs werden innerhalb der <code>.gitlab-ci.yml</code>-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 <code>script</code> beinhalten.
 +
 +
Beispiel einer minimalen Konfiguration:
 +
<source>
 +
job1:
 +
  script: "script-fuer-die-einrichtung"
 +
 +
job2:
 +
  script: "script-fuer-die-tests"
 +
</source>
 +
 +
Sie können die Jobs einzelnen Stages zuordnen, indem Sie diesen innerhalb des Jobs unter dem Punkt <code>stages</code> angeben:
 +
<source>
 +
stages:
 +
- build
 +
- test
 +
 +
job1:
 +
  stage: build
 +
  script: "script-fuer-die-einrichtung"
 +
 +
job2:
 +
  stage: test
 +
  script: "script-fuer-die-tests"
 +
</source>
 +
 +
Weitere GitLab CI/CD Beispiele finden Sie unter [https://docs.gitlab.com/ee/ci/examples/README.html 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===
 +
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 [https://docs.gitlab.com/ee/ci/variables/predefined_variables.html Predefined Variables] im GitLab Wiki.
 +
 +
Sie können aber auch selbst Variablen festlegen. Dazu können Sie innerhalb des Scripts den Punkt <code>variables</code> einfügen und darunter per ''Key: Value'' ihre Variablen festlegen.
 +
 +
<source>
 +
variables:
 +
  FINISHED: "Job wurde abgeschlossen"
 +
 +
job1:
 +
  script:
 +
    - "script-fuer-die-einrichtung"
 +
    - echo $FINISHED
 +
 +
job2:
 +
  script:
 +
    - "script-fuer-die-tests"
 +
    - echo $FINISHED
 +
</source>
 +
 +
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===
 +
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 <code>gitlab-ci.yml</code>-Datei innerhalb eines Jobs den Punkt <code>environment</code> einzufügen und hier den Namen und die URL des Servers anzugeben:
 +
 +
<source>
 +
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
 +
</source>
 +
 +
Weitere Informationen zu diesem Thema finden Sie im GitLab Wiki unter [https://docs.gitlab.com/ee/ci/environments/ Environments].
 +
 +
===Runner===
 +
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
 +
<br>
 +
Folgende Betriebssysteme werden offiziell unterstützt:
 +
*CentOS
 +
*Debian
 +
*Ubuntu
 +
*RHEL
 +
*Fedora
 +
*Mint
 +
*Windows
 +
*macOS
 +
*FreeBSD
 +
<br>
 +
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>
 +
 +
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 <code>gitlab-runner register</code> 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
 +
<br>
 +
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  [https://docs.gitlab.com/runner/executors/README.html#selecting-the-executor Selecting the executer].
 +
 +
Weitere Informationen zur Registrierung eines Runners finden Sie im GitLab Runner Wiki unter [https://docs.gitlab.com/runner/register/ 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===
 +
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 <code>gitlab-ci.yml</code>-Datei unter <code>cache:</code> an:
 +
 +
<source>
 +
cache:
 +
  paths:
 +
    - .cache/pip
 +
- venv
 +
</source>
 +
 +
Weitere Beispiele finden Sie im GitLab Wiki unter [https://docs.gitlab.com/ee/ci/caching/#common-use-cases Common Use Cases]
 +
 +
Um Artifacts in ihrem Projekt zu definieren, tragen Sie diese unter dem Punkt <code>artifacts:</code> in ihrem Script ein.
 +
 +
<source>
 +
artifacts:
 +
  paths:
 +
    - /output/meineAnwendung.exe
 +
  expire_in: 1 week
 +
</source>
 +
 +
Mit dem Keyword <code>expire_in</code> geben Sie an, wie lange GitLab die Artifacts speichern soll. Bitte beachten Sie die folgenden Beschränkungen.
  
 
==Beschränkungen==
 
==Beschränkungen==

Version vom 27. April 2021, 12:40 Uhr

Allgemeine Informationen
Information
Informationen
BetriebssystemAlle
ServiceVerschiedenes
Interessant fürAngestellte, Studierende und Gäste
HilfeWiki des ZIM der Uni Paderborn

no displaytitle found: GitLab - Wie arbeite ich mit GitLab

Bei GitLab handelt es sich um ein Online-Repository für Programmier-Projekte, ähnlich wie der Online-Dienst GitHub. Der wichtigste Unterschied ist aber, dass man Projekte nicht öffentlich machen muss. Der Code bleibt also in der Uni und kann ausschließlich mit gewünschten Personen gemeinsam bearbeitet werden. Darüberhinaus bietet GitLab einen Online-Codeeditor an.

Die wichtigsten Rahmendaten[Bearbeiten | Quelltext bearbeiten]

Wer kann den Dienst nutzen?[Bearbeiten | Quelltext bearbeiten]

Jeder mit einem gültigen IMT-Account.

Wie kann ich den Dienst nutzen[Bearbeiten | Quelltext bearbeiten]

Um GitLab verwenden zu können müssen Sie zunächst den Dienst im SP beantragen. Dieser wird automatisch genehmigt. Um den Dienst anschließend aufzurufen gehen Sie auf https://git.uni-paderborn.de.

Wie arbeite ich mit GitLab[Bearbeiten | Quelltext bearbeiten]

Wie lege ich ein neues GitLab Repository an[Bearbeiten | Quelltext bearbeiten]

Screenshot GitLab Create new project 01.png

Klicken Sie in der oberen Menüleiste auf New ("+" Icon neben dem Suchfeld) und dann auf New project. Es stehen ihnen vier Möglichkeiten zur Auswahl:

  • Create blank project
Neues Repository ohne Inhalt
  • Create from template
Neues Repository anhand einer Vorlage erstellen
  • Import project
Ein bereits bestehendes Repository (auf Github o.ä) klonen
  • Run CI/CD for external repository
Ein externes Repository mit GitLab CI/CD verbinden

Wählen sie den Punkt Create blank project aus.

Dialogfeld neues Projekt

Unter Project name können sie den Namen des Repositories angeben. Unter dem Punkt Visibility Level können Sie auswählen für wen das neue Repository sichtbar ist:

  • Private
Nur Sie und die Benutzer denen Sie Zugriff auf das Repository gewähren können es sehen
  • Internal
Das Repository kann von allen angemeldeten Benutzer gesehen und auch geklont werden
  • Public
Das Repository ist öffentlich und kann von jedem gesehen und geklont werden (auch außerhalb der Uni)

Als letzten Punkt haben Sie die Möglichkeit, das Repository automatisch mit einer Readme-Datei zu versehen. Diese wird in Markdown geschrieben und Dient der Projektbeschreibung (wie auf Github). Alternativ kann die Datei auch manuell erstellt werden.

Anschließend klicken Sie auf Create project. Sie werden automatisch auf die Startseite des Projektes weitergeleitet.

Eine neue Datei in einem GitLab Repository anlegen[Bearbeiten | Quelltext bearbeiten]

Screenshot GitLab Create New file.png

Um eine neue Datei über das Webinterface in ihrem Repository anzulegen, klicken Sie auf den "+" Button neben dem Namen des Repositories und wählen den Punkt New file aus. Es öffnet sich ein Dialogfenster, hier können Sie den Dateinamen vergeben und rechts neben dem Namenfeld eine Vorlage auswählen. Tragen Sie eine Commit message ein und wählen Sie aus in welcher Branch die Datei erzeugt werden soll. Klicken Sie zum Erstellen auf Commit changes.

Daten zu einem GitLab Repository hinzufügen[Bearbeiten | Quelltext bearbeiten]

Um Daten über das Webinterface einzufügen gehen Sie wie folgt vor:

  1. In dem Repository klicken Sie auf den "+" Button
  2. Wählen Sie Upload file aus
  3. Im Upload Dialog können Sie per drag and drop oder mit click to upload Dateien hochladen
  4. Tragen Sie eine Commit message ein und wählen Sie eine branch aus, in der die Dateien hochgeladen werden sollen
  5. Klicken Sie anschließend auf Upload file

Ordner zu einem GitLab Repository hinzufügen[Bearbeiten | Quelltext bearbeiten]

Um einen Ordner über das Webinterface zum Repository hinzuzufügen gehen sie folgendermaßen vor:

  1. In dem Repository klicken Sie auf den "+" Button
  2. Wählen Sie New directory aus
  3. Im Dialogfenster vergeben Sie einen Namen, die Commit message und wählen aus zu welcher Branch der Ordner hinzugefügt werden soll
  4. Klicken Sie zum Erstellen auf Create directory

Wie lege ich eine neue Gruppe in GitLab an[Bearbeiten | Quelltext bearbeiten]

Screenshot GitLab Create new group 01.png

Klicken Sie in der oberen Menüleiste auf New ("+" Icon neben dem Suchfeld) und dann auf New group.

Unter Group name können Sie einen Gruppennamen vergeben. Anschließend legen Sie die Sichtbarkeit der Gruppe fest:

  • Private
Nur Sie und die Mitglieder der Gruppe können diese sehen
  • Internal
Angemeldete Benutzer können die Gruppe sehen
  • Public
Die Gruppe kann von jedem gesehen werden (auch außerhalb der Uni)

Anschließend können Sie die Mail-Adressen der Mitglieder, die Sie in die Gruppe einladen möchten eintragen. Klicken Sie zum Erstellen auf Create group.

Benutzer/Gruppen zu einem GitLab Repository hinzufügen[Bearbeiten | Quelltext bearbeiten]

Wählen Sie in ihrem Repository in der linken Menüleiste Members aus. Um eine Person zum Repository hinzuzufügen wählen Sie den Punkt Invite Member' und geben Sie den Namen oder die Mail-Adresse der Person ein. Wählen Sie welche Position die Person in der Gruppe erhalten soll. Eine Übersicht der Berechtigungen der verschiedenen Positionen erhalten Sie hier. Unter dem Punkt Access expiration date können Sie festlegen wie lange die Person Zugriff auf das Projekt hat. Anschließend klicken Sie auf Import, falls die Personen bereits bei GitLab registriert sind. Andernfalls auf Invite um Sie zur Teilnahme am Repository einzuladen.

Um eine Gruppe zum Repository hinzuzufügen wählen Sie den Punkt Invite group und geben Sie den Namen der Gruppe ein. Mit Max access level legen Sie die höchste Berechtigungsstufe für Mitglieder der Gruppe fest. Wählen Sie z.B. 'Developer' können Mitglieder der Gruppe die 'Engineer' oder 'Maintainer' sind nur mit den Berechtigungen des 'Developer' auf das Projekt zugreifen. Unter dem Punkt Access expiration date können Sie festlegen wie lange die Gruppe Zugriff auf das Projekt hat.

Klicken Sie Invite um die Gruppe dem Projekt hinzuzufügen.

Eine neue Branch anlegen[Bearbeiten | Quelltext bearbeiten]

Um neue Features zu entwicklen oder zur Behebung eines Fehlers werden üblicherweise Feature Branches verwendet. Es wird eine Kopie der aktuellen Master Branch erstellt in der die Entwicklung weitergeführt wird. Das soll verhindern, dass mehrere Entwickler an einer Codebasis arbeiten und dadurch Fehler entstehen. Um eine solche Branch zu erstellen klicken Sie in Ihrem Repository auf den "+" Button und wählen den Punkt New branch aus. Vergeben Sie im Feld Branch Name einen Namen für die neue Branch und wählen Sie unter Create from die Quelle der neuen Branch aus. Klicken Sie auf Create branch um die neue Branch anzulegen.

Labels erzeugen[Bearbeiten | Quelltext bearbeiten]

Bevor Sie das erste Issue erstellen werden üblicherweise zuerst Labels anlegt um diese zu kategorisieren. Um neue Labels zu erzeugen klicken Sie in der linken Menüleiste Auf Issues und dann auf Labels. Hier haben Sie die Möglichkeit über New label selbst ein neues Label anzulegen oder mit Generate a default set of labels einen Standard Label-Satz zu erzeugen.

Issues anlegen[Bearbeiten | Quelltext bearbeiten]

Issues werden angelegt um auf einen Fehler im Programmcode oder der Dokumentation hinzuweisen, sowie ein neues Feature vorzuschlagen. Um ein neues Issue anzulegen klicken Sie in der linken Menüleiste auf Issues und dann auf New issue. Zunächst wird dem Issue ein Titel gegeben. Hierbei ist zu beachten einen Titel zu vergeben, der das Anliegen kurz und prägnant beschreibt:

  • schlechter Titel
    • Bug gefunden
    • Problem beheben
  • guter Titel
    • Anmeldung mit 12 stelligen Passwort nicht möglich
    • Absturz beim Öffnen der Datei XYZ im Dialog ABC


Bei dem Punkt Type können Sie auswählen, ob es sich um ein Issue oder einen Incident (einen Absturz o.ä.) handelt. Wählen Sie entsprechend aus. Geben Sie im Description Feld eine Beschreibung des Issues, evtl. schon mit einem Lösungsvorschlag. Zur Formatierung und Strukturierung steht ihnen die Auszeichnungssprache Markdown zur Verfügung. Mit der Checkbox unter dem Textfeld können wählen, ob ein Issue Vertraulich behandelt werden soll und nur von Teilnehmern mit mindestens Reporter Zugriff gesehen werden soll.

Mit den weiteren Punkten können Sie:

  • Assignees
Das neue Issue bestimmten Nutzern zuweisen.
  • Milestone
Einen Meilenstein auswählen, welcher die Lösung des Issues voraussetzt
  • Labels
Label werden vergeben um Issues zu Kategorisieren und zu Priorisieren
  • Weight
Bestimmt wie aufwändig das Issues zu beheben ist
  • Due date
Legt einen Termin fest bis zu dem das Issue behoben sein soll

Um das Issue einzureichen klicken Sie auf Submit issue.

Issues verwalten[Bearbeiten | Quelltext bearbeiten]

Um alle aktiven Issues einzusehen klicken Sie auf in der linken Menüleiste auf Issues. Hier finden Sie eine Auflistung aller aktiven Issues. Um abgeschlossene Issues einzusehen klicken Sie auf Closed in der oberen Menüleiste.

Merge Requests[Bearbeiten | Quelltext bearbeiten]

Wurde eine neue Branch erstellt und diese soll nun wieder in die Master Branch einfließen, erstellt man hierfür einen Merge Request. Dies kann direkt aus einem Issue heraus erfolgen oder manuell über den Punkt Merge requests und dann auf New merge request. Um aus einem Issue heraus einen Merge request zu erstellen öffnen Sie die Übersichtsseite des Issues und klicken auf Create merge request. Der Merge request ist nun erstellt. Damit dieser in die Master Branch einfließen kann muss er als Fertig markiert werden - dies können Sie mit dem Button oben rechts im Fenster Mark as ready machen.

Mark as ready

Nun können Sie über den grünen Merge Button den Code in den Master Branch einfließen lassen und der Feature Branch wird geschlossen.

Merge

Lizenz hinzufügen[Bearbeiten | Quelltext bearbeiten]

Klicken Sie auf der Übersichtsseite des Projektes auf Add LICENSE.

Lizenz hinzufügen

Hier können Sie aus den Vorlagen eine Lizenz auswählen oder selbst eine Lizenz einfügen. Klicken Sie anschließend auf Commit changes um die Lizenz dem Projekt hinzuzufügen.

Lizenz Vorlagen

GitLab CI/CD[Bearbeiten | Quelltext bearbeiten]

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.

GitLab CI/CD Pipeline


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.

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.

Beschränkungen[Bearbeiten | Quelltext bearbeiten]

Für artifacts gilt eine Quota von 1 GB, dafür werden sie allerdings nach 30 Tagen automatisch abgeräumt.

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 Di - Fr
Vor-Ort-Support Geschlossen Über die Feiertage geschlossen
Telefonsupport 08:30 - 13:00 Über die Feiertage geschlossen


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

Mo Di - Fr
08:00 - 16:00 Über die Feiertage geschlossen


Abgerufen von „https://hilfe.uni-paderborn.de/index.php?title=GitLab_-_Wie_arbeite_ich_mit_GitLab&oldid=22335“
Cookies helfen uns bei der Bereitstellung des ZIM HilfeWikis. Bei der Nutzung vom ZIM HilfeWiki werden die in der Datenschutzerklärung beschriebenen Cookies gespeichert.
Weitere Informationen