Kompendium

Semantische Versionierung (»Semver«)

In der Open-Source-Szene wird häufig der Semver-Standard (»Semantic Versioning«) für die Vergabe von Versionsnummern genutzt. Im Semver-Standard haben Versionsnummern immer 3 Zahlenkomponenten, voneinander getrennt durch Punkte (z.B. "9.5.6"):

• Major-Version (erste Zahl): Immer, wenn eine neue Softwareversion so grundlegende Änderungen mit sich bringt, dass die neue Version nicht abwärtskompatibel ist (»Breaking Changes«), wird eine neue Hauptversion begonnen.
• Minor-Version (mittlere Zahl): Zur Einführung neuer Funktionalitäten, die jedoch abwärtskompatibel sind und keine Störungen verursachen.
• Patch-Version (letzte Zahl): Nur für (abwärtskompatible) Bugfixes, es sind keine neuen Funktionalitäten zu erwarten.

Durch die konsequente Anwendung des Semver-Standards kann Nutzern einer Software signalisiert werden, mit welchem Aufwand sie beim Einspielen einer neuen Version rechnen müssen.

Composer, die gängigste Paketverwaltung in der PHP-Welt, macht intensiv Gebrauch vom Semantic-Versioning-Standard.

Composer & Packagist

Softwareautoren haben ein Interesse daran, ihre Programme öffentlichkeitswirksam zu publizieren. Gerade in der Open-Source-Szene gibt es eine Unzahl kleiner Programme, die sich sehr speziellen Aufgaben widmen, für sich allein gesehen aber kaum Nutzen für Endanwender haben. Sie sind dazu gedacht, in andere Software integriert zu werden (sog. »Bibliotheken«).

Damit Autoren komplexerer Software den Überblick haben, welche einsatzbereiten, kleineren Bausteine bereits existieren, braucht es ein gut organisiertes Ökosystem, in dem Bibliotheken als Pakete organisiert und gut zu finden sind. Um die teils komplexen Abhängigkeiten, die durch ihren Einsatz entstehen, effizient zu verwalten, kommt häufig Paketmanagementsoftware zum Einsatz.

Packagist

Auf packagist.org können Software-Autoren die von ihnen geschriebenen Programme zentral registrieren, so dass diese von Composer (s.u.) gefunden und installiert werden können. Packagist übernimmt dabei die Aufgabe eines Verzeichnisses — die eigentliche Software liegt auf Code-Verwaltungsplattformen wie GitHub oder BitBucket. Zur Registrierung und Veröffentlichung einer Software auf Packagist wird lediglich ein kostenloses Website-Konto benötigt.

Composer

In der PHP-Welt hat sich Composer als beliebtester Paketmanager (auch "Dependency Manager") durchgesetzt. Composer selbst ist in PHP programmiert und wird auf der Kommandozeile genutzt. Mit ihm lassen sich PHP-Softwarepakete installieren, aktualisieren und wieder entfernen, wobei automatisch alle Abhängigkeiten zu anderen Bibliotheken berücksichtigt werden.

Composer stützt sich in erster Linie auf das Paketverzeichnis Packagist (s.o.), kann jedoch auch Pakete einbeziehen, die nicht dort veröffentlicht, aber zumindest auf GitHub oder BitBucket verfügbar sind.

Installation

Um Composer zur Installation von Software (z.B. TYPO3) nutzen zu können, müssen wir das Skript zunächst einmalig downloaden und auf unserem Server installieren. Melde dich dazu per SSH an deinem Hetzner-Server an.

Leider lässt es Hetzner jedoch nicht zu, dass wir dort eigene Programme hinterlegen, so dass wir Composer an anderer Stelle dezentral ablegen und von dort aus nutzen müssen. Im folgenden Beispiel legen wir Composer mit in jenes Verzeichnis, in welchem wir auch TYPO3 installieren werden — als Speicherort könnte aber auch ein anderer gewählt werden.

