Wiki source code of GitLab Erklärungen
Last modified by Sebastian Beyer on 2026/09/14 22:56
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
150.1 | 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:Main.GitLab.Kompakt: Scrum in Gitlab.WebHome]]. | ||
| 7 | {{/info}} | ||
| 8 | |||
| |
148.1 | 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 | |||
| |
152.1 | 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. |
| |
148.1 | 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 | |||
| |
152.1 | 74 | == Meilensteine und größere Themenbereiche == |
| |
148.1 | 75 | |
| |
152.1 | 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. |
| |
148.1 | 77 | |
| |
152.1 | 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 | |||
| |
148.1 | 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 | |||
| |
152.1 | 103 | === Größere Themenbereiche über Labels === |
| |
148.1 | 104 | |
| |
152.1 | 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. |
| |
148.1 | 106 | |
| 107 | [[image:Label 1.png||data-xwiki-image-style-border="true"]] | ||
| 108 | |||
| |
152.1 | 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. |
| |
148.1 | 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 | |||
| |
154.1 | 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. |
| |
148.1 | 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 | |||
| |
150.1 | 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. |
| |
148.1 | 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 | |||
 |
155.3 | 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. |
| |
155.4 | 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. |
| |
148.1 | 240 | |
| 241 | [[image:1754139824426-497.png]] | ||
| 242 | |||
| 243 | ---- | ||
| 244 | |||
| 245 | = GitLab Pipelines = | ||
| 246 | |||
| 247 | 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. | ||
| 248 | |||
| 249 | == Pipeline im Basisprojekt v2 == | ||
| 250 | |||
| 251 | 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.** | ||
| 252 | |||
| 253 | 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. | ||
| 254 | 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. | ||
| 255 | |||
| 256 | {{code language="yaml"}} | ||
| 257 | stages: | ||
| 258 | - verify | ||
| 259 | - deploy | ||
| 260 | {{/code}} | ||
| 261 | |||
| 262 | 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"//). | ||
| 263 | Im Script-Abschnitt wird dann mvn clean verify ausgeführt. Maven verify baut das Projekt und führt die Tests im Projekt aus. | ||
| 264 | 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. | ||
| 265 | |||
| 266 | {{code language="yaml"}} | ||
| 267 | verify-job: | ||
| 268 | stage: verify | ||
| 269 | image: eclipse-temurin:21-jdk-alpine | ||
| 270 | script: | ||
| 271 | - "./mvnw clean verify" | ||
| 272 | rules: | ||
| 273 | - if: $CI_PIPELINE_SOURCE == "schedule" | ||
| 274 | when: always | ||
| 275 | allow_failure: true | ||
| 276 | - when: always | ||
| 277 | allow_failure: false | ||
| 278 | {{/code}} | ||
| 279 | |||
| 280 | ((( | ||
| 281 | 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. | ||
| |
151.1 | 282 | 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/#HEinschE4tzungszeitrE4ume]] sowie die "Soll-Zeit" pro Zeitraum gesetzt und für die Visualisierung verwendet werden. |
| |
148.1 | 283 | Im Script-Bereich wird erst git installiert und dann die Projekete zur Erfassung und Visualisierung der Daten installiert. |
| 284 | 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. | ||
| 285 | Im Gegensatz zum //verify-job// wird der //deploy_stats_pages//-Job **nur** ausgeführt, wenn die Pipeline zeitgesteuert gestartet wird. | ||
| 286 | |||
| 287 | {{code language="yaml"}} | ||
| 288 | deploy_stats_pages: | ||
| 289 | stage: deploy | ||
| 290 | image: maven:3.9.9-amazoncorretto-21-al2023 | ||
| 291 | variables: | ||
| 292 | DEVELOPMENT_BRANCH_NAME: "development" | ||
| 293 | FETCH_MULTITHREAD: "true" #options are true/false | ||
| 294 | LOGLEVEL: "SHORT" #options are OFF, SHORT, LONG. Has an effect on the amount of logging when data is being added | ||
| 295 | #TIME_FRAMES: "01.01.2025,31.03.2025,40,Zeitraum01;01.04.2025,31.05.2025,35" #Format start,end,minHours[,name];anotherTimeframe;anotherTimeframe;... | ||
| 296 | script: | ||
| 297 | - yum install -y git rsync | ||
| 298 | - git clone https://gitlab.swl.informatik.uni-oldenburg.de/GA/gitlab2data.git | ||
| 299 | - cd gitlab2data | ||
| 300 | - mvn clean package | ||
| 301 | - java -jar target/GitLab2Data-1.0-SNAPSHOT-jar-with-dependencies.jar | ||
| 302 | - cd .. | ||
| 303 | - mkdir -p public/data | ||
| 304 | - rm -f public/data/*.json | ||
| 305 | - cp gitlab2data/*.json public/data/ | ||
| 306 | - git clone https://gitlab.swl.informatik.uni-oldenburg.de/GA/data4visual.git repo | ||
| 307 | - rsync -av --exclude='data/' --exclude='.git' --exclude='.gitignore' repo/ public/ | ||
| 308 | artifacts: | ||
| 309 | paths: | ||
| 310 | - public | ||
| 311 | pages: | ||
| 312 | path_prefix: "stats" #to allow for parallel deployments of the projects own page don't make the stats site the main deployment | ||
| 313 | expire_in: never | ||
| 314 | rules: | ||
| 315 | - if: $CI_PIPELINE_SOURCE == "schedule" | ||
| 316 | when: always | ||
| 317 | - when: never | ||
| 318 | {{/code}} | ||
| 319 | |||
| 320 | ---- | ||
| 321 | |||
| 322 | = GitLab Pages (Einsehen der erfassten Projektdaten) = | ||
| 323 | ))) | ||
| 324 | |||
| 325 | 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. | ||
| 326 | |||
| 327 | [[image:1761672281141-645.png]][[image:1761672310982-950.png]] | ||
| 328 | |||
| 329 | == User Overview == | ||
| 330 | |||
| 331 | Auf der Seite User overview wird eine kompakte Übersicht aller Projektmitglieder dargstellt. Nutzer:innen werden nicht dargestellt, solange keine Zeitbuchung getätigt wurde. | ||
| 332 | [[image:Useroverview.png]] | ||
| 333 | |||
| 334 | == Timelogs == | ||
| 335 | |||
| 336 | 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. | ||
| 337 | |||
| 338 | [[image:TimeLogs.png]] | ||
| 339 | |||
| 340 | == Request (und Review) Overview == | ||
| 341 | |||
| 342 | 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. | ||
| 343 | |||
| 344 | [[image:RequestOverview.png]] | ||
| 345 | |||
| 346 | == Code Contribution == | ||
| 347 | |||
| |
155.1 | 348 | 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. |
| |
148.1 | 349 | |
| 350 | [[image:Codecontribution.png]] | ||
| 351 | |||
| 352 | == Target Time == | ||
| 353 | |||
| 354 | 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.** | ||
| 355 | |||
| 356 | [[image:TargetTime.png]] | ||
| 357 | |||
| 358 | ---- | ||
| 359 | |||
| |
153.1 | 360 | = Siehe auch = |
| 361 | |||
| 362 | * [[Stichwortverzeichnis>>doc:Main.Index.WebHome]] | ||
| 363 | * [[Glossar>>doc:Main.Glossar.WebHome]] | ||
| 364 | * [[Scrum>>doc:Main.Scrum.WebHome]] |