Update Lerntagebuch.md

Lerntagebuch.md

@@ -384,6 +384,142 @@ Aus dem Seminarischen Unterricht und der Übung kann ich für das Gruppe
 Der Release-Branch in Git dient der Vorbereitung einer Software-Version. Er zweigt von einem Commit im Develop-Branch ab. Im Release-Branch werden nur noch Bugs entfernt und gefixt. Die fertige Version landet dann sowohl im Master-Branch als auch im Develop-Branch, damit die Fixes auch da vorhanden sind.
 
 
+### Kritik
+
+Keine
+
+---
+
+
+## SU 05 (28.11.2023) - Kooperation SCM
+
+### Lernziel
+
+**Seminarischer Unterricht:**
+ 
+- Programme werden Komplexer --> Man muss zusammenarbeiten
+- Zusammenführen der Einzelleistungen
+- Probleme:
+    - Unterschiedliche Formatierungen des Codes
+    - Technische Konflikte --> Selbe Stelle von zwei Entwicklern bearbeitet
+    - Persönliche Konflikte --> Streit
+- Lösung: CI-System
+    - Verringert Aufwand des Personals
+    - Erfordert formale Vorgehensweisen --> Autoformater, verhindert Streit
+    - Vorstufe zu Continuous Delivery
+
+Softwareentwicklungsprozess
+- Code schreiben
+- Abhängigkeiten verwalten
+- Veröffentlichung des Codes
+- Integration
+- Build-Prozess
+- Kompilieren
+- Testen --> Automatisiert
+- Bereitstellung nach den Erwartungen des Kunden
+
+Abhängigkeitsverwaltung
+- Abhängigkeiten sind Codestücke von anderen Entwicklern
+- Nicht im SCM eingecheckt, sondern zentral bereitgestellt (z.B. Github)
+- Zugriff auf einzelne Versionen --> Muss sich auf bestimmte Version beziehen, sonst eventuell inkompatibel
+
+Versionsnummer
+Major.Minor.Patch-Label
+- Major: 
+    - Wenn erhöht: Inkompatible Änderungen --> Man muss Änderungen am eigenen Quellcode machen wenn man die Library nutzen will
+- Minor:
+    - Wenn erhöht: Zusätzliche Features, bleibt aber abwärtskompatibel
+- Patch
+    - Wenn erhöht: Fehlerbereinigung, bleibt abwärtskompatibel
+- Label
+    - Build-Kennzeichnung, Beschreibung, möglichst ohne Label
+    - Ausschließlich Ziffern und Punkte, rein amerikanisches Ascii
+- Immer wenn sich die höhere Nummer ändert werden die danach wieder auf 0 gesetzt --> Bessere Praxis: Patch-Level nie zurücksetzen
+- Ein nicht vorhandenes Label ist eine höhere Version als mit Label
+
+SCM
+- Sicherung der Arbeit einzelner Entwickler
+- Zentrale Verfügbarmachung
+- Zusammenführung von parallel bearbeiteten Dateien
+- Parallele Entwicklung verschiedener Features
+- Einzelne Stände
+- Im SCM sollte funktionaler Stand sein
+- Wechsel zwischen Branches
+
+Build-Prozess
+- Organisieren von Abhängigkeiten
+- Übersetzen des Codes
+- Automatisierte Tests
+- Liefer-Artefakt erzeugt
+- "Deployment" --> Herausgabe des fertigen Ergebnisses
+
+Compiler:
+- make / ceedling
+    - C/C++ 
+    - Keine Abhängigkeitenverwaltung
+    - Meistens wird nur dsa genutzt was der Compiler bereitstellt
+- maven/gradle
+    - Java
+    - Abhängigkeiten werden automatisch mit bereitgestellt
+- npm
+    - JavaScript/TypeScript
+
+Was macht ein CI-System?
+- SCM überwachen --> "Ist neuer Code da?"
+- Änderungen zusammenführen 
+- Build-Prozess
+- Auflösung der Abhängigkeiten
+- Kompilieren
+- Automatisierte Tests
+- Lieferartefakt erstellen
+- Lieferartefakt ausliefern
+- Bericht über Ergebnisse
+
+Automatisierte Tests
+- Kein menschlicher Eingriff
+- Kompilierbar heißt nicht zwangsläufig auch ausführbar
+- CI soll immer auslieferbaren Stand haben
+- Programm wird im CI-System ausgeführt mit automatisierten Tests
+- Dokumentation von gewünschtem Ergebnis → Laufzeitfehler können gefunden werden
+- Pro: Ausführungszeit von Arbeitszeit entkoppeln --> Kann über Nacht gemacht werden
+- Con: Test kann nur Abweichung von gewünschtem Ergebnis/Verhalten finden --> Es können nur bekannte Fehler entdeckt werden
+
+Vorgehensmodelle für Kooperation
+- Gemeinsames Remote-Repository
+    - Alle arbeiten auf diesem Remote-Repository
+    - Alle brauchen Schreibzugriff darauf --> Aufwändige Verwaltung von Berechtigungen
+    - Jeder Developer braucht Accout bei Instanz
+    - Einfache Synchronisation
+    - Gepushte Zwischenstände für alle verfügbar --> Änderungen gehen nicht verloren, unfertiger Stand problematisch
+- Private Fork
+    - Jeder Dev hat eigene Kopie des zentralen Reps auf eigenem Rep
+    - Nur der Dev selbst hat darauf Zugriff
+    - Zentrales Remote Rep --> Master, CI-System
+    - Jedes lokale Rep hat zwei remote Reps:
+    - Origin --> Master, read only
+    - Upstream --> Provater Fork, Schreibrechte
+    - Änderung mit Pull-Request aus Fork in Master --> Maintainer überprüft Code
+
+
+**Praxisübung:**
+Mehr nützliche Git-Befehle:
+- init --bare → Erzeugt ein Repository ohne versteckten .git-Ordner
+- remote add (name) (path) → Fügt ein Remote-Repository hinzu
+- push (repository) (branch) → Pusht den Branch auf das angegebene Remote-Repository
+- push --set-upstream
+- push --force-with-lease → Sorgt dafür, dass Commits nicht überschrieben werden
+
+
+### Erkenntnis
+
+Aus dem Seminarischen Unterricht und der Praxisübung kann ich das Wissen über Zusammenarbeit sowie CI-Systeme mitnehmen.
+
+
+### Wiederholung
+
+Ein Continous Integration System (kurz: CI-System) überwacht den aktuellen Stand im Source Code Management System. Werden Änderungen festgestellt, werden eventuelle Änderungen von anderen Entwicklern automatisch zusammengeführt. Danach wird das Projekt kompiliert, nachdem sich das CI-System um die Abhängigkeiten gekümmert hat. Das fertige Programm wird anschließend automatisch getestet, nach Erwartungswerten die der Programmierer vorher eingeben muss. Und schließlich gibt das CI-System einen Bericht über die Resultate zurück.
+
+
 ### Kritik
 
 Keine