1 Release Management

Informieren Sie sich über “Semantic Versioning” https://semver.org/lang/de/.

(a) Welche Vorteile bietet “Semantic Versioning”?

Mit Semantic Versioning ist immer direkt klar, wie schwerwiegend die changes im Update waren. Ob es nur kleine Bugfixes (PATCHES) waren und die akutelle MAJOR Version noch funktionstüchtig ist, ob es ein MINOR change war welcher neue Funktionalitäten hinzufügt ohne die Funktionalität zu beeinträchtigen oder ob es ein MAJOR change war, der nicht rückwärtskompatibel ist und gegebenenfalls ein update erfordert um die Funktionalität zu gewährleisten

(b) Was ist der Unterschied zwischen “Major”, “Minor” und “Patch”?

SemVer.org

MAJOR wird erhöht, wenn API-inkompatible Änderungen veröffentlicht werden,

MINOR wird erhöht, wenn neue Funktionalitäten, die kompatibel zur bisherigen API sind, veröffentlicht werden, und

PATCH wird erhöht, wenn die Änderungen ausschließlich API-kompatible Bugfixes umfassen.

(c) Sie haben ihr Projekt mit einer externen Bibliothek entwickelt. Die Bibliothek hat die Version 1.2.3. Welche Versionen der Bibliothek können Sie in Ihrem Projekt verwenden, ohne Einschränkungen zu befürchten?

i) 1.2.4 $✓$

ii) 1.3.0 $✓$

iii) 2.0.0 $\times$

iv) 1.1.0 $\times$

v) 1.2.2 $\times$

2 Integrationsstrategien

Bei der Entwicklung eingebetteter Systeme entsteht oft das Problem, dass die Hardware, auf der ein Softwareprodukt laufen soll, sich selbst noch in der Entwicklung befindet. Um trotzdem frühzeitig mit der Entwicklung beginnen zu können, wird meist gegen ein ausführbares Modell der Hardware entwickelt. Das heißt, die Ausführungsumgebung der Software wird simuliert, um die inkrementell entwickelte Software gegen die simulierte Ausführungsumgebung zu testen. Man spricht dabei von “Software-in-the-loop”-Tests (SIL), weil die Software als reale Implementierung in der “Simulationsschleife” ausgeführt wird.

In den folgenden Schritten kann dann das simulierte Hardware-Modell ebenfalls durch eine reale Implementierung ersetzt werden (“Hardware-in-the-loop”, HIL).

Welcher Integrationsstrategie entspricht dieses Vorgehen?

Die Software wird schrittweise entwickelt und gegen eine simulierte Hardwareumgebung (SIL) getestet, bevor diese durch die reale Hardware (HIL) ersetzt wird. Dieses Vorgehen entspricht der inkrementellen Integrationsstrategie, da es eine stufenweise Integration und Validierung ermöglicht.

3 Diskussion: CI-Strategien

Erklären Sie kurz die folgenden Begriffe:

1. Regressionstest

Wiederholtes testen von Testfällen, um sicherzustellen, dass Modifikationen in bereits getesteten Teilen der Software keine neuen Fehler (“Regressionen”) verursachen

2. Nightly Build

In der Nacht wo idealerweise kein Entwickler mehr an der Codebase arbeitet, wird der Sourcecode vom Tag kompiliert. Es ist ein “automated build” welcher ggf. auch automatisiert CI/CD Pipieline tests ausgeführt

Ihnen wird vorgeschlagen die Regressionstests einmal pro Nacht, nach dem Nightly Build, auszuführen.

Sehen Sie mögliche Nachteile einer solchen Strategie für die kontinuierliche Integration?

Es könnte zur Folge haben, dass Entwickler sich nur auf das Testen der Nightly Builds verlassen und dementsprechend ihren eigenen Code nicht mehr testen und Fehler und Edge-Cases dementsprechend sehr spät oder eventuell garnicht mehr gefunden werden. Wenn erst in der Nacht getestet wird mit dem kompletten Quellcode, kann es sein, dass verschiedene ungetestete Komponenten Fehler schmeissen, und es unklar ist woher der Fehler jetzt genau herkommt

Können Sie sich eine andere Strategie vorstellen, die mögliche Nachteile umgeht?

Jede Komponente vor ihrem merge in den main branch testen und mit Pipelines checken ob alle Bedingungen etc erfüllt werden mit eventuell sogar code coverage. Der nightly Build sollte dann nurnoch checken ob die jeweiligen Schnittstellen der jewiligen Komponenten fehlerfrei funktionieren oder nicht

4 Praxis: Softwareprojekt-Setup und Integration

Hab das geskipped hab schon genug CI/CD

