Skip to Content

Changes for page GitLab Erklärungen

Last modified by pmeyer on 2025/09/12 04:41
From version arrow_back 84.14 arrow_forward
edited by sbeyer1
on 2025/08/25 11:50
Change comment: There is no comment for this version
To version arrow_back 65.1 arrow_forward
edited by Pascal Meyer
on 2025/08/14 23:40
Change comment: Uploaded new attachment "Issue Label 3.png", version {1}

Summary

Details

insert_drive_file Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.sbeyer1
1 +XWiki.PascalMeyer
Content
... ... @@ -1,5 +3,3 @@
1 -[[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]]
2 -
3 3  {{toc/}}
4 4  
5 5  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.
... ... @@ -74,14 +74,9 @@
74 74  
75 75  [[image:Epic3.png||data-xwiki-image-style-border="true"]]
76 76  
77 -Bei der Issue-Erstellung/Bearbeitung können die erstellten Labels jetzt mit den neuen/bestehenden Issues verknüpft werden. Dies erfolgt trivial zur Status-Option.
75 +Bei der Issue-Erstellung/Bearbeitung können die erstellten Labels jetzt
78 78  
79 -[[image:Issue Label 2.png||data-xwiki-image-style-border="true"]]
80 80  
81 -[[image:Label 4.png||data-xwiki-image-style-border="true"]]
82 -
83 -[[image:Issue Label 3.png||data-xwiki-image-style-border="true"]]
84 -
85 85  = Product-Backlog =
86 86  
87 87  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.
... ... @@ -90,32 +90,10 @@
90 90  
91 91  [[image:ProductBacklog2.png||data-xwiki-image-style-border="true"]]
92 92  
93 -== Pflege/Priorisierung des Product-Backlogs ==
94 -
95 95  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 #1,#3,#4,#5,#6,#7 und für das Projekt unsortiert. Nach der Sortierung ist die Reihenfolge der Issues #7,#6,#5,#4,#3,#1 (Sortierung willkürlich gewählt und dient nur zu Anschauungszwecke).
96 96  
97 97  [[image:ProductBacklog3.png||data-xwiki-image-style-border="true"]]
98 98  
99 -== Erstellung neuer Listen ==
100 -
101 -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.
102 -
103 -[[image:Liste1.png||data-xwiki-image-style-border="true"]]
104 -
105 -In der sich öffnenden Option wird jetzt der Status **"in progress**" ausgewählt und mit der **"Add to board"**-Funktion bestätigt.
106 -
107 -[[image:Liste2.png||data-xwiki-image-style-border="true"]]
108 -
109 -[[image:Liste3.png||data-xwiki-image-style-border="true"]]
110 -
111 -Zusätzlich werden zur Veranschaulichung Listen für die Meilensteine- und Epic-Label erstellt.
112 -
113 -[[image:Liste4.png||data-xwiki-image-style-border="true"]]
114 -
115 -[[image:Liste5.png||data-xwiki-image-style-border="true"]]
116 -
117 -[[image:Liste6.png||data-xwiki-image-style-border="true"]]
118 -
119 119  = Erstellung eines Sprints =
120 120  
121 121  In GitLab erfolgt die Erstellung eines Sprints in sogenannten **"Milestones"** (Meilensteine). Diese Option ist in der Projektnavigationsleiste unter dem Reiter **"Milestones" **vorzufinden. Um einen neuen Sprint zu erstellen wird die **"New Milestone"**-Option ausgewählt.
... ... @@ -128,8 +128,6 @@
128 128  
129 129  [[image:Sprint3.png||data-xwiki-image-style-border="true"]]
130 130  
131 -== Sprint-Backlog ==
132 -
133 133  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.
134 134  
135 135  [[image:Sprint4.1.png||data-xwiki-image-style-border="true"]]
... ... @@ -144,10 +144,8 @@
144 144  
145 145  [[image:Sprint8.png||data-xwiki-image-style-border="true"]]
146 146  
147 -== Schätzungen ==
116 +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 Schätzung kann bspw. auf der Seite: https://www.scrumpoker-online.org/en/ durchgeführt werden. Die Ergebnisse werden dann direkt in den Issues unter dem Punkt "Weight" festgehalten.
148 148  
149 -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.
150 -
151 151  [[image:SprintS.png||data-xwiki-image-style-border="true"]]
152 152  
153 153  Die Sprint-Planung ist somit abgeschlossen und der fertiggestellte Sprint ist unter dem Reiter **"Milestones" **vorzufinden.
... ... @@ -158,7 +158,7 @@
158 158  
159 159  = Erstellung eines Wikis =
160 160  
161 -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.
128 +Im Softwareprojekt müssen viele Daten dokumentiert (siehe [[Anforderungsanalys>>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.
162 162  
163 163  [[image:Wiki1.png||data-xwiki-image-style-border="true"]]
164 164  
... ... @@ -178,40 +178,3 @@
178 178  = Zeiterfassung in GitLab =
179 179  
180 180  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.[[image:1754139824426-497.png]]
181 -
182 -----
183 -
184 -= GitLab Pipelines =
185 -
186 -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.
187 -
188 -== Pipeline im Basisprojekt v2 ==
189 -
190 -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.**
191 -
192 -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.
193 -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.
194 -
195 -{{code language="yaml"}}
196 -stages:
197 - - verify
198 - - deploy
199 -{{/code}}
200 -
201 -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"//).
202 -Im Script-Abschnitt wird dann mvn clean verify ausgeführt. Maven verify baut das Projekt und führt die Tests im Projekt aus.
203 -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//
204 -
205 -{{code language="yaml"}}
206 -verify-job:
207 - stage: verify
208 - image: eclipse-temurin:21-jdk-alpine
209 - script:
210 - - "./mvnw clean verify"
211 - rules:
212 - - if: $CI_PIPELINE_SOURCE == "schedule"
213 - when: always
214 - allow_failure: true
215 - - when: always
216 - allow_failure: false
217 -{{/code}}
attach_file Epic2.png
Size
... ... @@ -1,1 +1,1 @@
1 -71.1 KB
1 +90.7 KB
Content info
attach_file Label 4.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.PascalMeyer
Size
... ... @@ -1,1 +1,0 @@
1 -172.5 KB
Content info
attach_file Liste1.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.PascalMeyer
Size
... ... @@ -1,1 +1,0 @@
1 -130.0 KB
Content info
attach_file Liste2.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.PascalMeyer
Size
... ... @@ -1,1 +1,0 @@
1 -184.5 KB
Content info
attach_file Liste3.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.PascalMeyer
Size
... ... @@ -1,1 +1,0 @@
1 -191.4 KB
Content info
attach_file Liste4.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.PascalMeyer
Size
... ... @@ -1,1 +1,0 @@
1 -220.4 KB
Content info
attach_file Liste5.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.PascalMeyer
Size
... ... @@ -1,1 +1,0 @@
1 -239.4 KB
Content info
attach_file Liste6.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.PascalMeyer
Size
... ... @@ -1,1 +1,0 @@
1 -293.5 KB
Content info