From 6068572a62888f007d35a1143b8e3e0afff19f95 Mon Sep 17 00:00:00 2001 From: fdai7437 Date: Sun, 3 Dec 2023 20:50:35 +0100 Subject: [PATCH] SU_05 --- Lerntagebuch.md | 115 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 115 insertions(+) diff --git a/Lerntagebuch.md b/Lerntagebuch.md index ab3179c..5b7c539 100644 --- a/Lerntagebuch.md +++ b/Lerntagebuch.md @@ -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