Browse Source

Added Vorlesung 23.11

rated-lesson-2022-11-23__33
fakhrullah 2 years ago
parent
commit
214075dd4c
  1. 95
      lerntagebuch.md

95
lerntagebuch.md

@ -170,7 +170,102 @@ Rebase vs Merge:
Keep commits small and clean for easier problem solving and back tracking.
## Vorlesung (23.11)
### Lernziele
Vorteile von Continuous Delivery (CI):
1. automatisierte Prozesse verrigern Aufwand
2. formale Prozesse verringern Konfliktpotential
3. Vorstufe zu _Continuous Delivery_
Bestandteile von Softwareentwicklungsprozess:
1. Code schreiben
2. Abhängigkeitenverwaltung
3. Code veröffentlichen
4. Integration
5. build-Prozess: compile und test
6. Bereitstellung
Abhängigkeitenverwaltung:
1. nicht selbst im Build-Lauf erzeugt
2. nicht im SCM eingecheckt
3. zentrale Bereitstellung (innerhalb der Organisation)
4. Zugriff auf einzelne Versionen
Semantische Versionierung:
__1.2.3-beta1__
1- MAJOR - inkompatible Änderungen
2- MINOR - zusätzliche Features, Programmteil bleibt abwärtskompatibel
3- PATCH - Fehlerbehebungen, Programmteil bleibt abwärtskompatibel
beta1- LABEL - spezifische Build-Kennzeichung
Source Code Management (SCM):
1. Sicherung der Arbeit einzelner Entwickler
2. zentrale Verfügbarmachung
3. Zusammenführung parallel geänderter Dateien
4. parallele Entwicklung verschiedener Features ermöglichen
5. Zugriff auf dedizierte Stände (*releases*)
6. Wechsel zwischen Entwicklungsständen (`branches`)
build - Prozess:
1. Übersetzen
2. ängigkeiten organisieren
3. automatisierte Tests ausführen
4. Liefer-Artefakte erzeugen
5. Deployment
build-Prozess starten:
- Abhängigkeiten auflösen
- compilieren
- automatisierte Tests ausführen
- Lieferartefakt erstellen
- Lieferartefakt ausliefern
Integration:
1. SCM überwachen
2. build-Prozess starten
3. Ergebnisse berichteten
Problem des Continuous Ingegrations:
1. kein menschlicher Eingriff
2. compilierbar nicht bedeutet ausführbar
3. CI soll immer lieferbaren Stand bereit halten
4. Programm muss im CI Prozess ausgeführt werden
Vorteile automatisierter Tests:
1. automatisierte Tests führen Programm aus
2. dokumentieren gewünschtes Verhalten
3. sind wiederholbar
4. erkennen Laufzeitfehler (außer UnitTests)
5. Ausführungszeit von Arbeitszeit entkoppelt
gemeinsames _remote repository_
1. alle Entwickler arbeiten ausschließlich gegen ein gemeinsames _remote repository_
2. jeder Entwickler hat (Schreib-)Zugriff
3. einfache Synchonisation
4. (gepushte) Zwischenstände für alle direkt sichtbar
privater *fork*:
1. es gibt ein zentrales remote repository (= _master_)
2. jeder Entwickler hat ein separates remote repository (= _fork_)
3. jedes locale repository hat 2 _remote repositories_:
- `origin` - *master*, nur lesend
- `upstream` - privater *fork*, Schreibrechte
### Kritik
*forking* is a good practice for a large scale project, where a lot of people working on the same repository at the same time.
Loading…
Cancel
Save