Die vollständige / offizielle Installationsanleitung für Composer findest du auf der Composer-Website.

​x
# Ins Installationsverzeichnis wechseln
cd public_html/typo3
​
# Download und Ausführen des Composer-Installers
wget -O composer-installer.php https://getcomposer.org/installer
php composer-installer.php
​
# Löschen des Composer-Installers
rm composer-installer.php

Composer steht damit als composer.phar im aktuellen Verzeichnis für den Einsatz zur Verfügung. Um nicht jedes Mal die Dateiendung .phar mittippen zu müssen (steht für "PHP Archiv"), benennen wir das Skript in composer (ohne Endung) um:

xxxxxxxxxx
# Umbenennen der PHAR-Datei aus Bequemlichkeitsgründen
mv composer.phar composer

Im Prinzip wäre es wünschenswert, das Composer-Skript zentral auf dem Server zu hinterlegen, so dass es von überall aus genutzt werden kann. Linux sieht hierfür typischerweise das Verzeichnis /usr/local/bin vor, in welches wir Composer dazu verschieben müssten.

xxxxxxxxxx
# Funktioniert leider nicht auf dem Hetzner-Server, wäre aber praktisch:
mv composer /usr/local/bin

Leider aber lässt Hetzner dies nicht zu, weshalb wir Composer aus unserem lokalen Verzeichnis heraus nutzen müssen, etwa so:

Nutzung

xxxxxxxxxx
./composer require <vendor/package-name>

Dieser Befehl würde auf Packagist nach einer Software namens <vendor/package-name> suchen und diese — sofern zu finden — in der neuesten Version installieren. Im Beispiel ist <vendor/package-name> natürlich ein Platzhalter und muss gegen echte Werte ersetzt werden (inklusive der spitzen Klammern): Programmierer identifizieren sich selbst mit einem vendor (Herstellername) und geben ihrer Software einen eindeutigen Paketnamen (Kleinbuchstaben, Ziffern, -). In Kombination ist so jedes Softwarepaket zuverlässig referenzierbar.

Das führende ./ vor dem Composer-Kommando ist notwendig, um zu signalisieren, dass ein Programm (hier: Composer) im lokalen Verzeichnis benutzt werden soll. Andernfalls würde Linux erwarten, dass das Programm zentral, beispielsweise unter /usr/local/bin liegt.

Bei der Installation von Bibliotheken legt Composer ein Verzeichnis namens vendor an, in welches die Software hineininstalliert wird. Zusätzlich stellt Software einen sog. Autoloading-Mechanismus zur Verfügung, so dass andere Software bequem auf die installierten Bibliotheken zugreifen und diese nutzen kann.

Die vollständige Dokumentation zu Composer findest du auf der Composer-Website.

PHP-Konfiguration

Um Composer auf einem Hetzner-Account nutzen und damit Software installieren zu können, musst du einmalig im Hetzner-Backend die PHP-Option allow_url_fopen aktivieren:

Projektsicherung (Backup)

Zur vollständigen Sicherung eines Webprojekts müssen zwei Komponenten einzeln behandelt werden:

1. Dateien im Dateisystem
2. Daten in der Datenbank

Sichern des Dateisystems

Der einfachste Weg, die Dateien eines Projekts zu sichern, ist die Herstellung eines Voll-Backups. Dazu muss die komplette Verzeichnisstruktur des Projekts in ein Dateiarchiv verpackt werden, beispielsweise im ZIP-, GZ- oder RAR-Format. Es empfiehlt sich, in den Dateinamen des Archivs stets das Datum (und ggf. die Uhrzeit) zu integrieren, an dem das Archiv erstellt wurde. Zur Durchführung gibt es mehrere Ansätze:

Download + lokale Archivierung