In dieser Aufgabe sollen Sie ein Projekt mit bekannten Tools aufsetzen. Dafür müssen Sie gegebenenfalls recherchieren, wie Sie diese Tools (zusammen) verwenden. Anschließend sollen Sie ein neues Modul in die Software integrieren. Der Source-Code ist aus der bekannten Klasse Navigation.java, aber auf mehrere Klassen aufgeteilt. Geben Sie für dieses Blatt ein Zip-Paket mit Ihrem finalen Projekt (inklusive Tests) ab.

Erstellen Sie ein privates Repository auf GitLab.com.
Clonen Sie das Repository lokal.
Erstellen Sie ein neues Gradle-Projekt (Typ “application”, Sprache Java, Keine Subprojekte, mit JUnit) in dem lokalen Repository. Eventuell müssen Sie Gradle zuvor installieren.
Installieren Sie nun (als Gradle-Plugins):
- Checkstyle (mit Google Style-Guide)
- Spotbugs
- Error-Prone
- Google-Java-Format
Kopieren Sie nun die Dateien unter source_files in Ihr Projekt (in das Verzeichnis, in dem schon die generierte Datei App.java liegt). Existierende generierte Dateien können Sie ersetzen. Eventuell müssen Sie die Packages der Klassen anpassen.
Führen Sie die Code-Analyse-Tools aus (z. B. mit ./gradlew check) und verbessern Sie gegebenenfalls den Code bis es keine Fehlermeldungen mehr gibt.
Setzen Sie eine CI-Pipeline in GitLab auf. Verwenden Sie dafür einen shared runner. Die Pipeline sollte folgende Schritte enthalten:
(a) Build (ohne checks)

(b) statische Checks

(c) Tests

Hinweis: Eine erste Anleitung finden Sie z.B. hier: https://docs.gitlab.com/ee/ci/quick_start/

Pushen Sie Ihre bisherigen Änderungen und stellen Sie sicher, dass die CI-Pipeline funktioniert wie erwartet.
Erstellen Sie jetzt einen neuen Branch auf dem Sie den Shortest-Paths Algorithmus hinzufügen. Die Implementierung dafür finden Sie in algorithm. Kopieren Sie die Klasse in das entsprechende Verzeichnis. Passen Sie auch den Code in App.java an, sodass die neue Klasse verwendet wird. Pushen Sie die Änderungen.
Mergen Sie den Branch anschließend zurück in main.

K Softwareintegration

(a) Sehen sie sich den folgenden Code an, der eine Gitlab CI erstellt.

image: openjdk:21
stages:
  - build
  - test
 
build:
  stage: build
  script:
    - ./gradlew build
 
test:
  stage: test
  script:
    - ./gradlew test

i) Was passiert wenn der build fehlschlägt?

Test wird nicht durchgeführt und der Run in der Gitlab CI schlägt fehl.

ii) Was passiert wenn der test fehlschlägt?

Wird in der CI als nicht bestanden angeszeigt

iii) Erweitern sie die Pipeline um einen `lint` Job, der Checkstyle ausführt. Dieser soll ausgeführt werden, wenn das Projekt erfolgreich gebaut werden konnte. Also Kommando für Checkstyle dürfen Sie `./gradlew check` annehmen.

image: openjdk:21
stages:
  - build
  - lint
  - test
 
 
build:
  stage: build
  script:
    - ./gradlew build
 
lint:
	stage: lint
	script:
	 - ./gradlew check
 
test:
  stage: test
  script:
    - ./gradlew test

(b) Geben Sie für die folgenden Aussagen an, ob Sie wahr oder falsch sind:

Ein Erstellungssystem sollte wenn möglich alle Quelldateien neu kompilieren, da sich wichtige Abhängigkeiten ändern könnten.

Wahr

Ein Erstellungssystem benötigt während der Systemerstellung nur die Quelldateien.

Falsch, könnte gegebenfalls imports aus Libraries benötigen

Wenn möglich, sollte ein Erstellungssystem auch Tests durchführen.

Wahr

Die Erstellung eines (größeren) Systems sollte immer automatisiert werden.

Wahr, bei größeren Systemen sollten manche Sachen wie Tests automatisiert erledigt werden

Das Erstellungssystem sollte mit dem Versionsverwaltungssystem gekoppelt sein.

Wahr, idealerweise ja

🎓 MyUniNotes

Explorer

SWT - Blatt 10

1 Release Management

(a) Welche Vorteile bietet “Semantic Versioning”?

(b) Was ist der Unterschied zwischen “Major”, “Minor” und “Patch”?

(c) Sie haben ihr Projekt mit einer externen Bibliothek entwickelt. Die Bibliothek hat die Version 1.2.3. Welche Versionen der Bibliothek können Sie in Ihrem Projekt verwenden, ohne Einschränkungen zu befürchten?

i) 1.2.4 $✓$

ii) 1.3.0 $✓$

