Eine Entwicklungsumgebung reproduzierbar einrichten

Was du nach dieser Lektion kannst

Leonie beginnt heute in einem Entwicklungsteam. Für ein internes Ticketsystem erhält sie den Link zum Repository und den Satz: “Das Projekt läuft mit Node.js. Installiere die Pakete und starte es.” Auf ihrem Rechner schlägt die Installation fehl. Als sie eine andere Node.js-Version ausprobiert, startet das Projekt, aber zwei Tests liefern andere Ergebnisse als bei ihren Teammitgliedern.

Das Problem liegt nicht automatisch im Programmcode. Es fehlen eindeutige und prüfbare Angaben zur Entwicklungsumgebung. Eine Entwicklungsumgebung umfasst alle Werkzeuge und Einstellungen, die du brauchst, um eine Anwendung zu bearbeiten, zu prüfen und auszuführen. Dazu gehören nicht nur Editor oder integrierte Entwicklungsumgebung, kurz IDE. Auch Laufzeit, Software Development Kit, Abhängigkeiten, Konfiguration und gemeinsame Befehle gehören dazu.

Nach dieser Lektion kannst du:

• Anforderungen an eine Entwicklungsumgebung aus einem Projekt ableiten,
• Laufzeit, Werkzeuge und Bibliotheken nachvollziehbar auswählen,
• Abhängigkeiten und Konfiguration reproduzierbar festlegen,
• Änderungen mit Git kontrollieren,
• eine Einrichtung mit Lint-, Test- und Startbefehlen prüfen und dokumentieren.

Du brauchst dafür kein tiefes Wissen über eine bestimmte Programmiersprache. Die Beispiele nutzen ein kleines Node.js-Projekt, weil sich daran die Zusammenhänge kompakt zeigen lassen. Wie Variablen, Funktionen oder Schleifen funktionieren, gehört nicht zu dieser Lektion.

Die Umgebung ist Teil des Arbeitsergebnisses

Ein Repository allein reicht nicht aus, wenn jede Person raten muss, wie es ausgeführt wird. Reproduzierbar bedeutet hier: Ein Teammitglied kann mit den dokumentierten Voraussetzungen und Projektdateien dieselben Einrichtungsschritte ausführen und denselben geprüften Ausgangszustand herstellen.

Das heißt nicht, dass alle denselben Editor oder dasselbe Betriebssystem verwenden müssen. Unterschiede sind möglich, solange sie das Ergebnis nicht unkontrolliert verändern. Das Team muss deshalb festlegen, welche Teile verbindlich sind und welche persönliche Auswahl bleiben.

Eine Laufzeitumgebung führt ein Programm aus. Bei JavaScript auf dem Server kann das zum Beispiel Node.js sein. Ein Software Development Kit, kurz SDK, bündelt Werkzeuge und Bibliotheken für die Entwicklung auf einer Plattform. Je nach Technik kann ein SDK unter anderem Compiler, Laufzeit, Kommandozeilenwerkzeuge und Schnittstellen enthalten. Nicht jedes Projekt verwendet die Begriffe gleich. Entscheidend ist deshalb die dokumentierte Funktion, nicht nur der Name.

Mehrfachauswahl

Welche Angaben müssen für Leonies Start geklärt sein?

Wähle alle Angaben aus, die das Ergebnis der Einrichtung beeinflussen.

Wähle alle passenden Antworten

Unterstützte Node.js-Version Befehl für die Installation der Abhängigkeiten Persönliches Farbschema des Editors Benötigte Konfigurationsschlüssel Befehle für Lint und Tests

Auswahl prüfen Neu versuchen

Alle passenden Antworten gefunden.

Die Auswahl ist noch nicht vollständig richtig.

Laufzeit, Installation, Konfigurationsschlüssel und Qualitätsbefehle beeinflussen, ob das Projekt nachvollziehbar läuft. Ein persönliches Farbschema ändert den geprüften Projektzustand nicht.

Anforderungen kommen vor der Werkzeugwahl