Lade per FTP den kompletten Verzeichnisbaum deines Projekts auf deinen Lokalen Computer und nutze ein Archivierungsprogramm (z.B. 7-Zip), um ein Archiv herzustellen. Bitte stelle sicher, dass du das komplette übergeordnete Verzeichnis deines Projekts archivierst, nicht die einzelnen Dateien im Projekt, da die Vielzahl von Einzeldateien beim Auspacken unter Umständen großes Chaos anrichten kann.

Archivierung auf dem Live-Server

Die empfohlene, weil schnellere Variante des Archivierens nutzt die Kommandozeile. Verbinde dich dazu per SSH mit deinem Server und wechsle ins übergeordnete Verzeichnis deines Projekts. Nutze dort z.B. das zip-Kommando, um dein Projektverzeichnis in eine Archivdatei zu packen:

xxxxxxxxxx
# Wechsel ins übergeordnete Verzeichnis
cd public_html
​
# ZIP-Archiv vom Unterverzeichnis "wp" herstellen
zip -r wordpress-20190726.zip wp

Im Beispiel wird das Unterverzeichnis wp (letztes Argument) rekursiv (-r, also mit allen enthaltenen Dateien und Unterverzeichnissen) in ein Archiv namens wordpress-20190726.zip verpackt. Das Archiv wird nach Abschluss des Vorgangs in dem Verzeichnis liegen, in dem der Befehl ausgeführt wurde, im Beispiel also direkt im public_html-Verzeichnis.

Anschließend kannst du das erstellte Archiv per FTP vom Server laden und in Sicherheit bringen. Alternativ kannst du das Archiv auch in die öffentlich erreichbaren Zone deines Webservers verschieben (auf das public_html-Verzeichnis selbst solltest du nicht direkt zugreifen können) und dann über den Browser herunterladen. Angenommen, deine Website ist über https://wp.meinedomain.de erreichbar, dann könntest du obiges ZIP-Archiv wie folgt verfügbar machen:

xxxxxxxxxx
# Verschieben des Archivs in den öffentlich zugänglichen Bereich (Unterverzeichnis "wp")
mv wordpress-20190726.zip wp

Sodann solltest du das Archiv über https://wp.meinedomain.de/wordpress-20190726.zip per Browser herunterladen können. Vergiss nicht, das Archiv anschließend wieder vom Server zu löschen oder zumindest aus dem öffentlich zugänglichen Bereich herauszuschieben, da es mitunter sensible Daten enthält (z.B. Datenbank-Zugangsdaten):

xxxxxxxxxx
# Löschen des Archivs
rm wp/wordpress-20190726.zip

Sichern der Datenbank

Auch für die Archivierung der Datenbank gibt es zwei Wege: Über die Verwaltungsoberfläche von Hetzner, oder ebenfalls über die Kommandozeile.

Über die Hetzner-Verwaltungsoberfläche

Hetzner stellt zur browserbasierten Verwaltung von Datenbanken die Open-Source-Software phpMyAdmin zur Verfügung, über die bequem Datenbankexporte durchgeführt werden können. Melde dich dazu an deinem Hetzner-Backend an und starte den phpMyAdmin für die zu exportierende Datenbank:

Führe im phpMyAdmin folgende Schritte durch

1. Wähle den Reiter »Export«
2. Stelle den Exportmodus auf »Custom - display all possible options« (benutzerdefinierte Einstellungen) um
3. Stelle unter »Output > Save output to a file > Compression« auf zipped um (es wird dann ein ZIP-Archiv erzeugt)
4. Bestätigen den Export am Ende des Bildschirms durch die »Go«-Schaltfläche. Kurz darauf sollte dann ein Download starten, der die komplette Datenbank (Struktur und Daten erhält).

TIPP: Über den Reiter "Import" lassen sich solche Exporte auch wiedereinspielen. Durch das Hochladen eines früheren Datenbankarchivs kannst du deine Website (zumindest datenbanktechnisch) auf genau den Zustand zurückstellen, den sie beim Export hatte.