Changes for page GitLab Erklärungen

Summary

• Page properties (2 modified, 0 added, 0 removed)
• Attachments (0 modified, 4 added, 0 removed)
  • 1791805016217-653.png
  • 1791805037500-827.png
  • 1791805270825-311.png
  • 1791805272506-124.png

Details

Page properties

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.mgrawunder
	1	+XWiki.sbeyer1

Content

...	...	@@ -1,3 +1,11 @@
	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	+
1	1	[[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]]
2	2
3	3	{{toc/}}
...	...	@@ -7,7 +7,7 @@
7	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.
8	8	)))
9	9
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.
	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.
11	11
12	12	**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)
13	13
...	...	@@ -63,10 +63,19 @@
63	63
64	64	[[image:Issue Status 3.png||data-xwiki-image-style-border="true"]]
65	65
66		-== Meilensteine und Epics ==
	74	+== Meilensteine und größere Themenbereiche ==
67	67
68		-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.
69	69
	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	+
70	70	=== Meilensteine ===
71	71
72	72	Um einen neuen Meilenstein zu erstellen, wird in der Projektnavigationsleiste der Reiter** "Milestones" **angeklickt und nachfolgend die Option **"New milestone"** ausgewählt.
...	...	@@ -83,13 +83,13 @@
83	83
84	84	[[image:Meilenstein4.1.png||data-xwiki-image-style-border="true"]]
85	85
86		-=== Epics ===
	103	+=== Größere Themenbereiche über Labels ===
87	87
88		-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.
89	89
90	90	[[image:Label 1.png||data-xwiki-image-style-border="true"]]
91	91
92		-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.
93	93
94	94	[[image:Epic2.png||data-xwiki-image-style-border="true"]]
95	95
...	...	@@ -121,7 +121,7 @@
121	121
122	122	== Erstellung neuer Listen ==
123	123
124		-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.
125	125
126	126	[[image:IssueList2.png||data-xwiki-image-style-border="true"]]
127	127
...	...	@@ -191,7 +191,7 @@
191	191
192	192	= Erstellung eines Wikis =
193	193
194		-Im Softwareprojekt müssen viele Daten dokumentiert (siehe [[Anforderungsanalyse>>doc:Main.Dokumentation.WebHome]] und [[Entwurf>>doc:Main.Dokumentation.WebHome||anchor="HTeilaufgabe3:Entwurf28Dokumentation29"]] 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.
	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.
195	195
196	196	(% class="box infomessage" %)
197	197	(((
...	...	@@ -218,8 +218,8 @@
218	218
219	219	= Zeiterfassung in GitLab =
220	220
221		-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.
222		-**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.
223	223
224	224	[[image:1754139824426-497.png]]
225	225
...	...	@@ -227,15 +227,22 @@
227	227
228	228	= GitLab Pipelines =
229	229
230		-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.
231	231
	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	+
232	232	== Pipeline im Basisprojekt v2 ==
233	233
234		-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.
235	235
236		-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.
237		-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.
238	238
	259	+=== Aufbau der Pipeline ===
	260	+
	261	+Zunächst werden in der //.gitlab-ci.yml //die beiden Stages definiert:
	262	+
239	239	{{code language="yaml"}}
240	240	stages:
241	241	- verify
...	...	@@ -242,72 +242,128 @@
242	242	- deploy
243	243	{{/code}}
244	244
245		-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"//).
246		-Im Script-Abschnitt wird dann mvn clean verify ausgeführt. Maven verify baut das Projekt und führt die Tests im Projekt aus.
247		-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:
248	248
249		-{{code language="yaml"}}
250		-verify-job:
251		- stage: verify
252		- image: eclipse-temurin:21-jdk-alpine
253		- script:
254		- - "./mvnw clean verify"
255		- rules:
256		- - if: $CI_PIPELINE_SOURCE == "schedule"
257		- when: always
258		- allow_failure: true
259		- - when: always
260		- 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
261	261	{{/code}}
262	262
263		-(((
264		- 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.
265		-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.
266		-Im Script-Bereich wird erst git installiert und dann die Projekete zur Erfassung und Visualisierung der Daten installiert.
267		-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.
268		-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.
269	269
	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	+
270	270	{{code language="yaml"}}
271		-deploy_stats_pages:
272		- stage: deploy
273		- image: maven:3.9.9-amazoncorretto-21-al2023
274		- variables:
275		- DEVELOPMENT_BRANCH_NAME: "development"
276		- FETCH_MULTITHREAD: "true" #options are true/false
277		- LOGLEVEL: "SHORT" #options are OFF, SHORT, LONG. Has an effect on the amount of logging when data is being added
278		- #TIME_FRAMES: "01.01.2025,31.03.2025,40,Zeitraum01;01.04.2025,31.05.2025,35" #Format start,end,minHours[,name];anotherTimeframe;anotherTimeframe;...
279		- script:
280		- - yum install -y git rsync
281		- - git clone https://gitlab.swl.informatik.uni-oldenburg.de/GA/gitlab2data.git
282		- - cd gitlab2data
283		- - mvn clean package
284		- - java -jar target/GitLab2Data-1.0-SNAPSHOT-jar-with-dependencies.jar
285		- - cd ..
286		- - mkdir -p public/data
287		- - rm -f public/data/*.json
288		- - cp gitlab2data/*.json public/data/
289		- - git clone https://gitlab.swl.informatik.uni-oldenburg.de/GA/data4visual.git repo
290		- - rsync -av --exclude='data/' --exclude='.git' --exclude='.gitignore' repo/ public/
291		- artifacts:
292		- paths:
293		- - public
294		- pages:
295		- path_prefix: "stats" #to allow for parallel deployments of the projects own page don't make the stats site the main deployment
296		- expire_in: never
297		- rules:
298		- - if: $CI_PIPELINE_SOURCE == "schedule"
299		- when: always
300		- - when: never
	331	+needs:
	332	+ - job: verify-job
	333	+ artifacts: true
301	301	{{/code}}
302	302
	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	+
303	303	----
304	304
305	305	= GitLab Pages (Einsehen der erfassten Projektdaten) =
306	306	)))
307	307
308		- 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.
	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.
309	309
310		-[[image:1761672281141-645.png]][[image:1761672310982-950.png]]
	390	+[[image:1791805037500-827.png]][[image:1791805272506-124.png||height="282" width="1112"]]
311	311
312	312	== User Overview ==
313	313
...	...	@@ -328,7 +328,7 @@
328	328
329	329	== Code Contribution ==
330	330
331		-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.
	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.
332	332
333	333	[[image:Codecontribution.png]]
334	334
...	...	@@ -340,4 +340,8 @@
340	340
341	341	----
342	342
343		-
	423	+= Siehe auch =
	424	+
	425	+* [[Stichwortverzeichnis>>doc:Main.Index.WebHome]]
	426	+* [[Glossar>>doc:Main.Glossar.WebHome]]
	427	+* [[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