Leonie sollte nicht zuerst eine lange Werkzeugliste installieren. Zuerst klärt das Team, was das Projekt tatsächlich braucht. Für das Ticketsystem ergibt sich dieses kurze Anforderungsprofil:

projekt:
  zweck: "internes Ticketsystem"
  zielsystem: "Linux-Server"

entwicklung:
  laufzeit: "Node.js in der im Repository festgelegten Version"
  paketverwaltung: "npm"
  qualitaetsbefehle:
    - "npm run lint"
    - "npm test"
  lokaler_start: "npm run dev"

team:
  betriebssysteme:
    - "Linux"
    - "macOS"
    - "Windows"
  versionskontrolle: "Git"

Die Fassung nennt keine erfundene exakte Versionsnummer. In einem echten Projekt steht sie in einer dafür vorgesehenen Projektdatei oder in der Einrichtungsdokumentation. Entscheidend ist, dass das Team eine überprüfbare Festlegung trifft und sie gemeinsam mit dem Projekt pflegt.

Aus dem Profil lassen sich Auswahlkriterien ableiten:

1. Die Werkzeuge müssen auf den verwendeten Entwicklungssystemen funktionieren.
2. Die lokale Laufzeit muss zum Zielsystem und zum Projekt passen.
3. Das Team braucht eine einheitliche Paketverwaltung und ausführbare Qualitätsbefehle.
4. Die Einrichtung darf keine echten Zugangsdaten im Repository voraussetzen.
5. Ein neues Teammitglied muss den Ablauf ohne mündliche Zusatzregeln nachvollziehen können.

Ein Editor kann für diese Anforderungen ausreichen. Eine IDE kann zusätzlich Funktionen wie Debugger, Testintegration und Codeanalyse bündeln. Mehr Funktionen machen ein Werkzeug aber nicht automatisch geeigneter. Auswahlkriterien sind zum Beispiel Sprachunterstützung, Debugging, Bedienbarkeit, Ressourcenbedarf, Lizenzbedingungen, Barrierefreiheit und die vorhandene Erfahrung im Team.

Laufzeit und Abhängigkeiten festlegen

Eine Abhängigkeit ist ein fremder oder interner Softwarebaustein, den das Projekt verwendet. Bibliotheken sparen Entwicklungsarbeit, bringen aber auch Pflegeaufwand und Risiken mit. Das Team prüft deshalb mindestens:

• Erfüllt die Bibliothek die benötigte Aufgabe?
• Passt sie zur Laufzeit und zu anderen Abhängigkeiten?
• Darf sie unter ihrer Lizenz im Projekt eingesetzt werden?
• Wird sie nachvollziehbar gepflegt?
• Welche Sicherheits- und Wartungsfolgen entstehen?

Bei einem npm-Projekt beschreibt package.json unter anderem die direkten Abhängigkeiten und Projektbefehle. Die Sperrdatei package-lock.json hält den aufgelösten Abhängigkeitsbaum fest. Die npm-Dokumentation beschreibt npm ci als Installation für einen vorhandenen, konsistenten Sperrstand. Der Befehl verändert die Sperrdatei nicht. Weichen Paketbeschreibung und Sperrdatei voneinander ab, beendet er die Installation mit einem Fehler.

Für ein bereits vorbereitetes Projekt kann ein kontrollierter Einstieg so aussehen:

git clone <repository-url>
cd ticketsystem
npm ci
npm run lint
npm test
npm run dev

<repository-url> ist bewusst ein Platzhalter. Kopiere keine unbekannten Befehle mit echten Adressen oder Zugangsdaten aus einer fremden Nachricht. Prüfe außerdem die Projektdokumentation, bevor du Abhängigkeiten installierst. Paketverwaltungen können während der Installation Projektskripte ausführen.

Die Reihenfolge ist absichtlich gewählt. Nach dem Klonen wechselst du in das Projekt. Dann stellst du die festgelegten Abhängigkeiten her. Lint und Tests prüfen den Ausgangszustand, bevor du mit einer Änderung beginnst. Der Entwicklungsserver kommt zuletzt.

