89 lines
2.3 KiB
Markdown
89 lines
2.3 KiB
Markdown
# Continuous Development
|
|
## Configuration Management
|
|
### Version Control System (VCS)
|
|
- Erlauben mehrere Versionen von Dateien
|
|
- Falls etwas bearbeitet wurde, sieht man, wie es vorher aussah
|
|
- Erlaubt dem Team zusammenzuarbeiten
|
|
- auch wenn verteilt
|
|
|
|
#### Good Practices VC
|
|
- Absolut alles im VCS speichern
|
|
- Tests, Datenbankscripte, Buildscripte, Dokumentationen, etc.
|
|
- Alle Informationen, die benötigt werden, um irgendwelche Test- / Produktionsumgebungen wiederherzustellen
|
|
|
|
### VC - Release Versioning
|
|
- Jeder Release sollte eine eigene Nummer haben
|
|
|
|
#### Versionsschema
|
|
- SemVer (Semantic Versioning)
|
|
- **MAJOR**._Minor_.patch
|
|
- Major
|
|
- Bahnbrechende Änderungen (Hohes Risiko)
|
|
- inkompatible API Änderungen
|
|
- Entfernen von Features
|
|
- Änderungen am Datenbankschema, die Daten entfernen
|
|
- Minor Version
|
|
- Features (Mittleres Risiko)
|
|
- neues Feature
|
|
- UI ändern
|
|
- DB-Schema erweitern (keine Daten entfernen)
|
|
- patch version
|
|
- Alle anderen Änderungen (kaum Risiko)
|
|
- kleinere Bug-Fixes
|
|
- Zusätzliche Labels
|
|
- alpha
|
|
- beta
|
|
- bspw:
|
|
- _1.0.0-alpha.1_
|
|
- 
|
|
- 
|
|
|
|
|
|
### VC - Meaningful Commits
|
|
```Git
|
|
<type>[optional scope]: <description>
|
|
[optional body]
|
|
[optional footer(a)]
|
|
```
|
|
|
|
#### Commit Types
|
|
- chore
|
|
- bspw. Abhängigkeiten updaten
|
|
- refactor
|
|
- docs
|
|
- style
|
|
- Formatieren, fehlende Semikolons, ...
|
|
- test
|
|
- perf
|
|
- Performance Verbesserungen
|
|
- ci
|
|
- CI/CD related
|
|
- build
|
|
- Änderungen, die das Build-System oder externe Abhängigkeiten betreffen
|
|
- revert
|
|
- Rückgängig machen
|
|
|
|
|
|
### VC - Branching
|
|
- Vermeide lange Branches
|
|
- Überprüfe regelmäßig die Main-Line
|
|
|
|
### VC - Branching GitFlow
|
|
- 
|
|
- Development Branch (develop)
|
|
- master/main für produktionsfertigen Code
|
|
- develop für letzte Development Änderungen
|
|
- Feature Branch (feature/*)
|
|
- für neue Features
|
|
- existiert nur so lange, wie das Feature entwickelt wird
|
|
- Hotfix Branch (hotfix/*)
|
|
- Wie ein Release-Branch, aber für unerwartete, kurzfristige Releases
|
|
|
|
**Probleme:**
|
|
- Hotfix / Release Branch
|
|
- macht die Sache deutlich (teilweise unnötig) komplizierter
|
|
- Devs machen häufig Fehler
|
|
- direkt auf main mergen, ...
|
|
|
|
### Dependency Management
|
|
- |