From 1f5d83efe4209b836fa4747dff5208aed4c22f5c Mon Sep 17 00:00:00 2001
From: devops <fdlt3790@hs-fulda.de>
Date: Sun, 29 Jan 2023 20:14:04 +0100
Subject: [PATCH] vorlesung-19-01

---
 Lerntagebuch.md | 176 +++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 174 insertions(+), 2 deletions(-)

diff --git a/Lerntagebuch.md b/Lerntagebuch.md
index 822c834..c7c6d61 100644
--- a/Lerntagebuch.md
+++ b/Lerntagebuch.md
@@ -133,22 +133,32 @@ Nochmal lauft das Programm im Debug-modes und eingeben zahl ist 47
 Öffnen Sie das programm `Uebung2.java` im Editor
 
 - Starten Sie das Programm mehrfach (_"run as Java Application"_) und geben Sie verschiedenen natürliche Zahlen ein.
-
+  
   - **natürliche zahlen sind 45, 14, 89 ergebnis sind False ingesamt**
 
 - setzen Sie einen BreakPoint in Zeile 40
+
 - Starten Sie das Programm wie bisher
+
 - Starten Sie das Programm im Debug-Modus und geben Sie die Zahl 45 ein
+
 - Notieren Sie die Inhalte der Variablen (this) nextInt: 23
+  
   - this: **Uebung2@8**
   - count: **3**
+
 - Notieren Sie die Anzahl der Einträge in der _Debug View_ (this): **this, count, in, out in total 4 mit Zwischenüberschritt**
 
 - in welcher Zeile steht der Debugger? 34->36
+
 - Notieren Sie die Anzahl der Einträge in der _Debug View_ (this)
+  
   - nextInt: **45**, count: **2**
+
 - in welcher Zeile steht der Debugger? **40**
+
 - Notieren Sie die Anzahl der Einträge in der _Debug View_ (this) false
+  
   - nextInt: **16**, count: **4** ergebnis: **false**
 
 **Beenden Sie den Debugger (_"Terminate"_)**
@@ -217,9 +227,11 @@ Lokale Respository
 
 - GUI Tests (end to end tests)
   business logik überprufen, functions und kommiunikation mit anderen components überprufen.
+
 - Integration tests
 
 - Component / Contract Tests
+
 - Unit Tests
 
 **Testnamen**
@@ -577,4 +589,164 @@ Schreibe Code im TDD cycle.
 
 ### Mitteilung
 
----
+--------------------------------------------------------------------------------
+
+## SU (19.01.2023)
+
+### Lernziel
+
+#### Continous Integration
+
+- Relavante Literatur
+- Bedeutung von CI im Softwareentwicklungsprozess
+- Aufbau eines CI/CD-Systems
+- Ablauf des CI-Prozesses
+- Rolle von automatisierten Tests
+
+### Erkenntnise
+
+#### Bedeutung von CI im Softwareentwicklungsprozess
+
+Größe von Software-Projekten
+- steigende Komplexität
+- mehrere Entwickler
+- Zusammenführen der Einzelleistungen
+
+Zusammenführen der Einzelleistungen
+- Widerspruch Kreativität vs. Konformität
+- technische Konflikte
+- persönliche Konflikte
+- Aufwand
+
+Vorteile von CI Systemen
+- formale Prozesse verringern
+- automatisierte Prozesse verringern Aufwand
+- Vorstufe zu Continous Delivery
+
+Aufbau eines CI/CD-Systems
+
+- Entwicklungsumgebung des Programmierers
+- Source Code Management System (SCM)
+- Abhängigkeitenverwaltung
+- build – Werkzeug
+- Continous Integration Server
+- Erweiterungen für Continous Delivery
+
+Entwicklungsumgebung des Programmierers
+
+Integrated Developement Environment (IDE)
+- Syntax highlighting
+- Syntax-Vervollständigung
+- automatisierte Refactorings
+- Navigation
+- Compile–Parameter
+- Code automatische Formatierung
+- Fehler-Lokalisierung
+
+Source Code Management System (SCM)
+- Sicherung der Arbeit einzelner Entwickler
+- zentrale Verfügbarmachung
+- Zusammenführung parallel geänderter Dateien
+- parallele Entwicklung verschiedener Features ermöglichen
+- Zugriff auf dedizierte Stände (releases)
+- wechsel zwischen Entwicklungsständen
+
+Abhängigkeitenverwaltung
+- nicht selbst im Build-Lauf erzeugt
+- zentrale Bereitstellung (innerhalb der Organisation)
+- Zugriff auf einzelne Versionen
+
+build – Werkzeug
+- Übersetzen
+- Liefer-Artefakte erzeugen
+- Abhängigkeiten organisieren
+- automatisierte Tests ausführen
+- Deploymen
+
+Continous Integration Server
+- SCM überwachen
+- build-Prozess starten
+- Ergebnisse berichteten
+
+Erweiterungen für Continous Delivery
+- Staging System
+- Produktions System
+
+Ablauf des CI-Prozesses
+- Checkin Change
+- Fetch Change
+- Build
+- Test
+- Ergebnisauswertung
+- Benachrichtigung
+
+Checkin Change
+- veröffentlichen der Änderung
+- eigener branch
+- alle aktuell veröffentlichten Änderungen integriert.
+- vollständige Änderung
+  - compiliert lokal
+  - automatisierte (Unit–)Tests sind ”grün”
+  - Lieferobjekt kann lokal gebaut werden
+
+Fetch Change
+- Änderungen feststellen
+- zeitgesteuert
+- ereignisgesteuert
+
+Build
+- Änderung mit aktuellem Stand integrieren (merge)
+- compile (Produktivcode und Testcode)
+
+Test
+- nur nach erfolgreichem compile
+- Testframework starten
+- Ergebnisse sammeln
+
+Ergebnisauswertung
+- Ermittelt Status von merge, compile und Test
+- Erfolgsfall: Änderung als neuen aktuellen Stand übernehmen undveröffentlichen
+- Ergebnisdarstellung als Webseite
+
+
+Benachrichtigung
+- zeitnah
+- Fehlerfall: Committer
+- Erfolgsfall: alle
+- mögliche Wege:
+  - Mail
+  - RSS-Feed
+  - SMS
+  - Twitter
+  - WhatsApp
+
+
+Rolle von automatisierten Tests
+- Problem des Continous Integration
+- Vorteile automatisierter Tests
+- Grenzen automatisierter Tests 
+
+Problem des Continous Integration
+- compilierbar ! = ausführbar
+- CI soll immer lieferbaren Stand bereit halten
+- Programm muss im CI Prozess ausgeführt werden
+
+Vorteile automatisierter Tests
+- automatisierte Tests führen Programm aus
+- dokumentieren gewünschtes Verhalten
+- sind wiederholbar
+- erkennen Laufzeitfehler (außer UnitTests)
+- Ausführungszeit von Arbeitszeit entkoppelt
+
+
+Grenzen automatisierter Tests
+- finden nur Abweichungen von gewünschten/bekanntem Verhalten
+- finden keine neuen fachlichen Fehler
+
+### Kritik
+
+### Mitteilung
+
+
+
+----------------------------------------------------------------------------------