Sortieraufgabe

Bringe den Projekteinstieg in eine prüfbare Reihenfolge

Ordne die Schritte so, dass Leonie Probleme möglichst früh und nachvollziehbar erkennt.

Ziehe die Einträge an die richtige Position. Geht auch per Tastatur über den Griff.

Reihenfolge prüfen Neu versuchen

Die Reihenfolge stimmt.

Die Reihenfolge passt noch nicht.

Die Dokumentation nennt Voraussetzungen und mögliche Besonderheiten. Danach holst du das Projekt, installierst den festgelegten Stand, prüfst ihn und startest erst dann den Entwicklungsserver. So lässt sich ein Fehler einem Schritt zuordnen.

Konfiguration ist nicht dasselbe wie ein Geheimnis

Eine Anwendung braucht oft veränderliche Angaben, zum Beispiel die Adresse einer Datenbank oder den Port des lokalen Servers. Solche Werte gehören zur Konfiguration. Passwörter, private Schlüssel und echte Zugriffstoken sind Geheimnisse. Sie dürfen nicht als normale Projektdateien in die Versionskontrolle gelangen.

Das Repository kann stattdessen eine Datei wie .env.example enthalten. Sie zeigt benötigte Schlüssel, aber keine echten Werte:

APP_PORT=3000
DATABASE_URL=postgresql://user:password@localhost:5432/tickets_dev
SESSION_SECRET=replace-with-local-development-value

Die Beispielwerte erklären Form und Zweck. Die lokale Datei .env enthält die tatsächlichen Entwicklungswerte und wird über .gitignore ausgeschlossen:

.env
.env.local

Das Ignorieren schützt allerdings nur Dateien, die noch nicht versioniert wurden. Wenn ein Geheimnis bereits committed oder verteilt wurde, reicht das Löschen aus der aktuellen Datei nicht. Dann muss das Team den betroffenen Zugang sperren oder erneuern und den Vorfall nach dem betrieblichen Sicherheitsprozess behandeln.

Fehlersuche

Finde die gefährliche Stelle im Einrichtungsablauf

Wähle die Zeile, die nicht in ein gemeinsam versioniertes Einrichtungsskript gehört.

1. 1 node --version
2. 2 npm ci
3. 3 export SESSION_SECRET=prod-9b8a-real-token
4. 4 npm run lint
5. 5 npm test

Fehler gefunden.

Diese Stelle ist nicht die Ursache.

Ein echtes Geheimnis darf nicht im Skript oder Repository stehen. Das Projekt dokumentiert nur den Namen der benötigten Variable. Der konkrete Wert kommt aus einer dafür vorgesehenen, geschützten Quelle.

Noch einmal suchen

Versionskontrolle macht Änderungen nachvollziehbar

Git speichert nicht einfach regelmäßig den gesamten Ordner. Du wählst Änderungen für den nächsten Commit aus. Ein Commit ist ein benannter, nachvollziehbarer Projektstand. Bevor Leonie eine erste Änderung sichert, prüft sie deshalb genau, was sie aufgenommen hat:

git status
git diff
git add README.md package.json package-lock.json
git diff --staged
git commit -m "Document reproducible project setup"

git status zeigt den Zustand des Arbeitsbereichs. git diff zeigt noch nicht vorgemerkte Änderungen. Nach git add prüft git diff --staged, was tatsächlich in den nächsten Commit gelangt. Diese Kontrolle hilft auch dabei, versehentlich hinzugefügte lokale Konfiguration früh zu erkennen.

Ein sinnvoller Commit enthält eine zusammenhängende Änderung. Die Anpassung der Laufzeitangabe und die dazugehörige Dokumentation gehören zum Beispiel zusammen. Eine unabhängige Änderung an einer Benutzeroberfläche gehört in einen anderen Commit. So können Teammitglieder Entscheidungen später besser nachvollziehen und Änderungen gezielt prüfen.

Lint, Test und Start prüfen verschiedene Dinge