iii) 2.0.0 $\times$

iv) 1.1.0 $\times$

v) 1.2.2 $\times$

2 Integrationsstrategien

Welcher Integrationsstrategie entspricht dieses Vorgehen?

3 Diskussion: CI-Strategien

1. Regressionstest

2. Nightly Build

Ihnen wird vorgeschlagen die Regressionstests einmal pro Nacht, nach dem Nightly Build, auszuführen.

Sehen Sie mögliche Nachteile einer solchen Strategie für die kontinuierliche Integration?

Können Sie sich eine andere Strategie vorstellen, die mögliche Nachteile umgeht?

4 Praxis: Softwareprojekt-Setup und Integration

(a) Build (ohne checks)

(b) statische Checks

(c) Tests

K Softwareintegration

(a) Sehen sie sich den folgenden Code an, der eine Gitlab CI erstellt.

i) Was passiert wenn der build fehlschlägt?

ii) Was passiert wenn der test fehlschlägt?

iii) Erweitern sie die Pipeline um einen `lint` Job, der Checkstyle ausführt. Dieser soll ausgeführt werden, wenn das Projekt erfolgreich gebaut werden konnte. Also Kommando für Checkstyle dürfen Sie `./gradlew check` annehmen.

(b) Geben Sie für die folgenden Aussagen an, ob Sie wahr oder falsch sind:

Ein Erstellungssystem sollte wenn möglich alle Quelldateien neu kompilieren, da sich wichtige Abhängigkeiten ändern könnten.

Ein Erstellungssystem benötigt während der Systemerstellung nur die Quelldateien.

Wenn möglich, sollte ein Erstellungssystem auch Tests durchführen.

Die Erstellung eines (größeren) Systems sollte immer automatisiert werden.

Das Erstellungssystem sollte mit dem Versionsverwaltungssystem gekoppelt sein.

Graph View

Table of Contents

Backlinks

🎓 MyUniNotes

Explorer

SWT - Blatt 10

1 Release Management

(a) Welche Vorteile bietet “Semantic Versioning”?

(b) Was ist der Unterschied zwischen “Major”, “Minor” und “Patch”?

(c) Sie haben ihr Projekt mit einer externen Bibliothek entwickelt. Die Bibliothek hat die Version 1.2.3. Welche Versionen der Bibliothek können Sie in Ihrem Projekt verwenden, ohne Einschränkungen zu befürchten?

i) 1.2.4 ✓

ii) 1.3.0 ✓

iii) 2.0.0 ×

iv) 1.1.0 ×

v) 1.2.2 ×

2 Integrationsstrategien

Welcher Integrationsstrategie entspricht dieses Vorgehen?

3 Diskussion: CI-Strategien

1. Regressionstest

2. Nightly Build

Ihnen wird vorgeschlagen die Regressionstests einmal pro Nacht, nach dem Nightly Build, auszuführen.

Sehen Sie mögliche Nachteile einer solchen Strategie für die kontinuierliche Integration?

Können Sie sich eine andere Strategie vorstellen, die mögliche Nachteile umgeht?

4 Praxis: Softwareprojekt-Setup und Integration

(a) Build (ohne checks)

(b) statische Checks

(c) Tests

K Softwareintegration

(a) Sehen sie sich den folgenden Code an, der eine Gitlab CI erstellt.

i) Was passiert wenn der build fehlschlägt?

ii) Was passiert wenn der test fehlschlägt?

iii) Erweitern sie die Pipeline um einen lint Job, der Checkstyle ausführt. Dieser soll ausgeführt werden, wenn das Projekt erfolgreich gebaut werden konnte. Also Kommando für Checkstyle dürfen Sie ./gradlew check annehmen.

(b) Geben Sie für die folgenden Aussagen an, ob Sie wahr oder falsch sind:

Ein Erstellungssystem sollte wenn möglich alle Quelldateien neu kompilieren, da sich wichtige Abhängigkeiten ändern könnten.

Ein Erstellungssystem benötigt während der Systemerstellung nur die Quelldateien.

Wenn möglich, sollte ein Erstellungssystem auch Tests durchführen.

Die Erstellung eines (größeren) Systems sollte immer automatisiert werden.

Das Erstellungssystem sollte mit dem Versionsverwaltungssystem gekoppelt sein.

Graph View

Table of Contents

Backlinks

i) 1.2.4 $✓$

ii) 1.3.0 $✓$

iii) 2.0.0 $\times$

iv) 1.1.0 $\times$

v) 1.2.2 $\times$

iii) Erweitern sie die Pipeline um einen `lint` Job, der Checkstyle ausführt. Dieser soll ausgeführt werden, wenn das Projekt erfolgreich gebaut werden konnte. Also Kommando für Checkstyle dürfen Sie `./gradlew check` annehmen.