SWC - Eins

- Es gilt "nearest Definiton wins"
- es wird die Version verwendet, die am nächsten am Projekt (Root) ist

 

- Weil Software aus vielen Komponenten besteht, die zusammenarbeiten müssen
 

- Module müssen zusammen funktionieren -> Verschiedene Komponenten

Wenn sie:

- kompilliert
- run
- Tests laufen durch und sind pass
- Deployment erfolgreich

- Verschiedene Modelle
- Verschiedene Systeme
- Verschiedene Komponenten

- Beim merge/push ins Repo
- Bei besonders kritischen Schnittstellen

- Integration Server baut nicht erfolgreich
- Geteilte Komponenten funktionieren auf einem System, aber nicht auf einem anderen (Nicht Portable)
- Unit-Tests sind fehlgeschlagen
- Code- Qualität ist schlecht (Integrationtests schlagen fehl z.B. Checkstyle)
- Deployment schläft fehlt z.B. ssh kein Zugang

- Automatisierte Builds + Tests + Deployment
- Es ist ein triggered Event

- Alle arbeiten auf einer gemeinsamen Code-Basis
- Build läuft automatisch
- Tests laufen automatisch im Build
- Häufige Integration -> Weniger Konflikte (Konflikge früh erkennen)
- Jeder Commit triggert Build
- Keep the build fast
- Tests in Kopie von Prod Umgebung
- Artefakte/Executable einfach verfügbr machen
- Jeder kann sehen was gerade passiert (Pipeline)
- Deployment automatisieren
- Never commit a failing build
- Kein Code auf kaputten Stand

- Build Server
- Version Control Server
- Deployment Server
- Automation Build (Maven)
- CI-Tools
- Entwickler müssen -> Täglich Commiten, Code testen und Tests für den Code schreiben
 

1) Developer Pulled alles vom Repo oder (VCS)
2) Developer pushed /commited 
3) Event wird getriggered -> Build wird getriggered
4) Build Server macht checkout vom Repo und beginnt den Build
5) Reports etc werden erstellt -> Dev wird benachrichtigt

- Automatisches bauen, automaitsche Tests und schnelles Feedback/Dokumentation
- Kurze Iterationen, schnelle Anpassungen möglich

- Java Funktionen, Methoden
- Datenbankfunktionen
- Schnittstellen/Interfaces zu anderen Applications

- Man kann Fehler früh erkennen
- Es gibt weniger Bugs
- Bessere Qualität
- Besserer Status-Übersicht
- Weniger Aufwand
- Entdekct potenzielle Deployment Issues

Bild

Bild

- Führt zwei Lifecycle hintereinander aus
- Erst bereinigt er alle alten Artifakte, anschliessend kompiliert er
 

build-stage:
  stage: build
  script:
   -mvn clean compile

test-stage:
 stage: test
  script:
   -mvn verify checkstyle.check

- Nein, nur was im .yml definiert ist

SW-Engineering -> Ganzer Ablauf (Planung, Entwicklung, Wartung)
SWC -> Umsetzung (Coding, Debugging, testen, verbessern)
Programming -> Reines Coding

Reliability / Zuverlässigkeit (Wie gut funktioniert die Software?)
Mantainability / Wartbarkeit (Leicht änderbar)
Reusability (wiederverwendbar)
Usability (einfach zu nutzen)
Efficiency (schnell und Ressourcenschonend)
Testability (testbar)
Portablility (läuft überall)

Bild

Reliability / Zuverlässigkeit (Correctness + Robustheit)
- Es sollte einfach sein SW zu builden, die korrekt läuft
- Run and test the Software!

Resusability / Verwendbarkeit (Veränderbar und Erweiterbar)
- Man sollte weniger SW builden
- SW soll einfacher änderbar sein
- Redesign and improve the source code!

Usability (Funktionalität)
- Vergewissern, dass die SW macht, was der User möchte
- Build SW as early as possible and give it to the user