Ein Startbefehl allein zeigt nur, dass die Anwendung in einer bestimmten Situation anläuft. Er beweist nicht, dass der Code den vereinbarten Regeln entspricht oder dass wichtige Funktionen korrekt arbeiten.

• Lint prüft Code gegen festgelegte statische Regeln, ohne den normalen Programmablauf vollständig auszuführen.
• Tests prüfen erwartetes Verhalten mit definierten Eingaben und Ergebnissen.
• Run oder Dev startet die Anwendung in einer vorgesehenen Umgebung.

Alle drei Befehle sollten im Repository eindeutig benannt sein. Bei npm können Skripte den Einstieg vereinheitlichen:

{
  "scripts": {
    "lint": "eslint .",
    "test": "node --test",
    "dev": "node --watch src/server.js"
  }
}

Der Ausschnitt ist ein neues, vereinfachtes Beispiel. Er legt keine allgemeingültige Werkzeugwahl fest. Ein anderes Projekt kann andere Werkzeuge und Befehle verwenden. Wichtig ist, dass die Befehle dokumentiert, versioniert und auf dem unterstützten System ausführbar sind.

Schnellcheck

Entscheidungen für eine reproduzierbare Umgebung

Entscheide dich bei jeder Frage. Du bekommst die Erklärung direkt nach deiner Antwort.

/3

Leonie kann das Projekt starten, aber der Lint-Befehl meldet Fehler. Ist die Einrichtung damit vollständig geprüft?

Das passt.

Noch nicht ganz.

Der Start zeigt, dass die Anwendung in dieser Situation anläuft. Lint prüft zusätzlich die vereinbarten statischen Regeln. Ein gemeinsamer Ausgangszustand sollte alle dokumentierten Prüfungen bestehen.

Nächste Frage

Ein Teammitglied möchte `package-lock.json` nicht committen, weil `package.json` bereits Abhängigkeiten nennt. Was spricht im beschriebenen Projekt dagegen?

Das passt.

Noch nicht ganz.

Die Paketbeschreibung nennt Anforderungen. Die Sperrdatei hält den konkret aufgelösten Baum fest und ermöglicht in diesem npm-Workflow eine kontrollierte Installation mit `npm ci`.

Nächste Frage

Welche Dokumentation hilft einem neuen Teammitglied am meisten?

Das passt.

Noch nicht ganz.

Eine reproduzierbare Anleitung benennt Eingaben, Reihenfolge und überprüfbare Ergebnisse. Ein Screenshot oder eine reine Werkzeugliste lässt entscheidende Schritte offen.

Ergebnis ansehen

Geschafft

von 3

Situationen richtig eingeordnet.

Quiz noch einmal machen

Dokumentation schließt den Kreis

Am Ende ergänzt Leonie die README.md. Eine kompakte Einrichtungsanleitung kann so gegliedert sein:

## Lokale Entwicklung

### Voraussetzungen
- unterstützte Node.js-Version
- npm
- Git

### Einrichtung
1. Repository klonen.
2. `.env.example` als lokale `.env` übernehmen und Entwicklungswerte eintragen.
3. `npm ci` ausführen.

### Prüfen und starten
- `npm run lint`
- `npm test`
- `npm run dev`

### Erwartetes Ergebnis
- Lint endet ohne Fehler.
- Alle Tests bestehen.
- Der Entwicklungsserver nennt eine lokale Adresse.

Die Anleitung nennt nicht nur Tätigkeiten, sondern auch Prüfpunkte. Dadurch kann Leonie unterscheiden, ob eine Installation abgeschlossen ist oder nur scheinbar funktioniert. Wenn ein Schritt von Betriebssystem oder Zielumgebung abhängt, gehört diese Abweichung direkt an die passende Stelle.

Transferaufgabe

Plane das Onboarding für ein zweites Teammitglied

