Skip to Content

Wiki source code of GitLab Erklärungen

Version 143.2 by Marco Grawunder on 2025/10/22 15:22
Hide last authors
Marco Grawunder 84.1 1 [[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]]
2
Pascal Meyer 12.1 3 {{toc/}}
4
Marco Grawunder 143.1 5 (% class="box infomessage" %)
6 (((
Marco Grawunder 142.1 7 Falls man bei Gitlab nicht rechtzeitig ein Passwort vergeben hat oder das Passwort vergessen hat: [[https:~~/~~/gitlab.swl.informatik.uni-oldenburg.de/users/password/new>>https://gitlab.swl.informatik.uni-oldenburg.de/users/password/new]] Die hinterlegte E-Mail-Adresse ist die Uni-Mail-Adresse, die auch im Stud.IP hinterlegt ist.
Marco Grawunder 143.1 8 )))
Marco Grawunder 141.2 9
Pascal Meyer 4.2 10 Ab dem Wintersemester 2025/2026 wird die Projektstrukturierung und der [[Scrum>>doc:Main.Scrum.WebHome]]-Prozess in GitLab durchgeführt. Für die wichtigsten, grundlegendsten Funktion gibt es nachfolgend als Einstiegshilfe einige Erklärungen.
Pascal Meyer 1.3 11
12 = Issue/Task-Erstellung in GitLab =
13
Pascal Meyer 6.2 14 Für die Erstellung von Issues (User-Stories) oder Tasks (Aufgaben) wird in der Projektnavigationsleiste der Reiter** "Issues" **angeklickt und nachfolgend die Option **"New issue"** ausgewählt.
Pascal Meyer 4.2 15
Pascal Meyer 34.1 16 [[image:Issue1.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 4.2 17
Pascal Meyer 5.2 18 Anschließend öffnet sich ein neues Fenster mit vielen Option. Hierbei kann ein Typ, ein Titel, eine Beschreibung und viele weitere unterschiedlichen Funktionen festgelegt werden.
Pascal Meyer 4.2 19
Pascal Meyer 6.1 20 Als **"Type" **stehen drei Optionen zur Auswahl:
Pascal Meyer 5.2 21
Pascal Meyer 6.1 22 * "Incident" - Ein Zwischenfall/Störung
23 * "Issue" - Im SWP eine User-Story (siehe [[User-Stories>>doc:Main.Scrum.WebHome||anchor="HUserStories"]])
Pascal Meyer 6.2 24 * "Task" - Eine Aufgabe
Pascal Meyer 5.2 25
Pascal Meyer 7.1 26 Im unten gezeigtem Beispiel wird ein Issue gewählt und mit einem Titel (Name der User-Story) und einer Beschreibung (Akzeptanzkriterien) versehen.
Pascal Meyer 6.1 27
Pascal Meyer 8.2 28 Zusätzlich ist es möglich den Status (bspw. "To do", "Done", "In progress" etc), den Bearbeiter (ein oder mehrere Gruppenmitglieder), ein oder mehrere Labels, einen Meilenstein (siehe: ), Schätzungen und viele weitere Funktionen einzustellen. Anschließend werden die Angaben mit dem **"Create issue"** Button bestätigt.
Pascal Meyer 6.1 29
Pascal Meyer 34.1 30 [[image:Issue2.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 11.1 31
32 Es besteht im Anschluss direkt die Option sogenannte **"Child items"** hinzuzufügen. Dies ist besonders sinnvoll wenn die User-Story relativ umfangreich ist und somit besser in kleinere Arbeitspakete (bzw. Aufgaben) zerteilt werden sollte. Hierfür wird der **"Add"**-Button und entweder **"New task"** oder **"Existing task"** ausgewählt. Somit können entweder neue Aufgaben formuliert (wie im kommenden Beispiel) oder bestehende hinzugefügt werden.
Pascal Meyer 7.2 33
Pascal Meyer 34.1 34 [[image:Issue3.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 7.2 35
Pascal Meyer 11.1 36 Hier wurde als Aufgabe das Feld für die Eingabe definiert. Anschließend wurde die Eingabe mit **"Create task"** bestätigt.
37
Pascal Meyer 33.6 38 [[image:Issue4.png||data-xwiki-image-style-border="true"]]
39
Pascal Meyer 11.1 40 Nachdem alle Informationen eingepflegt und ausführlich beschrieben wurden, ist das Issue vorerst fertig.
41
Pascal Meyer 33.6 42 [[image:Issue5.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 13.2 43
Pascal Meyer 52.5 44 == Status bei Issues ==
45
Pascal Meyer 52.6 46 In GitLab werden standardmäßig fünf verschiedene Statusformen angeboten. Diese Optionen sind:
Pascal Meyer 52.5 47
Pascal Meyer 52.6 48 * **To do** (wird bei der Issue Erstellung standardmäßig ausgewählt)
49 * **In progress**
50 * **Done**
51 * **Won't do**
52 * **Duplicate**
53
54 Diese Statusformen werden genutzt um eine Sortierung und/oder Priorisierung der Issues zu ermöglichen. Zusätzlich dienen diese aber auch als Orientierung für das gesamte Projektteam. Somit weiß jedes Gruppenmitglied was erledigt ist und was noch erledigt werden muss.
55
Pascal Meyer 53.2 56 [[image:Issue Status 1.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 52.6 57
Pascal Meyer 56.1 58 Zur Status Änderung wird einfach die **"Edit"**-Option betätigt und anschließend öffnet sich ein Optionsmenü. Die gewünschte Option muss nur noch bestätigt werden und der neue Status wird festgelegt.
Pascal Meyer 52.6 59
Pascal Meyer 55.2 60 [[image:Issue Status 2.png||data-xwiki-image-style-border="true"]]
61
62 [[image:Issue Status 3.png||data-xwiki-image-style-border="true"]]
63
Pascal Meyer 56.2 64 == Meilensteine und Epics ==
65
Pascal Meyer 116.3 66 Im Laufe des Softwareprojektes werden eine Menge an Issues erstellt. Damit der Überblick über die Vielzahl an Issues nicht verloren geht und somit der Projektfortschritt nicht potenziell gefährdet wird, werden im Softwareprojekt mit Meilensteinen (siehe [[Meilensteine>>doc:Main.Anforderungen Software.WebHome||anchor="HAnforderungen:DievordefiniertenMeilensteine"]]) und Epics gearbeitet. In GitLab werden die Meilensteine mit der Funktion "**Milestones**" und die Labels mit der Funktion **"Labels"** umgesetzt. Diese Option ist im Reiter "Manage" und anschließend unter "Labels" vorzufinden.
Pascal Meyer 56.2 67
Pascal Meyer 110.3 68 === Meilensteine ===
69
Pascal Meyer 115.1 70 Um einen neuen Meilenstein zu erstellen, wird in der Projektnavigationsleiste der Reiter** "Milestones" **angeklickt und nachfolgend die Option **"New milestone"** ausgewählt.
Pascal Meyer 114.2 71
Pascal Meyer 113.2 72 [[image:Meilenstein1.1.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 110.3 73
Pascal Meyer 115.1 74 Nach der Erstellung wird der Meilenstein mit einem Titel, einem Start- sowie Enddatum und einer Beschreibung versehen. In der Beschreibung müssen die umzusetzenden Funktionen aufgelistet werden (Ziel des Meilensteins). Bestätigt wird die Erstellung mit der "**Create milestone**"-Funktion.
75
Pascal Meyer 113.2 76 [[image:Meilenstein2.png||data-xwiki-image-style-border="true"]]
77
Pascal Meyer 114.2 78 [[image:Meilenstein3.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 113.2 79
Pascal Meyer 128.2 80 Dem frisch erstellten Meilensteinen können jetzt Issues zugewiesen werden. Dies funktioniert trivial zu der Statusvergabe.
Pascal Meyer 127.3 81
Pascal Meyer 129.2 82 [[image:Meilenstein4.1.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 127.4 83
Pascal Meyer 115.1 84 === Epics ===
85
Pascal Meyer 116.4 86 Um ein neues Epic zu erstellen, wird in der Projektnavigationsleiste der Reiter** "Labels" **angeklickt und nachfolgend die Option **"New Label"** ausgewählt.
Pascal Meyer 115.1 87
Pascal Meyer 58.2 88 [[image:Label 1.png||data-xwiki-image-style-border="true"]]
89
Pascal Meyer 116.5 90 Das neue Epic wird mit einem Titel, einer Beschreibung und einer Farbe versehen. Bestätigt wird die Erstellung mit der "**Create label**"-Funktion.
Pascal Meyer 60.2 91
Pascal Meyer 63.2 92 [[image:Epic2.png||data-xwiki-image-style-border="true"]]
93
Pascal Meyer 116.2 94 [[image:Label1.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 63.2 95
Pascal Meyer 116.6 96 Bei der Issue-Erstellung/Bearbeitung können die erstellten Labels/Meilensteine jetzt mit den neuen/bestehenden Issues verknüpft werden. Dies erfolgt trivial zur Status-Option.
Pascal Meyer 63.2 97
Pascal Meyer 68.1 98 [[image:Issue Label 2.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 63.3 99
Pascal Meyer 118.2 100 [[image:Labelissue1.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 68.1 101
Pascal Meyer 118.2 102 [[image:Label2.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 68.1 103
sbeyer1 94.1 104 ----
105
Pascal Meyer 13.2 106 = Product-Backlog =
107
Pascal Meyer 33.6 108 Die erstellten Issues werden automatisch nach der Erstellung dem Product-Backlog (siehe [[Product-Backlog>>doc:Main.Scrum.WebHome||anchor="HProductBacklog"]]) hinzugefügt. Der Product-Backlog ist eine Liste mit allen erstellten und unbearbeiteten Issues. Dieser ist im GitLab unter dem Reiter **"Issue boards" **vorzufinden.
Pascal Meyer 17.1 109
Pascal Meyer 33.6 110 [[image:ProductBacklog1.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 17.1 111
Pascal Meyer 122.2 112 [[image:IssueList1.1.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 33.6 113
Pascal Meyer 68.2 114 == Pflege/Priorisierung des Product-Backlogs ==
115
Pascal Meyer 124.1 116 Die Pflege des Product-Backlogs (siehe [[Pflege>>doc:Main.Scrum.WebHome||anchor="HDerNutzeneinesgepflegten2FpriorisiertenProductBacklogs"]]) ist in GitLab sehr einfach durchzuführen. Hierfür werden die Issues einfach per "Drag and Drop" (Ziehen und Ablegen) in die gewünschte Ordnung bzw. Priorisierung gebracht. Im ersten Beispiel war die Reihenfolge der Issues #8,#4,#9,#7,#1,#3, #5, #6 und für das Projekt unsortiert. Nach der Sortierung ist die Reihenfolge der Issues #9,#8,#7,#6,#5,#4, #3, #1 (Sortierung willkürlich gewählt und dient nur zu Anschauungszwecke).
Pascal Meyer 17.1 117
Pascal Meyer 124.1 118 [[image:IssueList1.2.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 17.1 119
Pascal Meyer 70.2 120 == Erstellung neuer Listen ==
121
Pascal Meyer 78.2 122 In GitLab können die Listen auch genutzt werden um beispielsweise Meilensteine oder Epics darzustellen (siehe [[Meilensteine und Epics>>doc:Main.GitLab.WebHome||anchor="HMeilensteineundEpics"]]). Auch der Status der Issues kann dargestellt werden (siehe [[Status>>doc:Main.GitLab.WebHome||anchor="HStatusbeiIssues"]]). Hierfür wird einfach die **"New list"**-Funktion genutzt.
Pascal Meyer 70.2 123
Pascal Meyer 125.1 124 [[image:IssueList2.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 78.2 125
Pascal Meyer 82.1 126 In der sich öffnenden Option wird jetzt der Status **"in progress**" ausgewählt und mit der **"Add to board"**-Funktion bestätigt.
Pascal Meyer 78.2 127
Pascal Meyer 125.1 128 [[image:IssueList3.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 78.2 129
Pascal Meyer 125.1 130 [[image:IssueList4.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 78.2 131
Pascal Meyer 127.2 132 Zusätzlich werden zur Veranschaulichung Listen für die Epic-Label und Meilensteine erstellt.
Pascal Meyer 78.2 133
Pascal Meyer 127.2 134 [[image:IssueList5.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 78.2 135
Pascal Meyer 127.2 136 [[image:IssueList6.png||data-xwiki-image-style-border="true"]]
137
Pascal Meyer 131.2 138 [[image:MeilensteinList1.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 127.2 139
Pascal Meyer 131.2 140 [[image:MeilensteinList2.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 127.3 141
sbeyer1 94.1 142 ----
143
Pascal Meyer 18.3 144 = Erstellung eines Sprints =
Pascal Meyer 17.1 145
Pascal Meyer 104.2 146 In GitLab erfolgt die Erstellung eines Sprints in sogenannten **"Iterationen"** (Wiederholungen). Diese Option ist in der Gruppennavigationsleiste unter dem Reiter **"Iteration" **vorzufinden. Um einen neuen Sprint zu erstellen wird die **"New iteration cadence"**-Option ausgewählt.
Pascal Meyer 18.2 147
Pascal Meyer 104.2 148 [[image:Iteration1.png||data-xwiki-image-style-border="true"]]
Marco Grawunder 101.3 149
Pascal Meyer 108.2 150 Damit ein neuer Sprint erstellt werden kann, wird der Sprint mit einem Titel und einer optionalen Beschreibung versehen. Das Start- sowie Enddatum wird einmalig festgelegt. Anschließend wird die Dauer des Sprints in Wochen angegeben. Dieser Zeitraum ist für jeden weiteren Sprint fest. Desweiteren kann eingestellt werden, wie viele kommende Iterationen geplant werden können.  Die **"Roll over"** Funktion überträgt nicht fertiggestellte User Stories/Aufgaben automatisch in den nächsten Sprint. Mit der "**Create cadence"**-Funktion wird die Iteration und somit der Sprint erstellt.
Pascal Meyer 20.2 151
Pascal Meyer 108.2 152 [[image:Iteration2.1.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 20.2 153
Pascal Meyer 110.1 154 [[image:Iteration3.1.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 107.2 155
Pascal Meyer 69.2 156 == Sprint-Backlog ==
157
Pascal Meyer 24.2 158 Jetzt wurde erfolgreich ein Sprint erstellt. Jedoch fehlen bisher noch die Issues die benötigt werden um das Sprintziel zu erreichen. Dafür wird erneut der Reiter **"Issue boards" **(der Product-Backlog) angesteuert. Anschließend wird die Funktion **"New list"** ausgewählt.
Pascal Meyer 20.2 159
Pascal Meyer 132.2 160 [[image:IssueList2.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 20.3 161
Pascal Meyer 133.2 162 Hierbei werden wieder verschiedene Optionen angeboten. Für die Erstellung eines Sprints bzw. der Durchführung der Sprintplanung, wird die Option **"Iteration"** und der eben erstellte Sprint als **"Value"** ausgewählt. Anschließend wird der Vorgang durch die **"Add to board"**-Funktion bestätigt.
Pascal Meyer 22.1 163
Pascal Meyer 133.2 164 [[image:Sprintbacklog1.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 22.3 165
Pascal Meyer 135.2 166 [[image:Sprintbacklog3.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 133.3 167
Pascal Meyer 24.2 168
Pascal Meyer 27.5 169 Somit wurde erfolgreich ein sogenannter **Sprint-Backlog** (siehe [[Informationen zu Scrum>>doc:Main.Scrum.WebHome]]) erstellt. In der Sprint-Planungsphase wird vom kompletten Projektteam festgelegt, welche Issues im Sprint umgesetzt werden sollen um das selbst definierte Sprint-Ziel zu erreichen. Nachdem das Team sich geeinigt hat, werden die Issues aus dem Product-Backlog, per "Drag and Drop" (Ziehen und Ablegen) in dem Sprint-Backlog abgelegt.
Pascal Meyer 24.2 170
Pascal Meyer 134.2 171 [[image:Sprintbacklog2.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 24.3 172
Pascal Meyer 134.2 173
Pascal Meyer 69.2 174 == Schätzungen ==
Pascal Meyer 26.1 175
Pascal Meyer 69.2 176 Anschließend müssen die Issues geschätzt werden (siehe [[Schätzen>>doc:Main.Scrum.WebHome||anchor="HSchE4tzenvonAufwE4nden"]]). Dieser Vorgang dient der Schärfung des Verständnisses des gesamtem Projektteams. Hierbei ist es wichtig sich auf eine Werteskala (bspw. Fibonacci) zu einigen (diese sollte über die gesamte Projektdauer beibehalten werden). Die Ergebnisse werden dann direkt in den Issues unter dem Punkt "Weight" festgehalten.
177
Pascal Meyer 136.2 178 [[image:Schätzung1.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 27.5 179
Pascal Meyer 137.2 180 [[image:Schätzung2.1.png||data-xwiki-image-style-border="true"]]
181
Pascal Meyer 136.2 182 Die Sprint-Planung ist somit abgeschlossen und der fertiggestellte Sprint ist unter dem Reiter **"Iteration" **vorzufinden.
Pascal Meyer 30.2 183
Pascal Meyer 140.1 184 [[image:IterationSprint1.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 30.3 185
Pascal Meyer 140.1 186 [[image:IterationSprint2.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 32.2 187
sbeyer1 94.1 188 ----
189
Pascal Meyer 36.2 190 = Erstellung eines Wikis =
191
Pascal Meyer 83.1 192 Im Softwareprojekt müssen viele Daten dokumentiert (siehe [[Anforderungsanalyse>>doc:Main.Aufgabenstellung.WebHome||anchor="Teilaufgabe2:Anforderungsanalyse28Dokumentation29"]] und [[Entwurf>>doc:Main.Aufgabenstellung.WebHome||anchor="HTeilaufgabe3:Entwurf28Dokumentation29"]] sowie [[Dokumentation>>doc:Main.Anforderungen Software.WebHome||anchor="HAnforderungen:Dokumentation"]]) werden und unter anderem auch ein Projekttagebuch (siehe [[Projekttagebuch>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HProjekttagebuch"]] geführt werden. Dies wird in der Wiki-Funktion von GitLab umgesetzt. Diese Option ist in der Projektnavigationsleiste unter dem Reiter **"Wiki" **vorzufinden.
Pascal Meyer 37.2 193
Marco Grawunder 143.2 194 Hinweis: Grundsätzlich wäre es egal, ob man das Wiki unterhalb der Gruppe oder unterhalb des Projektes einhängt. Damit ich nicht so viel suchen muss, machen wir es so, dass das Wiki unterhalb des Projektes liegt (das haben die meisten, die was eingetragen haben, auch so gemacht)
195
196
Pascal Meyer 37.2 197 [[image:Wiki1.png||data-xwiki-image-style-border="true"]]
198
Pascal Meyer 38.2 199 [[image:Wiki2.png||data-xwiki-image-style-border="true"]]
200
Pascal Meyer 39.3 201 Im GitLab-Wiki muss die erste Seite die sogenannte **"Home"**-Seite sein. Sonst wird das Wiki nicht korrekt erzeugt. Die Seite wird mit der **"Create page"**-Funktion erstellt.
Pascal Meyer 39.2 202
203 [[image:Wiki3.png||data-xwiki-image-style-border="true"]]
Pascal Meyer 39.4 204
Pascal Meyer 43.1 205 Um weitere Seiten zu erstellen, wird in der "Page"-Hierachie das "+" unter Home ausgewählt. Nach Erstellung der neuen Seite, wird diese wieder mit der **"Create page"**-Funktion erstellt.
Pascal Meyer 39.5 206
Pascal Meyer 40.2 207 [[image:Wiki4.png||data-xwiki-image-style-border="true"]]
208
Sebastian Beyer 51.1 209 (% class="wikigeneratedid" id="H" %)
210 [[image:Wiki5.png||data-xwiki-image-style-border="true"]]
Sebastian Beyer 45.2 211
sbeyer1 85.1 212 ----
213
Sebastian Beyer 45.2 214 = Zeiterfassung in GitLab =
215
sbeyer1 140.2 216 Im Rahmen des Softwareprojekts sollt ihr eure Arbeitszeit präzise festhalten. Dazu könnt ihr direkt auf angelegten Issues/Tasks/User Stories in dem Bereich **Time tracking** eure Arbeitszeit Aufgabenspezifisch eintragen. In dem Fenster könnt ihr eintragen wie viel Zeit ihr gearbeitet habt, an welchem Tag ihr gearbeitet habt, um nachträgliches verbuchen von Arbeitszeit zu ermöglichen, und eine kleine Zusammenfassung angeben. Sollte bereits Zeit erfasst worden sein, muss über das Plus (siehe Bild oben rechts im roten Rahmen) Zeit gebucht werden.
sbeyer1 140.3 217 **Wichtig (Stand: 21.10.2025): **Solltet ihr in eurer Gruppe **Epics** anlegen, dann bucht **keine** Zeit auf den Epics direkt, sondern auf darunter liegenden Issues.
sbeyer1 84.2 218
sbeyer1 140.2 219 [[image:1754139824426-497.png]]
220
sbeyer1 84.2 221 ----
222
sbeyer1 84.4 223 = GitLab Pipelines =
224
sbeyer1 84.5 225 Eine GitLab Pipeline ist eine in //.gitlab-ci.yml// definierte Abfolge von Jobs. Jobs können dabei beispielsweise die automatische Ausführung von Tests sein.
226
sbeyer1 84.6 227 == Pipeline im Basisprojekt v2 ==
sbeyer1 84.5 228
sbeyer1 84.10 229 Die Pipeline im Basisprojekt ist auf zwei Stages mit jeweils einem Job aufgeteilt und wird im Folgenden Schritt für Schritt erklärt. Ihr dürft im Rahmen des Softwareprojekts, wenn nötig, die Pipeline um weitere Jobs oder Stages erweitern. **Die bestehenden Jobs sollten allerdings **(von Studierenden) **nicht geändert werden.**
sbeyer1 84.6 230
sbeyer1 84.12 231 In der //.gitlab-ci.yml //werden zunächst die Stages definiert. Eine Stage ist eine logische Gruppe von Jobs, die in einem bestimmten Abschnitt der Pipeline ausgeführt werden. Jobs in einer Stage werden parallel ausgeführt, es sei denn es wird eine Abhängigkeit in den Jobs definiert.
232 Wenn alle Jobs in einer Stage (erfolgreich) abgeschlossen sind, startet die nächste Stage. Schlägt ein Job fehl wird die gesamte Pipeline gestoppt, außer es werden Jobs so markiert, dass sie fehlschlagen dürfen.
sbeyer1 84.10 233
sbeyer1 84.6 234 {{code language="yaml"}}
235 stages:
236 - verify
237 - deploy
238 {{/code}}
sbeyer1 84.12 239
sbeyer1 84.14 240 Der //verify-job //ist der erste Job, der in der Pipeline definiert ist. Er wird in der //verify-//Stage ausgeführt. Das Image ist ein Docker-Image, welches schon mit einer Java 21 Umgebung eingerichtet ist. Dadurch wird sichergestellt, dass der Job immer die gleiche Umgebung hat ("//but it works on my machine"//).
241 Im Script-Abschnitt wird dann mvn clean verify ausgeführt. Maven verify baut das Projekt und führt die Tests im Projekt aus.
sbeyer1 84.15 242 Die Rules definieren, wann ein Job ausgeführt wird und ob das Fehlschlagen des Jobs erlaubt ist. Regeln werden von oben nach unten ausgewertet. //$CI_PIPELINE_SOURCE == "schedule" //sagt dass der Job bei automatischen Aufrufen über einen zeitgesteuerten Start der Pipeline mit besonderen Einschränkungen ausgeführt werden soll. //allow_failure// erlaubt in dem Fall, dass bei automatischer Ausführung die Pipeline nicht abgebrochen wird, falls sich euer Projekt nicht bauen lässt, damit darauffolgende Jobs weiterhin ausgeführt werden.
sbeyer1 84.12 243
244 {{code language="yaml"}}
245 verify-job:
246 stage: verify
247 image: eclipse-temurin:21-jdk-alpine
248 script:
249 - "./mvnw clean verify"
250 rules:
251 - if: $CI_PIPELINE_SOURCE == "schedule"
252 when: always
253 allow_failure: true
254 - when: always
255 allow_failure: false
256 {{/code}}
sbeyer1 84.15 257
sbeyer1 84.16 258 (((
sbeyer1 84.19 259 Der //deploy_stats_pages// Job ist der erste Job, der in der //deploy//-Stage ausgeführt wird. Der Job erfasst eure Projektarbeitsdaten (bspw. eure Stundenbuchungen) und veröffentlicht diese, nur für euch in GitLab sichtbar, in eurem Projekt.
sbeyer1 85.1 260 Die Variablen sind Umgebungsvariablen, die zum Erfassen der Daten benötigt werden. **Die //TIME_FRAMES// Variable ist auskommentiert und sollte durch euren projektverantwortlichen Betreuer:in (Tutor:in) angepasst werden.** Durch die //TIME_FRAMES// Variable können die [[Einschätzungszeiträume>>https://xwiki.swl.informatik.uni-oldenburg.de/xwiki/bin/view/Main/Bewertung/#HBewertungszeitrE4ume]] sowie die "Soll-Zeit" pro Zeitraum gesetzt und für die Visualisierung verwendet werden.
sbeyer1 84.22 261 Im Script-Bereich wird erst git installiert und dann die Projekete zur Erfassung und Visualisierung der Daten installiert.
sbeyer1 84.23 262 Der Artifakt-Bereich definiert welche Dateien nach Ausführung des Jobs behalten werden. Der Public Ordner wird verwendet, um statische Websiten zu veröffentlichen. In diesem Fall die Visualisierung der erfassten Daten.
sbeyer1 84.24 263 Im Gegensatz zum //verify-job// wird der //deploy_stats_pages//-Job **nur** ausgeführt, wenn die Pipeline zeitgesteuert gestartet wird.
sbeyer1 84.16 264
265 {{code language="yaml"}}
266 deploy_stats_pages:
sbeyer1 84.15 267 stage: deploy
268 image: maven:3.9.9-amazoncorretto-21-al2023
269 variables:
270 DEVELOPMENT_BRANCH_NAME: "development"
271 FETCH_MULTITHREAD: "true" #options are true/false
272 LOGLEVEL: "SHORT" #options are OFF, SHORT, LONG. Has an effect on the amount of logging when data is being added
273 #TIME_FRAMES: "01.01.2025,31.03.2025,40,Zeitraum01;01.04.2025,31.05.2025,35" #Format start,end,minHours[,name];anotherTimeframe;anotherTimeframe;...
274 script:
275 - yum install -y git rsync
276 - git clone https://gitlab.swl.informatik.uni-oldenburg.de/GA/gitlab2data.git
277 - cd gitlab2data
278 - mvn clean package
279 - java -jar target/GitLab2Data-1.0-SNAPSHOT-jar-with-dependencies.jar
280 - cd ..
281 - mkdir -p public/data
282 - rm -f public/data/*.json
283 - cp gitlab2data/*.json public/data/
284 - git clone https://gitlab.swl.informatik.uni-oldenburg.de/GA/data4visual.git repo
285 - rsync -av --exclude='data/' --exclude='.git' --exclude='.gitignore' repo/ public/
286 artifacts:
287 paths:
288 - public
289 pages:
290 path_prefix: "stats" #to allow for parallel deployments of the projects own page don't make the stats site the main deployment
291 expire_in: never
292 rules:
293 - if: $CI_PIPELINE_SOURCE == "schedule"
294 when: always
sbeyer1 84.16 295 - when: never
296 {{/code}}
sbeyer1 85.1 297
298 ----
299
sbeyer1 85.2 300 = GitLab Pages (Einsehen der erfassten Projektdaten) =
301 )))
302
sbeyer1 94.1 303 Wie im vorherigen Abschnitt beschrieben, werden im Softwareprojekt mit Hilfe der Pipeline Daten erfasst. Diese Daten können dann aus GitLab eingesehen werden, dazu kann man im Projekt über Deploy -> Pages und das Parallele Deployment "stats" die Daten einsehen.
Marco Grawunder 101.3 304 [[image:Deploy->Pages.png||alt="Pages können im Projekt über Deploy -> Pages eingesehen werden"]][[image:ParallelDeploymentsStats.png||height="174" width="1226"]]
sbeyer1 94.1 305
306 == User Overview ==
307
308 Auf der Seite User overview wird eine kompakte Übersicht aller Projektmitglieder dargstellt. Nutzer:innen werden nicht dargestellt, solange keine Zeitbuchung getätigt wurde.
sbeyer1 100.2 309 [[image:Useroverview.png]]
sbeyer1 94.1 310
311 == Timelogs ==
312
313 Unter Timelogs können einzelne Zeiteintragungen eingesehen werden. Dazu gibt es einige Filtermöglichkeiten, sowie die Möglichkeit nach Zeiträumen zu filtern. In Tabellenform lassen sich die Einträge einzelner Tage anklicken, um eine detailliertere Beschreibung einsehen zu können.
314
sbeyer1 98.2 315 [[image:TimeLogs.png]]
sbeyer1 94.1 316
317 == Request (und Review) Overview ==
318
319 Auf der Seite Request Overview können alle im Projekt erstellten Merge Requests eingesehen werden. Unter dem Diagramm ist zusätzlich eine Tabelle zu sehen, die neben der Anzahl im Diagramm noch weitere Informationen wie bspw. Titel und Status beinhaltet. Die Daten lassen sich nach Zielbranch (interessant ist hier Development) und Nutzer:in (durch einen Klick im Tortendiagramm) filtern. Die Seite Review Overview ist vom Verhalten analog gestaltet.
320
sbeyer1 99.2 321 [[image:RequestOverview.png]]
sbeyer1 94.1 322
323 == Code Contribution ==
324
325 Die Code Contribution Seite zeigt grafisch aufbereitete Informationen über die Menge an geschriebenem Code und die Zahl der Commits. Der Nutzer kann zwischen verschiedenen Diagrammtypen wählen (tägliche, monatliche oder Gesamtsummen für Code-nderungen bzw. Commits) und über Filter den dargestellten Zeitraum einschränken. Auch die Skalierung der Y-Achse kann angepasst werden.
326
sbeyer1 96.2 327 [[image:Codecontribution.png]]
sbeyer1 94.1 328
329 == Target Time ==
330
331 Die Target Time Seite ermöglicht die Auswertung der Arbeitszeit im Vergleich zur erwarteten Mindestarbeitszeit über definierte Zeiträume hinweg. Die Zeiträume müssen für eine Verwendung der Seite vom **Betreuer der Gruppe** (Tutor) in der GitLab Pipeline als Variable gesetzt sein (siehe Abschnitt zur Pipeline im Basisprojekt2). Wenn alles gesetzt ist, dann kann über die Seite eingesehen werden, wie viel Zeit im Verhältnis der erwarteten Zeit, ins Projekt investiert wurde. **Unter der roten Linie sollte keiner auf Dauer sein.**
332
sbeyer1 95.2 333 [[image:TargetTime.png]]
sbeyer1 94.1 334
335 ----
336
337