@ -222,3 +222,54 @@ Git Branches entsprechen Zweigen, repräsentieren Zeitlinien von Code-Backups un
### Kritik
### Kritik
---
## SU 05 (28.11.2023)
### Lernziel
- Kooperation SCM
- Literatur (Buchempfehlung)
- Kooperation im Softwareentwicklungsprozess
- Größe von Software-Projekten
- Zusammenführen der Einzelleisungen
- Vorteile von CI Systemen
- Softwareentwicklungsprozess
- Bestandteile
- Abhängigkeitenverwaltung
- nicht selbst in Build-Lauf erzeugt
- nicht im SCM eingecheckt
- Zentrale Bereitstellung (Organisation)
- Zugriff auf einzelne Versionen
- Semantische Versionierung
- major - inkompatible Änderung
- minor - zusätzliche Features
- patch - Fehlerbehebung
- label - spezifische Build-Bezeichnung
- SCM
- build-Prozess
- Integration
- Rolle von automatisierten Tests
- Problem des Continous Integration
- Vorteile automatisierter Tests
- Grenzen automatisierter Tests
- Vorgehensmodelle
- gemeinsames remote repository
- privater fork
### Erkenntnis
Durch die semantische Versionierung kann ich dem Gruppenprojekt in Zukunft eine Version zuordnen und weiß welche Version man hat und ob diese aktuell ist. Die einzelnen Versionen unseres Projekts können wir so managen.
### Wiederholung
Bei der semantischen Versionierung werden Versionsnummern verwendet, um Änderungen in Softwareprojekten zu kennzeichnen. Im folgenden sind die Bedeutungen der verschiedenen Teile einer Versionsnummer:
```
1.0.0-beta1
```
**1** - erste Zahl: **Major**-Version. Wenn sie sich ändert bedeutet das, dass in der Software rückwärtsinkompatible Änderungen vorgenommen wurden.
**0** - zweite Zahl: **Minor**-Version. Wenn sie sich ändert, wurden neue Funktionen zur Software hinzugefügt, die abwärtskompatibel sind.
**0** - dritte Zahl: **Patch**-Version. Wenn sie sich ändert, wurden Fehlerbehebungen oder kleinere Verbesserungen vorgenommen, die keinen Einfluss auf die öffentliche Schnittstelle haben.
**beta1** - letze Zahl: optionales **Label**. Wird verwendet um spezifische Builds oder Vorabversionen der Software zu kennzeichnen.