Ein neues Teammitglied soll das Ticketsystem auf einem frisch eingerichteten Rechner starten. Im Repository liegen bisher nur der Programmcode und eine unvollständige package.json. Entwirf einen Ablauf mit sechs bis acht Schritten. Begründe außerdem, welche Angaben und Dateien gemeinsam versioniert werden und welche lokal geschützt bleiben.

Deine Lösung

Musterlösung vergleichen

Musterlösung: Zuerst legt das Team die unterstützte Laufzeit und die Paketverwaltung fest und dokumentiert beides im Repository. Danach werden die benötigten direkten Abhängigkeiten geprüft und eine konsistente Sperrdatei erzeugt. Eine .env.example dokumentiert nur die benötigten Konfigurationsschlüssel; echte Geheimnisse bleiben in einer geschützten lokalen oder betrieblichen Quelle. Das Team ergänzt feste Skripte für Lint, Tests und lokalen Start. Vor dem Commit werden git status, die Änderungen und die vorgemerkten Inhalte geprüft. Anschließend führt eine zweite Person die Anleitung auf einem sauberen Arbeitsstand aus. Die Einrichtung gilt erst als nachvollziehbar, wenn Installation, Lint, Tests und Start die dokumentierten Ergebnisse liefern. Offene Abweichungen werden direkt in der Anleitung festgehalten.

Das steckt auch in meiner Lösung:

Ich habe Voraussetzungen und unterstützte Laufzeit benannt. Ich habe Paketbeschreibung und Sperrdatei berücksichtigt. Ich habe Konfigurationsschlüssel von echten Geheimnissen getrennt. Ich habe Git-Kontrollen sowie Lint, Test und Start eingeplant. Ich habe für wichtige Schritte ein erwartetes Ergebnis genannt.

Was du aus dem Szenario mitnimmst

Eine gute Entwicklungsumgebung ist keine möglichst lange Sammlung von Werkzeugen. Sie ist eine begründete, versionierte und geprüfte Arbeitsgrundlage. Für Leonies Team bedeutet das:

• Anforderungen bestimmen die Auswahl.
• Laufzeit und Abhängigkeiten werden eindeutig festgelegt.
• Konfiguration wird dokumentiert, Geheimnisse werden geschützt.
• Git macht zusammenhängende Änderungen nachvollziehbar.
• Lint, Tests und Start prüfen unterschiedliche Teile des Ausgangszustands.
• Eine zweite Person kann die Anleitung ohne mündliche Ergänzung ausführen.

Damit steht das Grundgerüst. Programmiergrundlagen, konkrete Algorithmen, detaillierte Testverfahren und fortgeschrittene Git-Arbeitsabläufe sind eigene Themen. Diese Lektion konzentriert sich auf die Frage, wie ein Team einen verlässlichen Startpunkt für die Entwicklung schafft.

Quellenbasis und Abgrenzung

Die berufliche Handlung folgt § 13 Absatz 1 Nummer 1 der Fachinformatikerausbildungsverordnung: Entwicklungsumgebungen und Bibliotheken auswählen und einsetzen. Der FIAE-Prüfungskatalog 2026 konkretisiert die Themenbreite unter anderem mit IDE, Bibliotheken, Software-Entwicklungswerkzeugen und Versionsverwaltung. Der Rahmenlehrplan liefert den handlungsorientierten schulischen Kontext der fachrichtungsspezifischen Lernfelder.

Die technische Ausgestaltung von npm ci folgt der offiziellen npm-Dokumentation. Der beschriebene Git-Ablauf nutzt Grundfunktionen aus der Git-Dokumentation. Beide Werkzeugbeispiele zeigen ein mögliches Vorgehen, keine vorgeschriebene Produktwahl.

Das Onboarding-Szenario, alle Dateiausschnitte, Quizfragen und Aufgaben wurden neu erstellt. Sie übernehmen keine echte Prüfungsaufgabe und sagen nicht voraus, welche Inhalte in einem konkreten Prüfungstermin vorkommen. Die Lektion grenzt Programmiergrundlagen, vertiefte Softwaretests, komplexe Branch-Strategien und produktionsspezifisches Secret-Management bewusst aus.

Belegmatrix