Build-Prozesse

In dieser Lerneinheit verstehst du die fundamentale Rolle von Build-Prozessen in der Softwareentwicklung und lernst ihre wichtigsten Aufgaben kennen. Du erfährst, wie Build-Prozesse aus Quellcode lauffähige Software erzeugen und welche Schritte dabei durchlaufen werden. Diese Grundlagen sind essentiell für deine tägliche Entwicklungsarbeit und die Implementierung automatisierter Build-Pipelines.

Einführung

Ein Entwickler committed Code – 20 Minuten später schlägt der Build fehl. Eine Bibliothek fehlt, die bei ihr lokal funktioniert hat. Ein anderer Entwickler kann das Projekt nicht einmal starten, weil eine andere Version von Node.js installiert ist.

Ohne Build-Prozess hat jeder Entwickler andere Probleme – mit Build-Prozess erhalten alle identische Ergebnisse. — Bildrechte: Ausbildung-in-der-IT.de (KI-unterstützt)

Wie stellen wir sicher, dass Software auf jedem Rechner identisch gebaut wird – unabhängig vom Betriebssystem, installierten Tools oder lokalen Konfigurationen?

Die Antwort: Build-Prozesse. Sie automatisieren die gesamte Transformation von Quellcode in lauffähige Software und garantieren Reproduzierbarkeit durch klare Regeln, standardisierte Tools und automatisiertes Dependency Management.

Lernziele

Nach dieser Lerneinheit kannst du:

• Build-Prozesse als automatisierte Transformation von Quellcode in lauffähige Software erklären.
• Die wichtigsten Build-Tools (Maven, npm, MSBuild) unterscheiden und ihre Einsatzgebiete benennen.
• Build-Skripte lesen und deren grundlegende Struktur verstehen.
• Abhängigkeitsmanagement als Kernkomponente des Build-Prozesses beschreiben.

Überleitung

Schauen wir uns zunächst an, was ein Build-Prozess überhaupt ist und welche zentralen Ziele er verfolgt.

Danach lernst du die wichtigsten Build-Tools kennen, die heute in der Praxis eingesetzt werden.

Was ist ein Build-Prozess?

Ein Build-Prozess ist die automatisierte Transformation von Quellcode in ausführbare Software oder andere verteilbare Artefakte.

Ohne Build-Prozess müsstest du manuell:

• Dateien kompilieren
• Abhängigkeiten herunterladen
• Tests ausführen
• Artefakte paketieren

Mit Build-Prozess übernimmt ein Tool diese Schritte automatisch. Ein einziger Befehl (z.B. mvn package oder gradle build) erstellt die gesamte Anwendung reproduzierbar.

Kernaussage: Build-Prozesse garantieren, dass Software konsistent und unabhängig von der Entwicklungsumgebung erstellt werden kann.

Das ist essentiell in Teams: Wenn zehn Entwickler an einem Projekt arbeiten, muss jeder denselben Build-Befehl ausführen können, mit demselben Ergebnis.

Die sieben Hauptziele von Build-Prozessen

Build-Prozesse verfolgen sieben zentrale Ziele, die modernen Software-Entwicklung ermöglichen:

Ziel	Beschreibung	Nutzen
Automatisierung	Kompilierung, Testing und Paketierung laufen ohne manuelle Eingriffe	Zeitersparnis, weniger Fehler
Konsistenz	Jeder Build erzeugt identische Artefakte, unabhängig von Ort und Zeit	”Works on my machine”-Problem gelöst
Test-Integration	Unit Tests, Integration Tests laufen automatisch bei jedem Build	Frühe Fehlererkennung
Schnelle Rückmeldung	Entwickler erhalten in Minuten Feedback zu ihrem Code	Kürzere Entwicklungszyklen
Dependency Management	Externe Bibliotheken werden automatisch in korrekten Versionen geladen	Versionskonflikte vermieden
Multi-Environment	Unterschiedliche Builds für Dev, Test, Production möglich	Umgebungsspezifische Konfiguration
Versionskontrolle	Builds werden automatisch versioniert und archiviert	Jederzeit Zugriff auf spezifische Versionen

Diese Ziele machen Build-Prozesse zur Grundlage für Continuous Integration und DevOps.

Build-Tools im Überblick

Es gibt zahlreiche Build-Tools für verschiedene Technologie-Stacks. Hier eine Übersicht der wichtigsten Tools:

