Skip to Content

Wiki source code of GitLab Erklärungen

Last modified by Sebastian Beyer on 2026/10/13 10:43
Show last authors
1 {{info}}
2 **Worum geht es auf dieser Seite?**
3
4 Hier wird beschrieben, **wie die Projektarbeit technisch in GitLab abgebildet wird**: Issues und Tasks, Product Backlog, Meilensteine, Sprints/Iterations, Zeiterfassung, Wiki und CI/CD.
5
6 Die methodischen Scrum-Grundlagen stehen unter [[Scrum>>doc:Main.Scrum.WebHome]]. Wer den Prozess bereits kennt und nur eine kompakte Zuordnung der GitLab-Funktionen benötigt, findet sie unter [[Kompakt: Scrum in GitLab>>doc:.Kompakt\: Scrum in Gitlab.WebHome]].
7 {{/info}}
8
9 [[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]]
10
11 {{toc/}}
12
13 (% class="box infomessage" %)
14 (((
15 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.
16 )))
17
18 Im Softwareprojekt werden Projektstrukturierung und der [[Scrum>>doc:Main.Scrum.WebHome]]-Prozess in GitLab abgebildet. Die folgenden Abschnitte erklären die dafür wichtigsten GitLab-Funktionen.
19
20 **Hinweis: **Es gibt (inzwischen) auch ein Tutorial zum Scrum bei Gitlab direkt: [[https:~~/~~/docs.gitlab.com/tutorials/scrum_events/>>https://docs.gitlab.com/tutorials/scrum_events/]] (englisch)
21
22 = Issue/Task-Erstellung in GitLab =
23
24 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.
25
26 [[image:Issue1.png||data-xwiki-image-style-border="true"]]
27
28 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.
29
30 Als **"Type" **stehen drei Optionen zur Auswahl:
31
32 * "Incident" - Ein Zwischenfall/Störung
33 * "Issue" - Im SWP eine User-Story (siehe [[User-Stories>>doc:Main.Scrum.WebHome||anchor="HUserStories"]])
34 * "Task" - Eine Aufgabe
35
36 Im unten gezeigtem Beispiel wird ein Issue gewählt und mit einem Titel (Name der User-Story) und einer Beschreibung (Akzeptanzkriterien) versehen.
37
38 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.
39
40 [[image:Issue2.png||data-xwiki-image-style-border="true"]]
41
42 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.
43
44 [[image:Issue3.png||data-xwiki-image-style-border="true"]]
45
46 Hier wurde als Aufgabe das Feld für die Eingabe definiert. Anschließend wurde die Eingabe mit **"Create task"** bestätigt.
47
48 [[image:Issue4.png||data-xwiki-image-style-border="true"]]
49
50 Nachdem alle Informationen eingepflegt und ausführlich beschrieben wurden, ist das Issue vorerst fertig.
51
52 [[image:Issue5.png||data-xwiki-image-style-border="true"]]
53
54 == Status bei Issues ==
55
56 In GitLab werden standardmäßig fünf verschiedene Statusformen angeboten. Diese Optionen sind:
57
58 * **To do** (wird bei der Issue Erstellung standardmäßig ausgewählt)
59 * **In progress**
60 * **Done**
61 * **Won't do**
62 * **Duplicate**
63
64 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.
65
66 [[image:Issue Status 1.png||data-xwiki-image-style-border="true"]]
67
68 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.
69
70 [[image:Issue Status 2.png||data-xwiki-image-style-border="true"]]
71
72 [[image:Issue Status 3.png||data-xwiki-image-style-border="true"]]
73
74 == Meilensteine und größere Themenbereiche ==
75
76 Im Laufe des Softwareprojekts entstehen viele Issues. Zur Strukturierung werden **Meilensteine** (siehe [[Meilensteine>>doc:Main.Softwareentwicklung.WebHome||anchor="HVorgegebeneMeilensteine"]]) und größere fachliche Themenbereiche verwendet.
77
78 * **Milestones** bilden wichtige Zielstände bzw. Meilensteine ab.
79 * **Issues** bilden typischerweise User Stories, Bugs oder Aufgaben ab.
80 * **Labels** können verwendet werden, um Issues größeren fachlichen Themenbereichen oder Komponenten zuzuordnen.
81
82 {{info}}
83 Ein solcher Themenbereich ist **nicht das Product Backlog**. Das Product Backlog ist die priorisierte Gesamtheit der noch offenen Produktanforderungen. Falls die eingesetzte GitLab-Version echte **Epics** bereitstellt, können diese für größere Features bzw. Themen verwendet werden; andernfalls lässt sich eine ähnliche Gruppierung über Labels erreichen.
84 {{/info}}
85
86
87 === Meilensteine ===
88
89 Um einen neuen Meilenstein zu erstellen, wird in der Projektnavigationsleiste der Reiter** "Milestones" **angeklickt und nachfolgend die Option **"New milestone"** ausgewählt.
90
91 [[image:Meilenstein1.1.png||data-xwiki-image-style-border="true"]]
92
93 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.
94
95 [[image:Meilenstein2.png||data-xwiki-image-style-border="true"]]
96
97 [[image:Meilenstein3.png||data-xwiki-image-style-border="true"]]
98
99 Dem frisch erstellten Meilensteinen können jetzt Issues zugewiesen werden. Dies funktioniert trivial zu der Statusvergabe.
100
101 [[image:Meilenstein4.1.png||data-xwiki-image-style-border="true"]]
102
103 === Größere Themenbereiche über Labels ===
104
105 Um einen größeren Themenbereich über ein Label abzubilden, wird in der Projektnavigation **Manage → Labels** geöffnet und anschließend **New Label** ausgewählt.
106
107 [[image:Label 1.png||data-xwiki-image-style-border="true"]]
108
109 Das neue Label wird mit einem sprechenden Titel, einer Beschreibung und einer Farbe versehen. Bestätigt wird die Erstellung mit der "**Create label**"-Funktion.
110
111 [[image:Epic2.png||data-xwiki-image-style-border="true"]]
112
113 [[image:Label1.png||data-xwiki-image-style-border="true"]]
114
115 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.
116
117 [[image:Issue Label 2.png||data-xwiki-image-style-border="true"]]
118
119 [[image:Labelissue1.png||data-xwiki-image-style-border="true"]]
120
121 [[image:Label2.png||data-xwiki-image-style-border="true"]]
122
123 ----
124
125 = Product-Backlog =
126
127 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.
128
129 [[image:ProductBacklog1.png||data-xwiki-image-style-border="true"]]
130
131 [[image:IssueList1.1.png||data-xwiki-image-style-border="true"]]
132
133 == Pflege/Priorisierung des Product-Backlogs ==
134
135 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).
136
137 [[image:IssueList1.2.png||data-xwiki-image-style-border="true"]]
138
139 == Erstellung neuer Listen ==
140
141 In GitLab können die Listen auch genutzt werden um beispielsweise Meilensteine oder Epics darzustellen (siehe [[Meilensteine und Epics>>doc:Main.GitLab.WebHome||anchor="HMeilensteineundgrF6DFereThemenbereiche"]]). 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.
142
143 [[image:IssueList2.png||data-xwiki-image-style-border="true"]]
144
145 In der sich öffnenden Option wird jetzt der Status **"in progress**" ausgewählt und mit der **"Add to board"**-Funktion bestätigt.
146
147 [[image:IssueList3.png||data-xwiki-image-style-border="true"]]
148
149 [[image:IssueList4.png||data-xwiki-image-style-border="true"]]
150
151 Zusätzlich werden zur Veranschaulichung Listen für die Epic-Label und Meilensteine erstellt.
152
153 [[image:IssueList5.png||data-xwiki-image-style-border="true"]]
154
155 [[image:IssueList6.png||data-xwiki-image-style-border="true"]]
156
157 [[image:MeilensteinList1.png||data-xwiki-image-style-border="true"]]
158
159 [[image:MeilensteinList2.png||data-xwiki-image-style-border="true"]]
160
161 ----
162
163 = Erstellung eines Sprints =
164
165 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.
166
167 [[image:Iteration1.png||data-xwiki-image-style-border="true"]]
168
169 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.
170
171 [[image:Iteration2.1.png||data-xwiki-image-style-border="true"]]
172
173 [[image:Iteration3.1.png||data-xwiki-image-style-border="true"]]
174
175 == Sprint-Backlog ==
176
177 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.
178
179 [[image:IssueList2.png||data-xwiki-image-style-border="true"]]
180
181 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.
182
183 [[image:Sprintbacklog1.png||data-xwiki-image-style-border="true"]]
184
185 [[image:Sprintbacklog3.png||data-xwiki-image-style-border="true"]]
186
187
188 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.
189
190 [[image:Sprintbacklog2.png||data-xwiki-image-style-border="true"]]
191
192
193 == Schätzungen ==
194
195 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.
196
197 [[image:Schätzung1.png||data-xwiki-image-style-border="true"]]
198
199 [[image:Schätzung2.1.png||data-xwiki-image-style-border="true"]]
200
201 Die Sprint-Planung ist somit abgeschlossen und der fertiggestellte Sprint ist unter dem Reiter **"Iteration" **vorzufinden.
202
203 [[image:IterationSprint1.png||data-xwiki-image-style-border="true"]]
204
205 [[image:IterationSprint2.png||data-xwiki-image-style-border="true"]]
206
207 ----
208
209 = Erstellung eines Wikis =
210
211 Im Softwareprojekt müssen viele Daten dokumentiert (siehe [[Anforderungsanalyse>>doc:Main.Dokumentation.WebHome]] und [[Entwurf>>doc:Main.Dokumentation.WebHome||anchor="HArchitekturundEntwurf"]] sowie [[Dokumentation>>doc:Main.Dokumentation.WebHome||anchor="HAnforderungen:Dokumentation"]]) werden und unter anderem auch ein Projekttagebuch (siehe [[Projekttagebuch>>doc:Main.Projektarbeit.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.
212
213 (% class="box infomessage" %)
214 (((
215 **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).
216 )))
217
218
219 [[image:Wiki1.png||data-xwiki-image-style-border="true"]]
220
221 [[image:Wiki2.png||data-xwiki-image-style-border="true"]]
222
223 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.
224
225 [[image:Wiki3.png||data-xwiki-image-style-border="true"]]
226
227 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.
228
229 [[image:Wiki4.png||data-xwiki-image-style-border="true"]]
230
231 (% class="wikigeneratedid" id="H" %)
232 [[image:Wiki5.png||data-xwiki-image-style-border="true"]]
233
234 ----
235
236 = Zeiterfassung in GitLab =
237
238 Im Rahmen des Softwareprojekts sollt ihr eure Arbeitszeit präzise festhalten. Dazu könnt ihr direkt auf angelegten **Issues/Tasks/User Stories und Merge Requests** 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.
239 **Wichtig! (Stand: 21.10.2025/14.09.2026): **Solltet ihr in eurer Gruppe **Epics** anlegen, dann bucht **keine** Zeit auf den Epics direkt, sondern auf darunter liegenden Issues. Der Grund dafür ist, dass GitLab es nicht ermöglicht die Buchungen auf Epics auszulesen und daher werden diese Buchungen für die Auswertungsseiten nicht erfasst.
240
241 [[image:1754139824426-497.png]]
242
243 ----
244
245 = GitLab Pipelines =
246
247 Eine GitLab Pipeline ist eine in der Datei //.gitlab-ci.yml// definierte Abfolge von Jobs. Diese Jobs können beispielsweise das Projekt automatisch bauen, Tests ausführen oder Berichte erstellen und veröffentlichen.
248
249 Die Jobs werden in sogenannten **Stages** (Phasen) organisiert. Jobs innerhalb einer Stage können parallel ausgeführt werden, sofern keine Abhängigkeiten festgelegt wurden. Die nächste Stage beginnt normalerweise erst, wenn die vorherige abgeschlossen ist.
250
251 Schlägt ein Job fehl, wird die Pipeline normalerweise als fehlgeschlagen markiert und nachfolgende Stages werden nicht mehr ausgeführt. Über die Einstellung allow_failure kann jedoch festgelegt werden, dass bestimmte Jobs fehlschlagen dürfen, ohne die weitere Ausführung der Pipeline zu verhindern.
252
253 == Pipeline im Basisprojekt v2 ==
254
255 Die Pipeline im Basisprojekt besteht aus zwei Stages mit insgesamt drei Jobs. Sie überprüft automatisch euer Projekt und stellt verschiedene Berichte bereit.
256
257 Die Pipeline darf im Rahmen des Softwareprojekts bei Bedarf um weitere Jobs oder Stages **erweitert** werden. Die **bestehenden Jobs** sollten von Studierenden allerdings **nicht verändert werden**, da sie für die Überprüfung und Auswertung des Projekts benötigt werden.
258
259 === Aufbau der Pipeline ===
260
261 Zunächst werden in der //.gitlab-ci.yml //die beiden Stages definiert:
262
263 {{code language="yaml"}}
264 stages:
265 - verify
266 - deploy
267 {{/code}}
268
269 (((
270 Die Pipeline enthält folgende Jobs:
271
272 * **verify-job (Stage: verify):** Baut das Projekt, führt Tests und weitere Überprüfungen aus und erstellt Berichte zur Testabdeckung (JaCoCo) und zu möglichen Codeproblemen (SpotBugs).
273 * **deploy_spotbugs_pages (Stage: deploy):** Veröffentlicht den zuvor erzeugten SpotBugs-Bericht als eigene GitLab-Pages-Seite.
274 * **deploy_stats_pages (Stage: deploy):** Erfasst regelmäßig eure Projektarbeitsdaten, beispielsweise Stundenbuchungen, und veröffentlicht eine Visualisierung dieser Daten.
275
276 Der verify-job führt die eigentlichen Überprüfungen durch. Die beiden Jobs der Deploy-Stage kümmern sich um die Veröffentlichung bzw. Bereitstellung der Berichte. Dabei wird der Statistik-Job nur bei zeitgesteuerten Pipelines ausgeführt.
277
278 ==== 1. Verify-Stage: Projekt überprüfen ====
279
280 Der erste Job der Pipeline heißt verify-job. Er wird in der Stage verify ausgeführt.
281
282 Für diesen Job wird das Docker-Image maven:3.9.9-eclipse-temurin-21 verwendet. Es stellt eine Umgebung mit Maven und Java 21 bereit. Dadurch wird sichergestellt, dass das Projekt bei jeder Pipeline-Ausführung unter vergleichbaren Bedingungen überprüft wird und nicht von den lokal installierten Entwicklungswerkzeugen abhängig ist.
283
284 Die eigentliche Überprüfung erfolgt durch folgenden Maven-Befehl:
285
286 {{code}}
287 ./mvnw clean verify jacoco:report
288 {{/code}}
289
290 Mit diesem Befehl wird das Projekt neu gebaut, die konfigurierten Tests und Maven-Überprüfungen werden ausgeführt und die Erstellung der JaCoCo-Berichte angestoßen.
291
292 Zusätzlich verarbeitet der Job die SpotBugs-Ergebnisse. Dazu werden zwei bereitgestellte Python-Skripte verwendet. Diese bereiten die gefundenen Probleme auf und erzeugen eine übersichtliche HTML-Seite.
293
294 Die erzeugten Berichte werden anschließend im Ordner public gesammelt und als sogenannte **Artifacts** gespeichert. Artifacts sind Dateien, die nach der Ausführung eines Jobs erhalten bleiben und beispielsweise von weiteren Jobs verwendet werden können.
295
296 ===== **JaCoCo: Testabdeckung** =====
297
298 JaCoCo ist ein Werkzeug zur Messung der Testabdeckung. Es zeigt euch, welche Teile eures Java-Codes bei der Ausführung der Tests durchlaufen wurden.
299
300 So könnt ihr erkennen, welche Klassen oder Methoden bereits durch Tests abgedeckt sind und an welchen Stellen möglicherweise noch Tests fehlen.
301
302 Der verify-job erstellt einen zusammengefassten JaCoCo-Bericht für das Projekt und veröffentlicht ihn über GitLab Pages. Dadurch könnt ihr die Ergebnisse direkt im Browser ansehen.
303
304 **Wichtig:** Eine hohe Testabdeckung bedeutet nicht automatisch, dass alle Tests sinnvoll sind oder dass das Projekt fehlerfrei ist. Sie hilft euch aber dabei, bisher ungetestete Bereiche zu erkennen.
305
306 ===== **SpotBugs: Mögliche Codeprobleme erkennen** =====
307
308 Neben JaCoCo wird auch SpotBugs verwendet. SpotBugs untersucht Java-Code auf typische Fehlermuster und mögliche Programmierfehler.
309
310 Die gefundenen Probleme werden in verschiedenen Formaten bereitgestellt:
311
312 * **HTML-Bericht:** Eine übersichtliche Darstellung der gefundenen Probleme mit zusätzlichen Erklärungen.
313 * **XML-Berichte:** Die ursprünglichen SpotBugs-Ergebnisse der einzelnen Module.
314 * **GitLab Code Quality:** Die Ergebnisse werden in ein Format umgewandelt, das GitLab zur Darstellung von Codequalitätsproblemen verwenden kann.
315
316 Die HTML-Berichte helfen euch, mögliche Fehler schneller zu verstehen und im eigenen Code nachzuvollziehen.
317
318 Die SpotBugs-Ergebnisse werden zunächst vom verify-job erstellt und anschließend durch einen eigenen Job veröffentlicht.
319
320 ==== 2. Deploy-Stage: Berichte veröffentlichen ====
321
322 In der zweiten Stage deploy werden die erzeugten Berichte bereitgestellt.
323
324 ===== **SpotBugs-Berichte veröffentlichen (deploy_spotbugs_pages)** =====
325
326 Der Job deploy_spotbugs_pages übernimmt die SpotBugs-Dateien aus dem vorherigen verify-job und veröffentlicht sie über GitLab Pages.
327
328 Hierfür verwendet der Job die folgende Einstellung:
329
330 {{code language="yaml"}}
331 needs:
332 - job: verify-job
333 artifacts: true
334 {{/code}}
335
336 Dadurch wird festgelegt, dass der Job die Ergebnisse des verify-job benötigt und dessen gespeicherte Artifacts verwendet.
337
338 Anschließend werden die SpotBugs-Dateien in den Ordner public kopiert. GitLab Pages verwendet diesen Ordner, um die Berichte als Webseite bereitzustellen.
339
340 Für jeden Branch wird eine eigene SpotBugs-Seite veröffentlicht. Dadurch könnt ihr die Ergebnisse eures aktuellen Entwicklungsbranches unabhängig von denen anderer Branches ansehen.
341
342 ==== 3. Wann werden die Jobs ausgeführt? ====
343
344 Die Pipeline unterscheidet zwischen normalen Ausführungen, beispielsweise nach einem Push, und zeitgesteuerten Ausführungen (Schedules).
345
346 Die Regeln für den verify-job und den deploy_spotbugs_pages-Job werden zentral unter .report_rules definiert und von beiden Jobs gemeinsam verwendet.
347
348 Dabei gelten folgende Regeln:
349
350
351 (% style="margin-left:auto; margin-right:auto" %)
352 |=Ausführung|=Verify und SpotBugs|=Projektstatistiken
353 |Normaler Push auf den Standardbranch|(((
354 Werden ausgeführt,
355
356 Fehler führen zum Fehlschlagen der Pipeline
357 )))|Werden nicht aktualisiert
358 |Push auf einen anderen Branch|(((
359 Werden ausgeführt,
360
361 Fehler führen zum Fehlschlagen der Pipeline
362 )))|Werden nicht aktualisiert
363 |(((
364 Zeitgesteuerte Pipeline
365
366 (Im SWP meist 1xam Tag)
367 )))|(((
368 Werden ausgeführt,
369
370 Fehler dürfen auftreten, ohne die gesamte
371
372 Pipeline scheitern zu lassen
373 )))|Werden aktualisiert
374
375  Die zeitgesteuerten Pipelines sind insbesondere für die regelmäßige Aktualisierung der Projektstatistiken wichtig.
376
377 Da sich euer Projekt möglicherweise nicht zu jedem Zeitpunkt fehlerfrei bauen lässt (//sollte **nicht** passieren)//, dürfen die Überprüfungsjobs bei zeitgesteuerten Ausführungen fehlschlagen (allow_failure: true). Dadurch wird verhindert, dass ein Fehler im Projektbuild grundsätzlich die nachfolgende Aktualisierung der Statistiken blockiert.
378
379 Bei normalen Pipeline-Ausführungen ist ein Fehlschlagen dagegen nicht erlaubt (allow_failure: false). Dadurch werden Fehler beim Bauen oder Testen des Projekts unmittelbar sichtbar.
380
381 **Hinweis:** Die Statistiken werden nur bei einer zeitgesteuerten Pipeline aktualisiert. Ein gewöhnlicher Push auf einen Branch löst zwar die Überprüfung des Projekts und die Erstellung der Codeberichte aus, aktualisiert aber nicht die Statistikseite.
382
383 ----
384
385 = GitLab Pages (Einsehen der erfassten Projektdaten) =
386 )))
387
388 Wie im vorherigen Abschnitt beschrieben, werden im Softwareprojekt mit Hilfe der Pipeline Daten erfasst. Diese Daten können dann aus GitLab eingesehen werden. Für die Gruppen-Stats könnt ihr rechts bei den Projekt Informationen das Badge für "Stat Report" anklicken. Den Jacoco Report findet ihr unter Operate->Environments -> reports -> jacoco-<Branch-Name>. Neben dem JaCoCo Bericht findet ihr dort auch generierte SpotBugs Berichte. Um diese Berichte zu öffnen, drückt ihr einfach auf den "Open"-Button. Dann sollte der jeweilige Bericht in einem neuen Tab geöffnet werden.
389
390 [[image:1791805037500-827.png]][[image:1791805272506-124.png||height="282" width="1112"]]
391
392 == User Overview ==
393
394 Auf der Seite User overview wird eine kompakte Übersicht aller Projektmitglieder dargstellt. Nutzer:innen werden nicht dargestellt, solange keine Zeitbuchung getätigt wurde.
395 [[image:Useroverview.png]]
396
397 == Timelogs ==
398
399 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.
400
401 [[image:TimeLogs.png]]
402
403 == Request (und Review) Overview ==
404
405 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.
406
407 [[image:RequestOverview.png]]
408
409 == Code Contribution ==
410
411 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.
412
413 [[image:Codecontribution.png]]
414
415 == Target Time ==
416
417 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.**
418
419 [[image:TargetTime.png]]
420
421 ----
422
423 = Siehe auch =
424
425 * [[Stichwortverzeichnis>>doc:Main.Index.WebHome]]
426 * [[Glossar>>doc:Main.Glossar.WebHome]]
427 * [[Scrum>>doc:Main.Scrum.WebHome]]