173 lines
5.1 KiB
Markdown
173 lines
5.1 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
|
||
- Komponenten / Module von anderen Teams innerhalb der Organisation
|
||
- 3rd Party Bibliotheken
|
||
|
||
#### Managing Components
|
||
- größere Projekte sollten in mehrere Komponenten zerlegt werden
|
||
- ggf. auch separate Pipelines zum builden
|
||
|
||
#### Managing External Libraries
|
||
- kommen meist in binärer Form
|
||
- am besten lokale Kopien in Versionen, welche funktionieren
|
||
- latest könnte bugs haben / die Anwendung kaputt machen
|
||
- trotzdem regelmäßig updaten!
|
||
|
||
### Software Configurations
|
||
- sollten gemanaged und getestet werden
|
||
- erlauben der Software mehr Flexibilität
|
||
- Wann?
|
||
- Während des buildens / packaging
|
||
- schlecht, dann ist das image nicht universell einsetzbar
|
||
- Deployment / Startup / Run Time
|
||
- egal wann – sie sollten immer über den gleichen Mechanismus geschehen
|
||
- bspw. Passwörter sollten nicht gehardcoded werden
|
||
|
||
### Environment Management
|
||
- Jede Software benötigt Hardware/Software/Infrastruktur/externe Systeme
|
||
- = Environment
|
||
- Sollte automatisiert laufen
|
||
- sollte einfacher sein einfach den kaputten wegzuwerfen und neu zu erstellen, als zu reparieren
|
||
|
||
## CI/CD
|
||
|
||
- Continuous Integration
|
||
- kein Dev will immer die gesamte Anwendung testen / laufen lassen
|
||
- CI übernimmt
|
||
- automatisierte Tests
|
||
- Bugs werden früher gefunden
|
||
- Continuous Delivery
|
||
- Erweiterung von CI um Release in Staging
|
||
- Continuous Deployment
|
||
- automatisches Deployment in Produktionsumgebung
|
||
|
||
### CI/CD Good Practices
|
||
- Wenn ein Fehler auftritt, ist es höchste Prio diesen zu fixen
|
||
- Vorher keine weiteren Änderungen pushen
|
||
- nicht nach Hause gehen, wenns nicht mehr geht
|
||
- entweder fixen oder rückgängig machen
|
||
- wer Änderungen macht ist auch verantwortlich
|
||
- Tests vorher lokal laufen lassen
|
||
- wenn welche fehlschlagen → nicht auskommentieren
|
||
- Pipeline nach dem pushen beobachten
|
||
- Pipeline stoppen lassen bei Fehlern
|
||
- fehlschlagende Tests
|
||
- langsame Tests
|
||
- hässlicher Codestyle
|
||
|
||
## Deployment Pipeline
|
||
|
||
|
||
- binarys so selten wie möglich erstellen
|
||
- dauert lange
|
||
- falls eine doppelt verwendet werden kann → doppelt nutzen
|
||
- bspw. Staging/Production
|
||
- Smoke-Testing vom Environment
|
||
- primitiv checken, ob Anwendung läuft und bspw. Startseite gewünschte Daten zeigt
|
||
- Staging-Umgebung nutzen für Acceptance Stage
|
||
- Alle Änderungen sollten durch die Pipeline gehen
|
||
- Falls irgendwas fehlschlägt → Pipeline stoppen
|
||
|
||
### Stages
|
||
#### Commit Stage
|
||
|
||
- Bestandteile:
|
||
- Code kompilieren
|
||
- Tests laufen lassen (Unit, Integration)
|
||
- Binaries erstellen
|
||
- statische Codeanalyse
|
||
- Falls Commit Stage funktioniert → Release Kandidaten erstellen
|
||
|
||
#### Acceptance Stage
|
||
|
||
- Bestandteile
|
||
- Service Testing
|
||
- Laufen in produktionsähnlicher Umgebung
|
||
|