Tool	Sprache/Stack	Einführung	Status	Hauptmerkmal
Make	C/C++	1970er	Legacy	Regelbasiert, detaillierte Kontrolle
Ant	Java	2000	Legacy	XML-basiert, ersetzt durch Maven/Gradle
Maven	Java	2004	Modern	Convention-over-Configuration
Gradle	Multi-Language	2012	Modern	Flexibel + Konventionen, Groovy DSL
npm/Yarn	JavaScript/TypeScript	2010/2016	Modern	Node.js Ökosystem
MSBuild	.NET	2003	Modern	Visual Studio Integration

Legacy vs. Modern:

• Make und Ant sind Legacy-Tools, die in alten C/C++ bzw. Java-Projekten zu finden sind
• Maven und Gradle dominieren moderne Java-Entwicklung
• npm ist Standard für JavaScript/TypeScript
• MSBuild für .NET-Projekte (C#, F#)

Faustregel: Für neue Projekte nutze moderne Tools (Maven, Gradle, npm, MSBuild). Legacy-Tools sind primär für Wartung alter Codebases relevant.

Was sind Build-Tools?

Ein Build-Tool ist ein Programm, das den Build-Prozess automatisch ausführt. Anstatt dass du manuell jeden Schritt durchführst (Dateien kompilieren, Bibliotheken laden, Tests ausführen, Artefakte erstellen), übernimmt das Build-Tool diese Aufgaben für dich.

Warum gibt es Build-Tools?

In den Anfängen der Softwareentwicklung mussten Entwickler alle Build-Schritte manuell ausführen. Bei kleinen Projekten funktionierte das – bei größeren Projekten mit hunderten Dateien und Dutzenden Abhängigkeiten wurde es schnell fehleranfällig und zeitaufwendig.

Build-Tools lösen dieses Problem durch Automatisierung und Standardisierung:

• Ein Befehl genügt: mvn package, npm run build oder dotnet build erstellt die komplette Anwendung
• Dependency Management: Externe Bibliotheken werden automatisch in den richtigen Versionen geladen
• Reproduzierbarkeit: Jeder Entwickler erhält denselben Build mit denselben Abhängigkeiten
• Integration in CI/CD: Automatisierte Builds können in Deployment-Pipelines integriert werden

Typische Aufgaben eines Build-Tools:

• Quellcode kompilieren (z.B. TypeScript → JavaScript, Java → Bytecode)
• Abhängigkeiten herunterladen und verwalten
• Tests ausführen (Unit Tests, Integration Tests)
• Code-Qualität prüfen (Linting, Formatting)
• Artefakte paketieren (JAR, WAR, npm Package)
• Deployment vorbereiten

Maven: Einführung

Maven ist ein Build-Tool speziell für Java-Projekte und folgt dem Prinzip Convention-over-Configuration.

Was bedeutet Convention-over-Configuration?

Anstatt dass du jeden Aspekt des Builds manuell konfigurierst (wo liegen die Quelldateien, wo sollen kompilierte Dateien hin, wie heißt das fertige Artefakt), definiert Maven sinnvolle Standard-Konventionen:

• Quellcode liegt immer in src/main/java
• Test-Code liegt immer in src/test/java
• Kompilierte Dateien landen in target/
• Das Artefakt heißt {artifactId}-{version}.jar

Warum gibt es Maven?

Vor Maven mussten Java-Projekte mit Ant (einem älteren Build-Tool) jeden Build-Schritt manuell in XML konfigurieren. Das führte zu hunderten Zeilen Konfiguration selbst für einfache Projekte. Maven wurde entwickelt, um diesen Aufwand drastisch zu reduzieren: Folge den Konventionen, dann brauchst du kaum Konfiguration.

Maven: Die pom.xml Datei

Die pom.xml (Project Object Model) ist die zentrale Konfigurationsdatei für Maven-Projekte. Sie beschreibt dein Projekt minimal:

<project xmlns="http://maven.apache.org/POM/4.0.0">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.beispiel</groupId>
    <artifactId>mein-projekt</artifactId>
    <version>1.0-SNAPSHOT</version>
</project>

Was bedeuten diese Felder?

• <groupId>: Identifiziert deine Organisation oder Gruppe (z.B. com.beispiel, oft deine Domain rückwärts)
• <artifactId>: Name deines Projekts (z.B. mein-projekt)
• <version>: Aktuelle Version (z.B. 1.0-SNAPSHOT für Entwicklungsversion)

Diese drei Werte zusammen bilden die Maven-Koordinaten - sie identifizieren dein Projekt eindeutig.

Zweck der pom.xml:

• Projektbeschreibung: Was ist dieses Projekt?
• Dependency Management: Welche externen Bibliotheken werden benötigt?
• Build-Lifecycle: Wie soll das Projekt gebaut werden?

Mit nur diesen Angaben kann Maven bereits dein Projekt kompilieren - dank der Konventionen.

Maven: Dependencies verwalten

Maven verwaltet externe Bibliotheken automatisch über den <dependencies> Abschnitt in der pom.xml:

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>6.2.0</version>
    </dependency>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>5.11.3</version>
        <scope>test</scope>
    </dependency>
</dependencies>

Wie funktioniert das?

1. Du definierst die Bibliothek mit ihren Koordinaten (groupId, artifactId, version)
2. Maven lädt die Bibliothek automatisch von Maven Central (zentrales Repository mit Millionen Bibliotheken)
3. Die Bibliothek wird in deinem lokalen .m2/repository Ordner gespeichert
4. Maven bindet die Bibliothek beim Build automatisch ein

Was bedeutet <scope>test</scope>?

Der Scope definiert, wann die Bibliothek verfügbar ist:

• Kein Scope (default): Bibliothek wird überall verwendet (Kompilierung, Tests, Runtime)
• <scope>test</scope>: Nur für Tests verfügbar (z.B. JUnit)
• <scope>provided</scope>: Wird von der Laufzeitumgebung bereitgestellt (z.B. Servlet-API vom Application Server)

Ein Befehl genügt: mvn package kompiliert den Code, führt Tests aus und erstellt ein JAR-Artefakt - inklusive aller Dependencies.

npm: Einführung

npm (Node Package Manager) ist das Standard-Build-Tool für JavaScript und TypeScript-Projekte im Node.js-Ökosystem.

Warum npm?

JavaScript-Entwicklung war lange Zeit chaotisch: Jedes Projekt hatte seine eigene Struktur, Bibliotheken mussten manuell heruntergeladen und eingebunden werden. npm standardisierte diesen Prozess und wurde zum de-facto Standard für JavaScript/TypeScript.

Zweck von npm:

• Dependency Management: Automatisches Laden von Bibliotheken aus der npm Registry (über 2 Millionen Pakete)
• Build-Automation: Ausführung von Scripts für Kompilierung, Testing, Deployment
• Versionskontrolle: Lockfiles (package-lock.json) garantieren reproduzierbare Builds

npm: Die package.json

Die package.json ist das Äquivalent zur pom.xml bei Maven. Sie definiert dein Projekt:

{
  "name": "mein-projekt",
  "version": "1.0.0",
  "scripts": {
    "build": "tsc && webpack",
    "test": "jest",
    "start": "node dist/index.js"
  }
}

Was bedeuten diese Felder?

• name: Projektname (kleinbuchstaben, ohne Leerzeichen)
• version: Aktuelle Version im Format major.minor.patch
• scripts: Definiert Befehle, die mit npm run ausgeführt werden

Wie funktionieren Scripts?

• npm run build führt tsc && webpack aus

  • tsc: TypeScript-Compiler (kompiliert .ts zu .js)
  • &&: Führt den zweiten Befehl nur aus, wenn der erste erfolgreich war
  • webpack: Bündelt alle JavaScript-Dateien in eine einzelne Datei

• npm test führt Jest (Test-Framework) aus

• npm start startet die kompilierte Anwendung

npm: Dependencies

npm unterscheidet zwischen zwei Arten von Dependencies:

{
  "dependencies": {
    "express": "^4.21.2"
  },
  "devDependencies": {
    "typescript": "^5.7.2",
    "jest": "^29.7.0"
  }
}

Was ist der Unterschied?

• dependencies: Bibliotheken, die deine Anwendung zur Laufzeit benötigt (z.B. Express für einen Webserver)
• devDependencies: Entwicklungs-Tools, die nur während der Entwicklung/beim Build benötigt werden (z.B. TypeScript-Compiler, Jest für Tests)

Was bedeutet ^4.21.2?

Das Caret-Symbol (^) bedeutet: “Version 4.21.2 oder höher, aber nicht 5.x”:

• 4.21.2 ✅ Erlaubt
• 4.22.0 ✅ Erlaubt (Minor-Update)
• 4.21.3 ✅ Erlaubt (Patch-Update)
• 5.0.0 ❌ Nicht erlaubt (Major-Update könnte Breaking Changes enthalten)

Befehle:

• npm install: Lädt alle Dependencies herunter
• npm install express: Fügt Express zu dependencies hinzu
• npm install --save-dev jest: Fügt Jest zu devDependencies hinzu

⏳ Lädt Dataview-Inhalt...

Was sind Build-Skripte?

Ein Build-Skript definiert, welche Schritte beim Build ausgeführt werden. Während Build-Tools wie Maven oder npm das Framework bieten, definiert das Build-Skript die spezifischen Befehle für dein Projekt.

Beispiel: npm package.json

{
  "scripts": {
    "build": "tsc && webpack",
    "test": "jest",
    "start": "node dist/index.js"
  }
}

Wie funktioniert das?

Wenn du npm run build ausführst:

1. npm liest die package.json
2. Sucht im scripts Objekt nach dem Schlüssel build
3. Führt den Befehl tsc && webpack aus:
   • tsc: Kompiliert TypeScript-Dateien zu JavaScript
   • &&: Führt den nächsten Befehl nur aus, wenn tsc erfolgreich war
   • webpack: Bündelt alle JavaScript-Dateien in eine Datei

Warum Build-Skripte?

Ohne Build-Skripte müsstest du jeden Befehl manuell eingeben:

tsc
webpack
node dist/index.js

Mit Build-Skripten genügt: npm run build && npm start

Moderne Build-Praktiken

Moderne Build-Prozesse gehen über einfaches Kompilieren hinaus und nutzen fortgeschrittene Techniken für Geschwindigkeit, Reproduzierbarkeit und Sicherheit:

Build Caching

Gradle und Bazel nutzen intelligentes Caching: Nur geänderte Teile werden neu gebaut.

// Gradle Build Cache aktivieren
org.gradle.caching=true

Effekt: Builds können 10-50x schneller werden bei inkrementellen Änderungen.

Reproducible Builds

Lockfiles garantieren, dass jeder Build dieselben Dependency-Versionen nutzt:

• npm: package-lock.json
• Gradle: gradle.lockfile
• Maven: Dependency Management mit exakten Versionen

Warum wichtig? “Auf meinem Rechner funktioniert es” wird eliminiert.

Dependency Scanning (Security)

Automatische Prüfung auf bekannte Sicherheitslücken:

npm audit                    # JavaScript/TypeScript
./gradlew dependencyCheck    # Java mit OWASP Plugin

Tools: Snyk, npm audit, OWASP Dependency Check

Container-basierte Builds

Docker ermöglicht isolierte Build-Umgebungen:

FROM maven:3.9-eclipse-temurin-21
COPY . /app
RUN mvn clean package

Jeder Build läuft in identischer Umgebung.

Best Practice: Nutze Build Caching für Geschwindigkeit, Lockfiles für Reproduzierbarkeit und Dependency Scanning für Sicherheit.

Welches Build-Tool wählen?

Die Wahl des richtigen Build-Tools hängt von deinem Projekt und Team ab. Hier eine Entscheidungsmatrix:

Kriterium	Maven	Gradle	npm	MSBuild
Sprache	Java	Multi-Language	JavaScript/TS	.NET (C#/F#)
Lernkurve	Mittel	Steil	Einfach	Einfach
Flexibilität	Niedrig	Sehr hoch	Mittel	Mittel
Build-Speed	Langsam	Schnell (Caching)	Schnell	Schnell
Ökosystem	Riesig (Java)	Wachsend	Riesig (npm)	Groß (.NET)
Enterprise	Standard	Modern	Web-fokussiert	Microsoft

Empfehlungen für Anfänger

Java-Projekt:

• Anfänger: Maven (klare Konventionen)
• Erfahren: Gradle (mehr Kontrolle)

JavaScript/TypeScript:

• Immer: npm oder Yarn (Ökosystem-Standard)

.NET:

• Immer: MSBuild (Visual Studio Integration)

Legacy-Tools vermeiden

Make und Ant nur für Wartung alter Projekte nutzen. Für neue Projekte sind moderne Tools (Maven, Gradle, npm) die bessere Wahl.

Faustregel: Nutze das Tool, das in deinem Technologie-Stack Standard ist. Weiche nur ab, wenn du spezifische Gründe hast.

Best Practice: Umgebungsvariablen nutzen

Vermeide hartcodierte Pfade oder Konfigurationen. Nutze stattdessen Umgebungsvariablen, damit dein Build-Skript auf jedem System funktioniert.

Schlechtes Beispiel:

// Funktioniert nur auf einem spezifischen Rechner
const outputPath = "/Users/max/projects/app/build";

Warum ist das schlecht?

• Auf einem anderen Rechner existiert der Pfad /Users/max/ nicht
• Der Build schlägt fehl, weil der Pfad nicht gefunden wird
• Jeder Entwickler müsste den Code anpassen

Gutes Beispiel:

// Funktioniert auf jedem System
const outputPath = process.env.BUILD_OUTPUT || "build";

Wie funktioniert das?

• process.env.BUILD_OUTPUT: Liest die Umgebungsvariable BUILD_OUTPUT
• || "build": Falls die Variable nicht gesetzt ist, wird “build” als Standardwert verwendet
• Jeder Entwickler kann seine eigene BUILD_OUTPUT Variable setzen, ohne den Code zu ändern

Setzen von Umgebungsvariablen:

# Linux/macOS
export BUILD_OUTPUT="/mein/eigener/pfad"
npm run build
 
# Windows
set BUILD_OUTPUT="C:\\mein\\pfad"
npm run build

Best Practice: Build-Konfigurationen

Ermögliche verschiedene Build-Konfigurationen für unterschiedliche Umgebungen (Development, Test, Production).

Beispiel: npm Scripts

{
  "scripts": {
    "build:dev": "webpack --mode development",
    "build:prod": "webpack --mode production",
    "test": "jest"
  }
}

Wie funktioniert das?

• npm run build:dev: Erstellt einen Development-Build

  • Nicht minimiert (Code bleibt lesbar)
  • Source Maps aktiviert (erleichtert Debugging)
  • Schneller Build

• npm run build:prod: Erstellt einen Production-Build

  • Code minimiert (kleinere Dateigrößen)
  • Optimierungen aktiviert (bessere Performance)
  • Langsamerer Build, aber besseres Endprodukt

Warum ist das wichtig?

• Entwickler brauchen schnelle Builds zum Testen
• Production braucht optimierte Builds für Nutzer
• Verschiedene Umgebungen haben verschiedene Anforderungen (z.B. andere API-URLs)

Kernprinzip: Build-Skripte sollten auf jedem System ohne manuelle Anpassungen laufen. Umgebungsspezifische Einstellungen gehören in separate Konfigurationsdateien oder Umgebungsvariablen.

Abhängigkeitsmanagement: Grundlagen

Abhängigkeitsmanagement bedeutet: Dein Build-Tool lädt automatisch alle benötigten Bibliotheken herunter und bindet sie ein.

Warum ist das wichtig?

Früher musstest du:

1. Bibliotheken manuell von Webseiten herunterladen
2. In dein Projekt kopieren
3. Bei Updates: Alte Version löschen, neue herunterladen, wieder kopieren
4. Bei 20 Bibliotheken: 20× dieser Aufwand

Wie funktioniert es heute?

Maven Beispiel:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
    <version>6.2.0</version>
</dependency>

Wenn du mvn compile ausführst:

1. Maven prüft: Ist spring-context-6.2.0.jar im lokalen Repository (.m2/repository)?
2. Falls nein: Download von Maven Central (zentrale Bibliotheks-Datenbank)
3. Bibliothek wird gespeichert in .m2/repository/org/springframework/spring-context/6.2.0/
4. Bei zukünftigen Builds: Wiederverwendung aus lokalem Cache (kein erneuter Download)

Vorteil: Jeder im Team hat exakt dieselben Bibliotheksversionen, keine “funktioniert auf meinem Rechner”-Probleme.

Abhängigkeitsmanagement: Transitive Dependencies

Transitive Dependencies (transitive Abhängigkeiten) sind Bibliotheken, die deine Bibliotheken selbst benötigen.

Beispiel:

Du fügst Spring Context hinzu:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
    <version>6.2.0</version>
</dependency>

Spring Context benötigt intern:

• spring-core (Kernfunktionalität)
• spring-beans (Bean-Management)
• spring-expression (Expression Language)

Was macht das Build-Tool?

1. Liest die pom.xml von spring-context
2. Findet dort weitere <dependency> Einträge
3. Lädt diese automatisch herunter
4. Wiederholt den Prozess für jede gefundene Dependency (rekursiv)
5. Resultat: Dependency Tree mit allen benötigten Bibliotheken

Versionskonflikte:

Was wenn zwei Bibliotheken verschiedene Versionen von commons-logging wollen?

• Bibliothek A will commons-logging:1.2
• Bibliothek B will commons-logging:1.3

Build-Tools nutzen Dependency Resolution Strategien:

• Maven: “Nearest Definition” - nimmt Version, die am nächsten zur Wurzel im Dependency Tree ist
• npm: Installiert beide Versionen in unterschiedlichen Ordnern (node_modules Struktur)

Best Practice: Nutze feste Versionen (6.2.0) statt Ranges (6.+) für reproduzierbare Builds.

Paketierung: Grundlagen und Formate

Nach erfolgreichem Build und Testing folgt die Paketierung (Packaging): Der kompilierte Code wird zusammen mit Ressourcen in ein verteilbares Format gebündelt.

Warum Paketierung?

• Eine Datei statt hunderte: Statt 500 einzelne .class Dateien zu kopieren → Eine app.jar
• Dependency-Inklusion: Alle benötigten Bibliotheken sind enthalten
• Direkt ausführbar: java -jar app.jar oder npm start
• Einfaches Deployment: Auf Server kopieren, fertig

Typische Paket-Formate:

Technologie	Format	Verwendung
Java	JAR (Java ARchive)	Standalone-Anwendungen, Bibliotheken
	WAR (Web Application ARchive)	Web-Anwendungen für Tomcat/JBoss
JavaScript/TypeScript	npm Package	Bibliotheken für npm Registry
	Bundle (webpack)	Gebündelter Code für Browser
.NET	NuGet Package	Bibliotheken für .NET
	exe/dll	Ausführbare Dateien

JAR vs WAR:

• JAR: Enthält .class Dateien + Manifest (Einstiegspunkt Main-Class)
• WAR: Enthält zusätzlich Web-Ressourcen (HTML, CSS, JSP) + WEB-INF Verzeichnis mit Deployment-Deskriptoren

Paketierung: Der Packaging-Prozess

Wie funktioniert Paketierung mit Maven?

Wenn du mvn package ausführst:

1. Kompilierung: Quellcode wird zu .class Dateien kompiliert (falls noch nicht geschehen)
2. Test-Ausführung: Alle Tests werden ausgeführt (muss erfolgreich sein)
3. Ressourcen kopieren: Dateien aus src/main/resources werden ins Paket kopiert
4. Manifest erstellen: META-INF/MANIFEST.MF Datei wird generiert:

   Manifest-Version: 1.0
   Main-Class: com.beispiel.MainKlasse
   Class-Path: libs/spring-context-6.2.0.jar libs/...
   

5. JAR-Datei erstellen: Alle .class Dateien + Ressourcen werden in target/app-1.0.jar gepackt

Wie funktioniert Paketierung mit npm?

Wenn du npm pack ausführst:

1. Build ausführen: npm run build wird aufgerufen (TypeScript → JavaScript Kompilierung)
2. package.json lesen: Welche Dateien sollen ins Paket? (definiert in files Array)
3. Tarball erstellen: .tgz Datei wird erstellt (z.B. mein-paket-1.0.0.tgz)
4. Veröffentlichung: Mit npm publish wird das Paket zur npm Registry hochgeladen

Fat JAR vs. Thin JAR:

• Thin JAR: Enthält nur eigenen Code, Dependencies müssen separat bereitgestellt werden
• Fat JAR (Uber JAR): Enthält eigenen Code + alle Dependencies in einer Datei
  • Vorteil: Eine Datei für Deployment
  • Nachteil: Größere Dateigröße (oft 50-100 MB)

Maven erstellt standardmäßig Thin JARs. Für Fat JARs: maven-shade-plugin oder spring-boot-maven-plugin verwenden.

⏳ Lädt Dataview-Inhalt...

Ausblick

Du hast die Grundlagen von Build-Prozessen kennengelernt und verstehst jetzt, wie Maven, npm und andere Build-Tools funktionieren. Du kannst Build-Skripte lesen, Dependencies verwalten und einfache Builds selbst konfigurieren.

In der nächsten Lerneinheit “Continuous Integration (CI)” lernst du:

Du erfährst, wie Build-Prozesse in CI/CD-Pipelines automatisiert werden. Jeder Code-Commit löst automatisch einen Build und Tests aus – ohne manuelles Eingreifen.

Du lernst CI-Tools wie Jenkins und GitLab CI kennen und verstehst, wie sie Build-Prozesse orchestrieren. So entwickelst du ein Verständnis für moderne, automatisierte Entwicklungs-Workflows.

Tipp: Die Konzepte aus dieser Lerneinheit – Build-Tools, Dependencies, Artefakte – sind die Grundlage für CI/CD. Alles, was du hier gelernt hast, wird in der nächsten Lerneinheit automatisiert.

---