zusammenfassungen/Writerside/topics/04/Software Engineering/03_ContinousDevelopment.md

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

<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