# 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_
- ![image_843.png](image_843.png)
- ![image_844.png](image_844.png)


### 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
- ![image_845.png](image_845.png)
- 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
![image_859.png](image_859.png)
- 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
![image_860.png](image_860.png)

- 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
![image_861.png](image_861.png)
- Bestandteile:
  - Code kompilieren
  - Tests laufen lassen (Unit, Integration)
  - Binaries erstellen
  - statische Codeanalyse
- Falls Commit Stage funktioniert → Release Kandidaten erstellen

#### Acceptance Stage
![image_862.png](image_862.png)
- Bestandteile
  - Service Testing
  - Laufen in produktionsähnlicher Umgebung