1) Kunde durch frühe und kontinuierliche Auslieferung wertvoller SW zufrieden stellen
2) Änderungen sind willkommen, auch spät im Projekt
2) Liefere funktionierende SW, innerhalb kurzer Zeiträume
3) Fachexperten und Entwickler müssen während des Projekts tägllich zusammenarbeiten
4) Motivierte Teams bringen Vertrauen und Unterstützung
5) Direkte Kommunikation -> Am besten face-to-face
6) Funktionierende SW -> Wichtiger Fortschrittmass
7) Nachhaltigkeit -> Gleichmössiges Tempo halten können
8) Technische Exzellenz und gutes Design im Augenmerk
9) Einfachheit -> Nur das nötigste bauen
10) Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams
11) Regelmässige Verbesserung -> reflektieren und anpassen

1) Commanded -> Manuell gestartet
2) Schedulded -> Run build bei vordefinierten Intervall oder Zeitangaben
3) Triggered -> Build als Resultat von einem Event (z.B. CI)

Es braucht
- Build Server
- VCS (Version Control Server)
- Klarer Prozess
- Developer Responsebility -> Code checked in before "End of the Day", Code must be buildable, Code must have and pass unit-testing

Sequenziell (z.B. Wasserfallmodell):
- Feste Reihenfolge
- Wenig Änderungen möglich
- Testing oft erst am Ende 
- Weniger Feedback

Iterativ (Agile): 
- Kleinere Schritte (Iterationen)
- Häufiges Testing und Integration
- Schnelle Anpassung bei Änderung
- Kontinuerliches Feedback

- Fehler früh erkennen
- Qualität sichern und verbessern
- Funktionalität und Zuverlässigkeit testen

- Unit-Tests
- Integrationtesting

- Unit-Tests
- Code Reviewing
- Refractoring
- Coding-Standard
- Continous-Integration
- Automatische Builds (Maven)

- Verwaltung von sich ständig ändernde Artefakte, wie Dokumente, Source-Code, oder Konfigurationsdateien
- Verfolgt das Ziel, dass jede Änderung eindeutig nachvollziehbar dokumentiert ist und jede Version eines Artefakts wiederhergestellt werden kann
- Verantwortlich für das Erstellen und Aufrechthalten der Integrität aller Artefakte eines SW-Projektes während des gesamten Life-Cycle

- Konfigurationsplanung
- Toolauswahl
- Release-Planung/Management
- Report des Konfigurationsstatus
- Change-Request Management
- Konfigurationskontrolle
- Konfigurations-Identifikation

- Alte Bugs tretten wieder auf
- Alte Releases können nicht mehr gebuilded werden
- Alte Releases können nicht gefunden werden
- Dateien gehen verloren
- Dateien sind plötzlich verändert (Integration nicht gewährleistet)
- Selber Code existiert in mehreren Projekten
- Zwei Devs änjdern gleiche Datei, ohne es zu merken

Alles was in einem Projekt entsteht, zum Beispiel:
- Source Code
- Dokumentationen/Reporting
- Ausführbare Dateien
- Konfigurations-Datei (yml)
- Build-Skript (pom.xml)

- Das ist ein Artefakt, welches unter Konfigurations- bzw. Versions-Management gestellt werden muss.
- Es muss dabei eindeutig identifizierbar sein und alte Versionen müssen abrufbar bleiben

- Version: Bestimmter Zustand eines Konfigurationselements mit klar definiertem Funktionsumfang
- Release: Eine veröffentlichte Version. Häufig wird ein Reale für Nutzer oder Kunden bereitgestellt
- Variante: Angepasste Form einer Version z.B. Anpassung für Tablets, Sehbehinderte, Hardware, OS etc

- Es werden mindestens 2 Nummern für die Identifikation Verwendet (Major und Minor)
1) Major -> Es muss mit Inkompatibilitäten zwischen Major-Versionen gerechnet werden (1.xx -> 2.xx)
2) Minor -> Änderungen dieser Nummer sind rückwärtskompatibel (1.3.x -> 1.4.x)
3) Patch -> Bug-Fixes, Änderungen sind vorwärts und rückwärtskompatibel (1.3.1 -> 1.3.2)
4) Build -> Nummer gibt eine Neukompilierung von Source-Code an, z.B. aufgrund von Prozessor-, Plattform- oder Compilierungänderungen
5) Revision -> Kleine Änderungen an einer Version, welche Fehler behebt, jedoch keinen Einfluss auf den Funktionsumfang hat
6) Variante -> Variante einer Version, welche entwickelt wurde, um z.B. auf einer anderen HW oder OS zu laufen