Skip to Content

Wiki source code of GitLab Erklärungen

Version 84.20 by sbeyer1 on 2025/08/25 12:02
Show last authors
1 [[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]]
2
3 {{toc/}}
4
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.
6
7 = Issue/Task-Erstellung in GitLab =
8
9 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.
10
11 [[image:Issue1.png||data-xwiki-image-style-border="true"]]
12
13 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.
14
15 Als **"Type" **stehen drei Optionen zur Auswahl:
16
17 * "Incident" - Ein Zwischenfall/Störung
18 * "Issue" - Im SWP eine User-Story (siehe [[User-Stories>>doc:Main.Scrum.WebHome||anchor="HUserStories"]])
19 * "Task" - Eine Aufgabe
20
21 Im unten gezeigtem Beispiel wird ein Issue gewählt und mit einem Titel (Name der User-Story) und einer Beschreibung (Akzeptanzkriterien) versehen.
22
23 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.
24
25 [[image:Issue2.png||data-xwiki-image-style-border="true"]]
26
27 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.
28
29 [[image:Issue3.png||data-xwiki-image-style-border="true"]]
30
31 Hier wurde als Aufgabe das Feld für die Eingabe definiert. Anschließend wurde die Eingabe mit **"Create task"** bestätigt.
32
33 [[image:Issue4.png||data-xwiki-image-style-border="true"]]
34
35 Nachdem alle Informationen eingepflegt und ausführlich beschrieben wurden, ist das Issue vorerst fertig.
36
37 [[image:Issue5.png||data-xwiki-image-style-border="true"]]
38
39 == Status bei Issues ==
40
41 In GitLab werden standardmäßig fünf verschiedene Statusformen angeboten. Diese Optionen sind:
42
43 * **To do** (wird bei der Issue Erstellung standardmäßig ausgewählt)
44 * **In progress**
45 * **Done**
46 * **Won't do**
47 * **Duplicate**
48
49 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.
50
51 [[image:Issue Status 1.png||data-xwiki-image-style-border="true"]]
52
53 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.
54
55 [[image:Issue Status 2.png||data-xwiki-image-style-border="true"]]
56
57 [[image:Issue Status 3.png||data-xwiki-image-style-border="true"]]
58
59 == Meilensteine und Epics ==
60
61 Im Laufe des Softwareprojektes werden eine Menge an Issues erstellt. Damit der Überblick, über die Vielzahl an Issues, nicht verloren geht wird im Softwareprojekt mit Meilensteinen (siehe [[Meilensteine>>doc:Main.Anforderungen Software.WebHome||anchor="HAnforderungen:DievordefiniertenMeilensteine"]]) und Epics gearbeitet. In GitLab werden beide Funktionen mit **"Labels"** umgesetzt. Diese Option ist im Reiter "Manage" und anschließend unter "Labels" vorzufinden.
62
63 [[image:Label 1.png||data-xwiki-image-style-border="true"]]
64
65 [[image:Label 2.png||data-xwiki-image-style-border="true"]]
66
67 [[image:Label 3.png||data-xwiki-image-style-border="true"]]
68
69 Die Erstellung von Epics sind kongruent zur Erstellung der Meilensteine-Label**. **Zur Veranschaulichung wird das Epic-Label **"Lobby" **erstellt.
70
71 [[image:Epic1.png||data-xwiki-image-style-border="true"]]
72
73 [[image:Epic2.png||data-xwiki-image-style-border="true"]]
74
75 [[image:Epic3.png||data-xwiki-image-style-border="true"]]
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.
78
79 [[image:Issue Label 2.png||data-xwiki-image-style-border="true"]]
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 = Product-Backlog =
86
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.
88
89 [[image:ProductBacklog1.png||data-xwiki-image-style-border="true"]]
90
91 [[image:ProductBacklog2.png||data-xwiki-image-style-border="true"]]
92
93 == Pflege/Priorisierung des Product-Backlogs ==
94
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
97 [[image:ProductBacklog3.png||data-xwiki-image-style-border="true"]]
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 = Erstellung eines Sprints =
120
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.
122
123 [[image:Sprint1.png||data-xwiki-image-style-border="true"]]
124
125 Damit ein neuer Sprint erstellt werden kann, wird der Sprint mit einem Titel, einem Start- sowie Enddatum und einer Beschreibung versehen. Das Sprintziel sollte in der Beschreibung festgehalten werden. Im unten aufgeführten Beispiel ist die Registrierung und die Anmeldung das angestrebte Sprintziel. Gespeichert wird der Sprint durch die "**Create milestone"**-Funktion
126
127 [[image:Sprint2.png||data-xwiki-image-style-border="true"]]
128
129 [[image:Sprint3.png||data-xwiki-image-style-border="true"]]
130
131 == Sprint-Backlog ==
132
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
135 [[image:Sprint4.1.png||data-xwiki-image-style-border="true"]]
136
137 Hierbei werden wieder verschiedene Optionen angeboten. Für die Erstellung eines Sprints bzw. der Durchführung der Sprintplanung, wird die Option **"Milestone"** und der eben erstellte Sprint als **"Value"** ausgewählt. Anschließend wird der Vorgang durch die **"Add to board"**-Funktion bestätigt.
138
139 [[image:Sprint5.png||data-xwiki-image-style-border="true"]]
140
141 [[image:Sprint6.1.png||data-xwiki-image-style-border="true"]]
142
143 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.
144
145 [[image:Sprint8.png||data-xwiki-image-style-border="true"]]
146
147 == Schätzungen ==
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 [[image:SprintS.png||data-xwiki-image-style-border="true"]]
152
153 Die Sprint-Planung ist somit abgeschlossen und der fertiggestellte Sprint ist unter dem Reiter **"Milestones" **vorzufinden.
154
155 [[image:SprintE.png||data-xwiki-image-style-border="true"]]
156
157 [[image:SprintF.png||data-xwiki-image-style-border="true"]]
158
159 = Erstellung eines Wikis =
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.
162
163 [[image:Wiki1.png||data-xwiki-image-style-border="true"]]
164
165 [[image:Wiki2.png||data-xwiki-image-style-border="true"]]
166
167 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.
168
169 [[image:Wiki3.png||data-xwiki-image-style-border="true"]]
170
171 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.
172
173 [[image:Wiki4.png||data-xwiki-image-style-border="true"]]
174
175 (% class="wikigeneratedid" id="H" %)
176 [[image:Wiki5.png||data-xwiki-image-style-border="true"]]
177
178 = Zeiterfassung in GitLab =
179
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// 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.
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}}
218
219 (((
220 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.
221 Die Variablen sind Umgebungsvariablen, die zum Erfassen der Daten benötigt werden. **Die //TIME_FRAMES// Variable ist auskommentiert und sollte durch euren Projektverantwortlichen**
222
223 {{code language="yaml"}}
224 deploy_stats_pages:
225 stage: deploy
226 image: maven:3.9.9-amazoncorretto-21-al2023
227 variables:
228 DEVELOPMENT_BRANCH_NAME: "development"
229 FETCH_MULTITHREAD: "true" #options are true/false
230 LOGLEVEL: "SHORT" #options are OFF, SHORT, LONG. Has an effect on the amount of logging when data is being added
231 #TIME_FRAMES: "01.01.2025,31.03.2025,40,Zeitraum01;01.04.2025,31.05.2025,35" #Format start,end,minHours[,name];anotherTimeframe;anotherTimeframe;...
232 script:
233 - yum install -y git rsync
234 - git clone https://gitlab.swl.informatik.uni-oldenburg.de/GA/gitlab2data.git
235 - cd gitlab2data
236 - mvn clean package
237 - java -jar target/GitLab2Data-1.0-SNAPSHOT-jar-with-dependencies.jar
238 - cd ..
239 - mkdir -p public/data
240 - rm -f public/data/*.json
241 - cp gitlab2data/*.json public/data/
242 - git clone https://gitlab.swl.informatik.uni-oldenburg.de/GA/data4visual.git repo
243 - rsync -av --exclude='data/' --exclude='.git' --exclude='.gitignore' repo/ public/
244 artifacts:
245 paths:
246 - public
247 pages:
248 path_prefix: "stats" #to allow for parallel deployments of the projects own page don't make the stats site the main deployment
249 expire_in: never
250 rules:
251 - if: $CI_PIPELINE_SOURCE == "schedule"
252 when: always
253 - when: never
254 {{/code}}
255 )))