SWC - Eins
SWC - Erste Prüfung
SWC - Erste Prüfung
Was passiert, wenn mehrere Versionen einer Dependency existieren?
- Es gilt "nearest Definiton wins"
- es wird die Version verwendet, die am nächsten am Projekt (Root) ist
Wozu braucht man Continous Integration
- Weil Software aus vielen Komponenten besteht, die zusammenarbeiten müssen
Was versteht man unter Integration?
- Module müssen zusammen funktionieren -> Verschiedene Komponenten
Wann ist eine Integration erfolgreich?
Wenn sie:
- kompilliert
- run
- Tests laufen durch und sind pass
- Deployment erfolgreich
Was sind die grössten Probleme/Herausforderungen für Integration?
- Verschiedene Modelle
- Verschiedene Systeme
- Verschiedene Komponenten
Wann passiert Integration?
- Beim merge/push ins Repo
- Bei besonders kritischen Schnittstellen
Wann schlägt Integration fehl?
- 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
Was versteht man unter CI?
- Automatisierte Builds + Tests + Deployment
- Es ist ein triggered Event
Welche CI-Practices/Regeln gibt es?
- 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
Was sind die Voraussetzungen für Continous Integration?
- 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
Wie sieht das CI-Setup aus?
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
Warum ist Continous Integration wichtig für agile Projekte?
- Automatisches bauen, automaitsche Tests und schnelles Feedback/Dokumentation
- Kurze Iterationen, schnelle Anpassungen möglich
Was soll alles integriert und getestet werden?
- Java Funktionen, Methoden
- Datenbankfunktionen
- Schnittstellen/Interfaces zu anderen Applications
Was sind die Hauptvorteile von Continous Integration?
- Man kann Fehler früh erkennen
- Es gibt weniger Bugs
- Bessere Qualität
- Besserer Status-Übersicht
- Weniger Aufwand
- Entdekct potenzielle Deployment Issues
Was sidn die typischen Gitlab.yml Begriffe?
Bild
Wie sieht ein .gitlab-ci.yml Template aus?
Bild
Was macht mvn clean compile?
- Führt zwei Lifecycle hintereinander aus
- Erst bereinigt er alle alten Artifakte, anschliessend kompiliert er
Wie kann man System kompilieren (yml)?
build-stage:
stage: build
script:
-mvn clean compile
Wie geht Code-Analyse mittels Checkstyle (yml)?
test-stage:
stage: test
script:
-mvn verify checkstyle.check
Führt eine CI-Pipeline immer alle Phasen eines Maven-Skripts durch?
- Nein, nur was im .yml definiert ist
Was ist Software Construction?
Erstellung und Wartung von Software durch:
- Coding
- Debugging
- Unit-Testing
- Integration Testing
Was ist der Unterschied zwischen SWC, SW-Engineering und Programming?
SW-Engineering -> Ganzer Ablauf (Planung, Entwicklung, Wartung)
SWC -> Umsetzung (Coding, Debugging, testen, verbessern)
Programming -> Reines Coding
Was sind Qualitätsmerkmale einer Software?
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)
Wie ist der Aufbau einer Umgebung für SWC?
Bild
Was sind die Challenges von SW-Development?
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
Was sind die 12 agile Prinzipien?
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
Was sind die SWC-Aspekte aus dem SWEBOK?
Welche Art von Automationen gibt es?
1) Commanded -> Manuell gestartet
2) Schedulded -> Run build bei vordefinierten Intervall oder Zeitangaben
3) Triggered -> Build als Resultat von einem Event (z.B. CI)
Was sind die Vorraussetzungen für ein Automation-Build?
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
Welchen Einfluss hat das Vorgehen (Sequenziell vs. Iterativ) auf die Aktivitäten und Abläufe in der SWC?
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
Was sind die Hauptziele von Construction-Testing?
- Fehler früh erkennen
- Qualität sichern und verbessern
- Funktionalität und Zuverlässigkeit testen
Welche Arten von Tests gibt es?
- Unit-Tests
- Integrationtesting
Welche Massnahmen können auf Construction-Ebene angewendet werden, um die SW-Qualität zu prüfen/verbessern?
- Unit-Tests
- Code Reviewing
- Refractoring
- Coding-Standard
- Continous-Integration
- Automatische Builds (Maven)
Was versteht man unter SW-Versionsmanagement?
- 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
Was sind typische Aufgaben des SW-Konfigurationsmanagement?
- Konfigurationsplanung
- Toolauswahl
- Release-Planung/Management
- Report des Konfigurationsstatus
- Change-Request Management
- Konfigurationskontrolle
- Konfigurations-Identifikation
Was sind die Symptome eines schlechten Version Control Managements?
- 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
Was ist ein Artefakt?
Alles was in einem Projekt entsteht, zum Beispiel:
- Source Code
- Dokumentationen/Reporting
- Ausführbare Dateien
- Konfigurations-Datei (yml)
- Build-Skript (pom.xml)
Was ist ein Configuration Item (CI)?
- 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
Was ist der Unterschied von Version, Release und Variante?
- 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
Was sind die typischen Release- und Versionsidentifikationen?
- 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
-
- 1 / 106
-
Cartes-fiches
Was versteht man unter Merging?
- Zwei Enwicklungsverläufe werden zusammengeführt
- Branch erstellen "git branch xxx"
- Zu Branch wechseln "git checkout xxx"
- Branch erstellen und direkt wechseln "git checkout -b xxxx"
- Branch anzeigen "git branch"
- Branch löschen "git branch -d xxx"
- Branch pushen "git push -u origin xxx"
Wie ist der Ablauf beim Merging?
1) git checkout -b feature-login
2) git add *
3) git commit -m "Feature fertig"
4) git push -u origin feature-login
5) git checkout main
6) git merge feature-login
Was ist der Unterschied zwischen Reset und Restore?
Damit können:
- Änderungen, welche noch nicht commited sind, wieder rückgängig gemacht werden
- Ältere Versionen einer Datei wiederhergestellt werden
- Änderungen, die schon committed sind rückgängig machen
Mit "git log" wird Commit History angezeigt!
"git HEAD" zeigt wo man im Repo ist (Zeigt auf Commit)
Restore: Working Copy und Staging ändern
Reset: Index/Commit-Zeiger ändern
Revert: Neuer Commit wird erstellt
Wie kann man eine Datei aus einem alten Commit zurückholen?
- git restore -s <commit> file
Wie kann man das komplette Projekt zurücksetzen?
- git clone <url>
- git reset --hard <commit>
Wie kann man eine Datei aus dem Staging entfernen?
- git restore --staged file
Was sind Configuration-items?
Elemente eines Systems, das verwaltet, versioniert und nachverfolgt wird.
Welche Configuration Items werden im Git gespeichert und welche nicht?
Git: Build-Dateien(pom.xml), Source-Code, Test-Code, Dokumentation(readme.md), Dockerfile, CI-Config, DB-Schema, Ressourcen(.jpg)
Nicht im Git: Logs, Output, *.class, /target, Test-Report*.xml, Container, Binaries -> Artefakte
Was gehört unter Versionskontrolle und was nicht?
- Alles wo Arbeit drin steckt gehört in ein Repo
- Alles was generiert werden kann, soll nicht unter Versionsverwaltung gestellt werden
Was macht git restore -s <commit> liesmich.txt
- Nur diese eine Datei wird geändert, Rest vom Projekt bleibt gleich
Was macht git reset --hard <commit>?
Zeit zurückdrehen (Ganzer Zustand)
- Alles wird zurückgesetzt (Dateien + History)
Was macht git revert?
Macht einen alten Commit "rückgängig", aber sauber
- Neuer Undo-Commit wird erstellt
git reset 7 vs git reset --hard 7
git reset 7 = --mixed, standard:
HEAD geht zurück auf Commit 7, Staging Area wird angepasst, Working Directory bleibt unverändert
git reset --hard 7
HEAD geht zurück auf Commit 7, Staging Area wird angepasst, Working Directory wird auch überschrieben (f7)
Was bedeutet New file: test.txt in Staging Area?
- Datei befindet sich in der Staging Area (Staged/tracked)
Was ist der Unterschied zwischen Merge und Rebase?
- git merge (Fügt zwei Branches/Entwicklungsverläufe zusammen) -> Neuer Merge-Commit (F) entsteht
- git rebase (Verschiebt deinen Branch auf einen anderen) -> Keine Verzweigungen mehr
Was sind die Goldenen Regeln bezüglich Rebase?
- Rebase niemals auf öffentliche Branches (Main/Dev) oder gepushten Branches
Weil: die History verändert wird, andere haben plötzlich andere Commits
- Chaos beim Pullen
Was versteht man unter Interactive Rebase?
git rebase -i HEAD~3
- Man kann Commits zusammenfassen (squash)
- Commit Messages ändern
- Commits löschen
- Reihenfolge ändern
+ saubere Commit History
+ ideal vor dem Push
+ Perfekt für "aufräumen"
Welche Branching Workflows gibt es?
1) Trunk-based
2) Feature Branch Workflow
3) Gitflow
Was ist Trunk Based Development?
- Alle arbeiten hauptsächlich auf enem Hauptbranch (main oder trunk)
- Branches, wenn überhaupt sind nur sehr kurzlebig
__
Wie arbeitet man?
- Kleine Änderungen werden oft commited
- Häufig mergen
- Feature Flags statt langer Branches
Was sind die Vor- und Nachteile von Trunk Based Development?
Vorteile:
- Wenige Merge Konflikte
- Schnelle Integration
- Ideal für CI/CD
- immer lauffähiger Code
Nachteile:
- braucht gute Tests, sonst herrscht Chaos
- Disziplin im Team nötig
- grosse Features schwieriger zu isolieren
Was ist Feature-Branch Workflow?
- Für jedes Feature wird ein eigener Branch erstellt
- Danach wird das Feature in Main gemerged
Ablauf:
main → feature-branch → fertig → merge zurück
Was sind die Vorteile und Nachteile von Feature Branch Workflow?
Vorteile:
- Saubere Trennung von Features
- Paralleles Arbeiten möglich
- Weniger Risiko für main-branch
Nachteile:
- Merge-Konflikte möglich
- Branches können veralten
- Integration passiert später
Was ist Gitflow?
- Ein strukturierter Workflow mit mehreren Branches:
Main -> Stabile Releases
Develope -> Aktuelle Entwicklung
feature/* -> Neue Features
release /* -> Vorbereitung Release
hotfix/* -> schnelle Fixes
Was sind die Vor und Nachteile von Gitflow?
Vorteile:
- klare Struktur
- gut für Releases
- stabile Produktion
- gut für grosse Projekte
Nachteile:
- sehr komplex
- viele Branches -> Overhead
- langsamer Entwicklungsprozess
- schlecht fr CI/CD
Was sind Mergekonflikte und wann entstehen sie?
Mergekonflikt entsteht, wenn Git nicht automatisch entscheiden kann, welche Änderung richtig ist
-> Die gleiche Stelle in einer Datei wurde unterschiedlich verändert
-> Mergekonflikte entstehen bei git pull, merge oder rebase
Wie behebt man ein Mergekonflikt?
Mergekonflikt wird direkt erkannt -> Wechselt in Merge-Modus, es wird erwartet, dass der Mergekonflikt jetzt gelöst wird...
1) git status prüfen -> Beide modified
2) Datei öffnen
3) Umschreiben
4) Datei als gelöst melden "git add readme.md"
5) git commit readme.md "Mergekonflikt gelöst"
Was gehört alles in einen Build?
- Automatisches Kompilieren
- Automatisches Durchführen von Tests
- Auslieferbares Artefakt erstellen (JAR, WAR, EXE)
Welchen Umfang haben die meisten Builds?
- Artefakte von vorherigen Build bereinigen (clean)
- Auschecken aller erforderlichen Files aus einem Repo (checkout)
- Kompilieren aller Source-Files (Prod + Tests) (compile)
- Ausführen von Unit-Tests (JUnit) (test)
- Ausführen von einfachen Metrikmessungen (coverage)
- Generierung von API-Dokumentationen (javadoc:javadoc)
Was sind die Aufgaben von Maven?
- Automatisches Bauen
- Automatische Tests durchführen
- Wartung und Fehlerursache durch manuelles verringern
- Code Qualität verbessern
- Reporting/Dokumentation (z.B. Sites)
- Dependencies verwalten
Was sind die Grundprinzipien von Maven?
1) Convention over Configuration (CoC):
- Es muss wenig selbst konfiguriert werden, da viele Standardkonfigs vorgegeben sind
- Standardverhalten (Lifecycle) ist fix
2) Declarative Configuration:
- Es muss kein Code geschrieben werden, sondern man beschreibt was passieren soll (Ablauf)
3) Stabil und Konservativ:
- Maven ändert sich wenig und ist zuverlässig
- Grosse Plugins Community
Welche Lifecycles gibt es?
1) Default
2) Clean //Löscht target/
3) Site //Zuständig für Dokumente/Reporting etc
Welche Phasen gibt es im Default Lifecycle?
1) validation -> Prüft, ob alle notwendigen Ressourcen vorhanden sind
2) compile -> Kompiliert den Source-Code (in src/main/java und src/test/java) und erstellt .*class in target/classes
3) test -> Führt Unit-Tests durch -> (src/test/java) -> Reporting in target/surefire-reports
4) package -> Erstellt ausführbares File (Artefakt) -> JAR/WAR/EXE in target/*.jar
5) verifiy -> Führt zusätzliche Checks aus (Integrationstest, Checklist etc).
6) install -> Installiert lokale Artefake ins lokale Repo -> ~/.m2/repository
7) deploy -> Veröffentlicht Artefakte in Remote-Repo
Welche Phasen hat der Clean LifeCycle?
- pre-clean (Aktionen vor dem löschen)
- clean (Löscht target /Build-Ordner)
- post-clean (Aktionen nach dem löschen)
Welche Phasen hat der site Lifecylce?
- pre-site (Vorbereitung der Dokumentation)
- site (erstellt Projekt Website) -> HTML in target/site/*
- post-site (Nachbearbeitung)
- deploy-site (Veröffentlicht Website)
Was sind Artefakte und welche gibt es?
Alle erzeugden Ergebnisse eines Build-Prozeses:
1) .class (HauptCode) -> Phase compile -> target/classes/
2) .class (TestCode) -> Phase test-compile -> target/test-classes/
4) Test-Report/xml/txt -> Phase test -> target/surefire-reports/
5) .jar / .war / .exe -> Phase package -> target/*
6) Zusätzliche Reports -> Phase verify -> target/*
7) .jar + .pom -> Phase install -> ~/.m2/repository
8) .jar + .pom -> Phase deploy -> Remote-Repo
Welche Dependency-Scopes gibt es? //Wann ist die Dependency verfügbar?
- compile (default) -> überall verfügbar und im Artefakt enthalten
- provided -> Wird zur Laufzeit von der Umgebung bereitgestellt
- runtime -> Wird zur Laufzeit benötigt, nicht beim kompilieren
- test -> Nur für Tests verfügbar
- system -> Wie provided, aber lokal
- import -> Importiert BOMs in dependency management
Welche wichtigen Maven Plugins gibt es?
1) Maven Compiler Plugiin -> Kompiliert Java-Code
2) Maven surefire Plugin -> Führt Unit-Tests aus
3) Maven jar Plugin -> Erstellt jar-Datei <artifactId>_<version>*.jar
4) Maven clean Plugin -> Löscht Build Artefakte
5) Maven site Plugin -> Erstellt Website/Reporting
6) Maven install Plugin -> Installiert Artefakte Lokal ~/.m2/repository
7) Maven deploy Plugin -> Pusht Artefakte in Remote-Repo
Welche wichtige Maven Goals gibt es? plugin:goal
plugin:goal
1) compiler:compile -> Kompiliert Hauptcode /src/main/java
2) compiler:test-compile -> Kompiliert TestCode /src/test/java
3) surefire:test -> Führt Unit-Tests aus
4) jar:jar -> Erstellt eine Jar-Datei
5) clean:clean -> Löscht target/ Ordner
6) install:install -> Installiert Artefakte Lokal in ~/m2.repository
7) deploy:deploy -> lädt Artefakte in das Remote-Repo
8) site:site -> Erstellt Reports
9) javadoc:javadoc -> Erstellt HTML-Dok in /target/site/apidocs
Wofür steht Crisp?
C - Complete (Build enthält alles was nötig ist, alle Dependencies definiert)
R - Repeatable (Build ist immer gleich reproduzierbar) - gleicher Input = gleicher Output, Version Control = Zeitmaschine
I - Informative (Build liefert nützliche Infos) - Logs, Reports etc (Hilft beiim Debuggen)
S - Schedulable (Build läuft automatisiert) - CI/CD, jederzeit ausführbar
P - Portable (Build läuft überall gleich) - unabhängig von Umgebung
Wie ist die Maven Standard-Ordner Struktur aufgebaut?
Bild
