Skip to Content

Changes for page GitLab Erklärungen

Last modified by Sebastian Beyer on 2026/10/13 10:43
From version 150.1
edited by Marco Grawunder
on 2026/08/25 15:21
Change comment: There is no comment for this version
To version 162.6
edited by Sebastian Beyer
on 2026/10/13 10:39
Change comment: Auto-saved during real-time collaboration

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.mgrawunder
1 +XWiki.sbeyer1
Content
... ... @@ -3,7 +3,7 @@
3 3  
4 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 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:Main.GitLab.Kompakt: Scrum in Gitlab.WebHome]].
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 7  {{/info}}
8 8  
9 9  [[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]]
... ... @@ -15,7 +15,7 @@
15 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 16  )))
17 17  
18 -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.
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 19  
20 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 21  
... ... @@ -71,10 +71,19 @@
71 71  
72 72  [[image:Issue Status 3.png||data-xwiki-image-style-border="true"]]
73 73  
74 -== Meilensteine und Epics ==
74 +== Meilensteine und größere Themenbereiche ==
75 75  
76 -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.Softwareentwicklung.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.
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 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 +
78 78  === Meilensteine ===
79 79  
80 80  Um einen neuen Meilenstein zu erstellen, wird in der Projektnavigationsleiste der Reiter** "Milestones" **angeklickt und nachfolgend die Option **"New milestone"** ausgewählt.
... ... @@ -91,13 +91,13 @@
91 91  
92 92  [[image:Meilenstein4.1.png||data-xwiki-image-style-border="true"]]
93 93  
94 -=== Epics ===
103 +=== Größere Themenbereiche über Labels ===
95 95  
96 -Um ein neues Epic zu erstellen, wird in der Projektnavigationsleiste der Reiter** "Labels" **angeklickt und nachfolgend die Option **"New Label"** ausgewählt.
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.
97 97  
98 98  [[image:Label 1.png||data-xwiki-image-style-border="true"]]
99 99  
100 -Das neue Epic wird mit einem Titel, einer Beschreibung und einer Farbe versehen. Bestätigt wird die Erstellung mit der "**Create label**"-Funktion.
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.
101 101  
102 102  [[image:Epic2.png||data-xwiki-image-style-border="true"]]
103 103  
... ... @@ -129,7 +129,7 @@
129 129  
130 130  == Erstellung neuer Listen ==
131 131  
132 -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.
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.
133 133  
134 134  [[image:IssueList2.png||data-xwiki-image-style-border="true"]]
135 135  
... ... @@ -226,8 +226,8 @@
226 226  
227 227  = Zeiterfassung in GitLab =
228 228  
229 -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.
230 -**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.
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.
231 231  
232 232  [[image:1754139824426-497.png]]
233 233  
... ... @@ -235,15 +235,22 @@
235 235  
236 236  = GitLab Pipelines =
237 237  
238 -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.
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.
239 239  
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 +
240 240  == Pipeline im Basisprojekt v2 ==
241 241  
242 -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.**
255 +Die Pipeline im Basisprojekt besteht aus zwei Stages mit insgesamt drei Jobs. Sie überprüft automatisch euer Projekt und stellt verschiedene Berichte bereit.
243 243  
244 -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.
245 -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.
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.
246 246  
259 +=== Aufbau der Pipeline ===
260 +
261 +Zunächst werden in der //.gitlab-ci.yml //die beiden Stages definiert:
262 +
247 247  {{code language="yaml"}}
248 248  stages:
249 249   - verify
... ... @@ -250,72 +250,101 @@
250 250   - deploy
251 251  {{/code}}
252 252  
253 -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"//).
254 -Im Script-Abschnitt wird dann mvn clean verify ausgeführt. Maven verify baut das Projekt und führt die Tests im Projekt aus.
255 -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.
269 +(((
270 +Die Pipeline enthält folgende Jobs:
256 256  
257 -{{code language="yaml"}}
258 -verify-job:
259 - stage: verify
260 - image: eclipse-temurin:21-jdk-alpine
261 - script:
262 - - "./mvnw clean verify"
263 - rules:
264 - - if: $CI_PIPELINE_SOURCE == "schedule"
265 - when: always
266 - allow_failure: true
267 - - when: always
268 - allow_failure: false
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
269 269  {{/code}}
270 270  
271 -(((
272 - 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.
273 -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.
274 -Im Script-Bereich wird erst git installiert und dann die Projekete zur Erfassung und Visualisierung der Daten installiert.
275 -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.
276 -Im Gegensatz zum //verify-job// wird der //deploy_stats_pages//-Job **nur** ausgeführt, wenn die Pipeline zeitgesteuert gestartet wird.
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.
277 277  
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 +
278 278  {{code language="yaml"}}
279 -deploy_stats_pages:
280 - stage: deploy
281 - image: maven:3.9.9-amazoncorretto-21-al2023
282 - variables:
283 - DEVELOPMENT_BRANCH_NAME: "development"
284 - FETCH_MULTITHREAD: "true" #options are true/false
285 - LOGLEVEL: "SHORT" #options are OFF, SHORT, LONG. Has an effect on the amount of logging when data is being added
286 - #TIME_FRAMES: "01.01.2025,31.03.2025,40,Zeitraum01;01.04.2025,31.05.2025,35" #Format start,end,minHours[,name];anotherTimeframe;anotherTimeframe;...
287 - script:
288 - - yum install -y git rsync
289 - - git clone https://gitlab.swl.informatik.uni-oldenburg.de/GA/gitlab2data.git
290 - - cd gitlab2data
291 - - mvn clean package
292 - - java -jar target/GitLab2Data-1.0-SNAPSHOT-jar-with-dependencies.jar
293 - - cd ..
294 - - mkdir -p public/data
295 - - rm -f public/data/*.json
296 - - cp gitlab2data/*.json public/data/
297 - - git clone https://gitlab.swl.informatik.uni-oldenburg.de/GA/data4visual.git repo
298 - - rsync -av --exclude='data/' --exclude='.git' --exclude='.gitignore' repo/ public/
299 - artifacts:
300 - paths:
301 - - public
302 - pages:
303 - path_prefix: "stats" #to allow for parallel deployments of the projects own page don't make the stats site the main deployment
304 - expire_in: never
305 - rules:
306 - - if: $CI_PIPELINE_SOURCE == "schedule"
307 - when: always
308 - - when: never
331 +needs:
332 + - job: verify-job
333 + artifacts: true
309 309  {{/code}}
310 310  
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 +(% style="margin-left:auto; margin-right:auto" %)
351 +|=Ausführung|=Verify und SpotBugs|=Projektstatistiken
352 +|Normaler Push au| |
353 +| | |
354 +| | |
355 +
311 311  ----
312 312  
313 313  = GitLab Pages (Einsehen der erfassten Projektdaten) =
314 314  )))
315 315  
316 - Wie im vorherigen Abschnitt beschrieben, werden im Softwareprojekt mit Hilfe der Pipeline Daten erfasst. Diese Daten können dann aus GitLab eingesehen werden, dazu ist in dem Wiki in eurem Projekt (nicht auf Gruppenebene!) auf der Startseite ein Link hinterlegt (Plan -> Wiki). Unter Gruppen Stats findet ihr die erfassten Daten (1x täglich aktualisiert). Unter Test Report findet ihr einen von Jacoco generierten Bericht über eure Test-Coverage. Um den Weg dahin zu erleichtern, könnt ihr den Wiki-Bereich anpinnen.
361 + 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.
317 317  
318 -[[image:1761672281141-645.png]][[image:1761672310982-950.png]]
363 +[[image:1791805037500-827.png]][[image:1791805272506-124.png||height="282" width="1112"]]
319 319  
320 320  == User Overview ==
321 321  
... ... @@ -336,7 +336,7 @@
336 336  
337 337  == Code Contribution ==
338 338  
339 -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.
384 +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.
340 340  
341 341  [[image:Codecontribution.png]]
342 342  
... ... @@ -348,4 +348,8 @@
348 348  
349 349  ----
350 350  
351 -
396 += Siehe auch =
397 +
398 +* [[Stichwortverzeichnis>>doc:Main.Index.WebHome]]
399 +* [[Glossar>>doc:Main.Glossar.WebHome]]
400 +* [[Scrum>>doc:Main.Scrum.WebHome]]
1791805016217-653.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.sbeyer1
Size
... ... @@ -1,0 +1,1 @@
1 +67.8 KB
Content
1791805037500-827.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.sbeyer1
Size
... ... @@ -1,0 +1,1 @@
1 +67.8 KB
Content
1791805270825-311.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.sbeyer1
Size
... ... @@ -1,0 +1,1 @@
1 +51.1 KB
Content
1791805272506-124.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.sbeyer1
Size
... ... @@ -1,0 +1,1 @@
1 +51.1 KB
Content