Moderne Webanwendungen mit Node.js und Express.js

Projektinitialisierung und Versionskontrolle

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Beim Durchstarten mit der eigenen Webanwendung gilt es, einige Initialisierungsaufgaben zu erledigen. Im Idealfall greifen Sie dabei direkt auf Versionskontrollsysteme zurück.

Transkript

Vor dem Beginn mit einem neuen Node.js-Projekt, sollte man zunächst einmal darauf achten, einige Best-Practice-Modelle anzuwenden. Dazu gehören zum einen den Node Package Manager zu benutzen. und zum anderen ein Versionskontrollsystem zu verwenden. Wie das im Einzelnen funktioniert, demonstriere ich Ihnen in diesem Video. Ich beginne initial also mit einem leeren Projektordner. Das bedeutet, aktuell gibt es keine Inhalte in meinem Projekt. Ich öffne die Konsole, das Terminal, und nutze den Befehl "npm init", um mein Node.js-Projekt zu initialisieren. Ich kann nun mein Projekt anhand der abgefragten Parameter spezifizieren. Und sobald das erledigt ist, erhalte ich innerhalb meines Ordners eine "package.json"-Datei. Die "package.json"-Datei erlaubt es anderen Nutzern, mein Projekt zu verstehen, und welche Abhängigkeiten es hat. Wenn ich nun beispielsweise eine Abhängigkeit installiere, wie 'express'... (tippen) nutze ich den Parameter '--save', um sicherzustellen, dass meine Abhängigkeiten innerhalb meiner "package.json"-Datei dokumentiert werden. Als nächstes möchte ich dafür sorgen, dass ich zum einen mit anderen Personen zusammenarbeiten kann, sollte ich es wünschen. Und zum anderen, mir selbst dokumentiere, welche Änderungen ich über die Zeit hinweg an meinem Projekt vornehme, und so entsprechend auch zu älteren Ständen zurückspringen kann. Dafür nutze ich nun ein Versionskontrollsystem mit dem Namen Git. Im Reiter VCS Import into Version Control wird mir nun die Möglichkeit gegeben, einen Ordner auszuwählen, für den ein Git-Projekt initialisiert wird. Ich wähle den Projekt-Ordner und bestätige mit OK. Zum jetzigen Zeitpunkt hat sich meine Oberfläche etwas verändert. Im unteren Bereich befinden sich nun zwei Tabs mit der Bezeichnung "Version Control" und "Changes". Im Reiter VERSION CONTROL sehe ich, welche Kommandos von der graphischen Oberfläche automatisch im Hintergrund ausgeführt werden. im Reiter CHANGES kann ich nun nachvollziehen, welche Dateien aktuell versioniert sind und welche nicht. Nicht versionierte Dateien werden auch im Projekt-Explorer entsprechend dargestellt, mit einer roten Farbe. Um nun sicherzustellen, dass meine "package.json"-Datei immer unter der Versionskontrolle liegt, klicke ich auf 'Click to browse'. Und kann nun durch einen Rechtsklick auf die "package.json" Add to VCS auswählen. Und nun wird entsprechend die "package.json"-Datei versioniert. In meinem Projekt-Ordner gibt es einige andere Ordner, wie beispielsweise den Ordner "node_modules" und den Order ".idea". Beide dieser Ordner sind nicht relevant für ein Versionskontrollsystem. Daher empfiehlt es sich diese Ordner entsprechend zu ignorieren. Das ist relativ einfach möglich, durch ein Rechtsklick Ignore... Ich kann nun spezifizieren, dass ich alle Ordner beziehungsweise Dateien unter dem Ordner ".idea" ignorieren möchte. Ich bestätige mit OK. Und sehe nun einige Ordner und Dateien, die entspechend zum "Express Framework" dazugehören. Ich kann auch den Ordner "node_modules" entsprechend ignorieren. Und mit OK bestätigen. Die nun verbliebenen Dateien sind Dateien, die im Unterordner "express" liegen. Da auch diese nicht für mich relevant sind, kann ich über Ignore... entsprechend alle Dateien unterhalb von "\express" ignorieren. Nun ist nur noch meine "package.json" -Datei für Versionskontrolle relevant. Um nun eine erste Version zu erheben, kann ich über Rechtsklick auf "Default" und "Commit Changes..." noch einmal sehen, welche Dateien relevant sind für diese Änderungen und eine Bezeichnung vergeben. Zum Beispiel "initial commit". Ich kann IntelliJ beziehungsweise Webstorm dazu bringen Codeanalyse zu betreiben, in dem Moment, wo ich auf COMMIT klicke. Das bedeutet, Webstorm überprüft, ob der Code der Qualität entspricht, die die Codeanalyse voraussetzt. Im Normalfall ist dieser Prozess sehr langwierig, und empfiehlt sich nur, wenn es wirklich einen Zweck dafür gibt. Aus diesem Grund wähle ich ihn nicht mehr aus und bestätige den Commit. Unter dem Reiter "Log" sehe ich nun, dass es einen "intial commit" mit der "package.json"-Datei gibt. Wenn ich nun eine Änderung vornehme, beispielsweise auf Version 1.0.1 wechsle, sehe ich in Webstorm, dass Zeilen, die Änderungen haben, markiert werden, und Dateien, die verändert wurden, nicht mehr grün sind, sondern blau. Unter dem Reiter LOCAL sehe ich nun, dass die "package.json"-Datei wieder auftaucht. Und ein neuer Aufruf von Commit Changes... - ein neuer Text für die entsprechende Beschreibung, führt dazu, dass wieder eine neue Version erhoben worden ist. Möchte ich nun zu einer anderen Version zurückspringen, kann ich diese auswählen, über einen Rechtsklick Checkout Revision, zurückspringen, und sehe nun, dass die Version wieder 1.0.0 ist. "HEAD" bezeichnet also immer den Standpunkt, der aktuell mein Projekt repräsentiert. "MASTER" repräsentiert den Standpunkt, den der Entwicklungszweig "master" aktuell inne hat. Wenn ich es wünsche, kann ich auch parallel neue Entwicklungszweige anlegen, in denen ich separat von dem Haupt-"Master" weiter entwickeln kann, und erst später dies zum "master" hinzufüge. Unter Branches... kann ich zum Beispiel, einen neuen Entwicklungszweig anlegen. Ich bezeichne ihn mit einem Namen: beispielsweise "index-development". Und nun sehen wir, dass sowohl "HEAD", "MASTER", als auch "index-development" auf diesem Versionsstand sind. Füge ich nun beispielsweise eine neue Datei hinzu... werde ich zunächt einmal gefragt, ob ich diese Datei auch mit dem Versionskontrollsystem Git nutzen möchte. Ich bestätige mit JA. Füge einen entsprechenden Code hinzu. Und speichere die neue Version... mit der Bezeichnung "Index.js". Im Log zeigt sich nun, dass der aktuelle Stand des Projektes auf dem Entwicklungszweig "index-development" liegt, und das "index-development" bereits diese Änderung hat. Ist dieser Entwicklungszweig zu einem bestimmten Zeitpunkt abgeschlossen, kann ich nun über Git Branches... zum "master" zurückkehren. Und entsprechend über Git Branches... index-development Merge alle Änderungen, die in "index-development" vorgenommen worden sind, auf den "master" anwenden. Das bedeutet, "Index.js" ist nun auch Teil des "Master"-Zweiges. Zu Anfang dieses Videos habe ich also mit Hilfe des Node Package Managers das Projekt initialisiert, und meine Abhängigkeiten nachhaltig in der "package.json" gesichert. Mit einer kurzen Einführung in Versionskontrollsysteme konnte ich meine relevanten Dateien zu einer Sicherung hinzufügen, Änderungen absichern, gegebenenfalls wiederherstellen. Und über unterschiedliche Entwicklungszweige, auch Branches genannt, an unterschiedlichen Dingen parallel arbeiten.

Moderne Webanwendungen mit Node.js und Express.js

Entwickeln Sie auf der Open-Source-Plattform Node.js kompakte und performante Webapplikationen und lernen Sie weiterführende Konzepte professioneller Webentwicklung kennen.

2 Std. 20 min (24 Videos)
Derzeit sind keine Feedbacks vorhanden...
Exklusiv für Abo-Kunden
Erscheinungsdatum:23.03.2015

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!