You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
3.2 KiB
3.2 KiB
Lerntagebuch für Programmiermethoden und -werkzeuge von Philipp Hartmann
SU5 23.11.2022
Lernziele (Was waren die wesentlichen Inhaltlichen Punkte der letzten Vorlesung - Stichpunktartig)
Kooperation im Softwareentwicklungsprozess
- Größe von Software-Projekten
- Zusammenführen der Einzelleistungen
- Vorteile von CI Systemen
Softwareentwicklungsprozess
Bestandteile
- Code schreiben
- Abhängigkeitenverwaltung
- Code veröffentlichen
- Integration
- build-Prozess -- compile (Programm erstellen) -- test (das Programm testen)
- Bereitstellung
Abhängigkeitenverwaltung
- nicht selbst im Build-Lauf erzeugt
- nicht im SCM eingecheckt
- zentrale Bereitstellung
- Zugriff auf einzelne Versionen
Semantische Versionierung
- MAJOR ist nicht rückwärtskompatibel
- MINOR ist rückwärtskompatibel
- PATCH Fehlerbehebungen & rückwärtskompatibel
- LABEL spezifische Kennzeichnung
Source Code Management System (SCM)
- Sicherung der eigenen Arbeit
- zentrale Verfügbarkeit
- Zusammenführung parallel geändeter Dateien (merge)
- parallele Entwicklung der featueres möglich
- Zugriff auf dedizierte Stände ( releases)
- Wechsel zwischen Entwicklungsständen (branches)
build - Prozess
- Übersetzen
- Abhängigkeiten organisieren
- Tests ausführen (können auch automatisiert sein)
- Liefer-Artefakte erzeugen
- Deployment (Zentral bereitstellen)
beliebte build-tools:
- make vorwiegend C/C++ keine Abhängigkeitsverwaltung
- maven / gradle vorwiegend Java
- npm vorwiegend Javascript / TypeScript
Integration
- SCM überwachen
- build- Prozess starten -- Abhängigkeiten auflösen -- compilieren -- automatisierte Tests ausführen -- Lieferartefakt erstellen
- Ergebnisse berichten
Rolle von automatisierten Tests
Problem des Continous Integration
- kein menschlicher Eingriff
- 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 welche teifgründiger sind(außer UnitTests)
- Ausführungszeit von Arbeitszeit entkoppeln
- automatisierte Tests sind erheblich schneller als "menschliche" Tests
Grenzen automatisierte Tests
- finden nur Abweichungen von gewünschten/bekannten Verhalten (findet nur das wonach der Entwicker sucht)
- finden keine neuen fachlichen Fehler
Vorgehensmodelle
gemeinsames remote repository
- alle Entwickler arbeiten ausschließlich gegen ein gemeinsames remote repository
- jeder Entwickler hat (Schreib-) Zugriff
- einfache Synchronisation
- (gepushte) Zwischenstände für alle direkt sichtbar
privater fork
- es gibt ein zentrales remote repository (=master)
- jeder Entwickler hat ein seperates remote repository (= fork)
- jedes locale repository hat 2 remote repositories -- origin --> master, nur lesend (dies nutzt man um syncrhon zu bleiben) -- upstream --> privater fork, Schreibrechte (dort kann ich meine Änderungen pushen)
Erkenntnis (Was kann ich für das Gruppenprojekt anwenden -2-3 Sätze)
build tools nutzen und automatisierte Tests einfügen