@ -280,5 +280,120 @@
### Mitteilung an die Dozierenden
keine
## SU_05
### Automatisiertes Zusammenführen Literaturempfehlungen
### Lernziele
#### Gründe: man kann nicht alles allein bewältigen wegen steigender Komplexität und Aufwand. Deadlines sehr streng
mehrere Entwickler
Zusammenführen der Einzelleistungen
Aufwand ()
Formatierung des Quelltextes ist ein Problem (führt zu Konflikten beim Zusammenführen, kreativität hält nicht an Konvetionen)
technische Konflikte (z.B. zwei Entwickler müssen eine Stelle ändern)
persönliche Konflikte (gewöhnliche Gründe)
#### Vorteile: automatisierte Prozesse verringern den Aufwand was auch Zeit einspart
formale Prozesse verringern Konfliktpotential
Vorstufe für Continous Delivery (wenn nur noch automatische Prozesse ablaufen)
#### Entwicklungsprozess: Code schreiben
Abhängigkeitsverwaltung (Bibliotheken etc.). Bereitstellung zu Laufzeit
Veröffentlichug des Codes
Integration (Zusammenfügen zum Gesamtsoftware)
build-Prozess (erstellen des Zielformats der Software aus Queltext)
compile
test (automatisiertes Testen)
Bereitstellung (Erzeugung eine exe oder zip, Dateiform; Deliverable in Repository bereitzustellen)
#### Abhängigkeitsverwaltung: manche Teile kommen von außerhalb, alles was nicht aus dem Quellcode kommt ist Abhängigkeit
nicht im SCM eingecheckt
zentrale Bereitstellung (in der Organisation, JVM öffentliche Repositories, kann auch lokal erstellt werden)
Zugriff auf einzelne Versionen (zeitgemäs, sonst konflikte)
#### Versionierung: MAJOR inkompatible Änderungen (Änderungen am Quellcode)
MINOR zusätliche Features
Programmteil bleibt
abwärtskompatibel
PATCH Fehlerbehebungen
Programmteil bleibt
abwärtskompatibel
LABEL spezifische Build-Kennzeichnung
#### SCM Sicherung für einzelne Entwickler
zentrale Verfügbarmachung
zusammen führen parallel geäderter Dateine
parallele Entwicklung verschiedener Features
Zugriff auf dedizierte Stände
branches
#### Build Prozess: Abhängigkeiten organisieren
Übersetzen
ausführung automatisierten Tests
Liefer Artefakte erzeugen
Deployment (das Lieferartefakt wird ausgegeben)
#### Tools: make (c~, gnu~)i/ceedling
vorwiegend C/C++
keine Abhängigkeitsverwaltung
maven/gradle
vorwiegend Java
npm
JS/TS
#### Integration: Wir haben Server das Integration übernimmt
SCM überwachen
Änderungen zusammenführen
build Prozess starten (befor Abhängigkeiten auflösen)
compilieren
Lieferartefakt erstellen
"""" ausliefern
Ergebnisse berichten ob es funftionnirete oder nicht
#### Probleme: kein menschlicher Eigriff
compilirbar != ausführbar
CI soll immer lieferbaren Stand bereit halten
Programm muss im CI Prozess ausgeführt werden
#### Automatisierte Tests: führen Programm aus
dokumentieren gewünschtes Vergalten
sind wiederholbar
erkennen Laufzeitfehler (außer Unittests)
Ausführungszeit von Atbeitszeit entkoppelt (da wo keiner arbeiten will)
#### Grenzen: finden nur Abweichungen von gewünschten/erwartetem Verhalten
"""""" keine neue fachlichen Fehler
#### Vorgehensmodelle: gemeinsame remote repository
privater fork
#### remote repository: alle arbeiten gegen RR
jeder hat Zugriff
einfache Synchronisation
gepushte Zwischenstände sind für alle sichtbar
#### privater fork: es gibt ein zentrales RR (= master)
jeder Entwickler hat ein separates RR (= fork)
jedes LR hat 2 RR
origin -> master, nur lesend
upstream -> privater fork, Schreiberechte
Änderungen werden per Pull Request aus dem fork in maser repository übernommen
### Erkenntnis
#### In der Praxisunterricht haben wir die erworbene Kenntnisse über remote repositories in das Praxis umgesetzt und Umgang damit trainiert.
### Wiederholung
#### Zur Wiederholung haben wir den Umgang mit local repositories geübt. Die nächste Aufgabe war so aufgebaut, dass es ohne vorkenntnisse über lokal repositories nicht möglich war, diese zu bewältigen.
### Kritik
#### keine
### Mitteilung an die Dozierenen
#### keine
