Deployment: Das steckt hinter dem neuen Installationssystem

Die Installation einer Software ist mittlerweile zu einen entscheidenen Nutzungsfaktor geworden. Ist die Installation zu unverständlich oder funktioniert mit dem vorhandenen System nicht, ist der User verärgert und wählt im schlimmsten Fall ein anderes Tool.

Wer die Posts im ContentLion Forum durchliest, wird mitbekommen haben, dass ich dabei bin den Installer unseres CMS neu aufzubauen. Das Ganze dauert schon etwas länger, dass hat aber auch einen Grund: Das Thema Deployment (Bereitstellung von Software) ist durchaus komplex.

Varianten des Installers

Neben der normalen Installation (per Weboberfläche) gibt es auch eine Installation über APS. Das ist ein System, mit dem das CMS in den 1-Klick-Installationen der Webhoster gelangen kann.

Neben den beiden Installationsarten wird es auch möglich sein, eigene Installer zu bauen, wo man sich die Plugins auswählt, die mit der Installation bereits ausgeliefert werden sollen. Das bedeutet, man kann auf Basis der Plugins das CMS auch direkt als Forum oder Ähnliches ausliefern können.

Ablauf der Installer-Generierung

Wenn wir mehrere Installationen des Installers haben, bedeutet das, dass bei einer neuen Version jedes Mal alle Installer angepasst werden müssen. Mit Implementierung und Testen wäre dies nach und nach eine immer größer werdende Aufgabe. Aus diesem Grund werden die Installationen automatisch vom Server generiert werden.

Dabei helfen zwei Frameworks:

• Serverseitiges Framework, mit den die MySQL-Queries generiert werden, die Dateien kopiert und z.B. in ein ZIP-Archiv verschoben werden.
• Clientseitiges Framework, Dieses Framework wird auf Wunsch zusammen mit den Installer ausgeliefert und kann die Installation an sich selbst durchführen. Die Oberfläche wird dann von der jeweiligen Installer-Variante verwaltet.

Ist der Installer dann generiert und freigegeben, kann die Verteilung beginnen. So kann die Installation später zum Beispiel über SFTP auf die Download-Server verteilt werden. Diese können bei uns selbst liegen, oder aber auch auf fremden Servern.

Datenbank konfigurieren

Einen wichtigen Teil bei der Installation ist das Einrichten der Datenbank. Das heißt, die Tabellen müssen angelegt und mit ersten Daten befüllt werden. Aus diesem Grund werden am Server die einzelnen Create-Statements generiert und können dann dem Client übergeben werden.

Das ist aber noch nicht alles: Es müssen ja auch die Daten, die während der Installation ausgefüllt werden in die Datenbank kommen (z.B. die Logindaten). Diese Daten sollen sogar von Plugins verlangt werden können. Das bedeutet, wenn man in die Installation z.B. das memcached Plugin integriert, sollen die Zugangsdaten zum Server direkt mit abgefragt werden. Auch hier möchten wir nicht alle Installer von Hand abändern.

Aus dem Grund werden die Einstellungen abstraiert und können bei der Generierung des Installers mit eingebaut werden. Sie sind in Gruppen aufgeteilt, so dass man die Einstellungen auf verschiedene Schritte aufteilen kann. Um die Validität der Daten zu erhalten, gibt es verschiedene Typen von Einstellungen (z.B. numerisch oder String mit Regex-Überprügung).

Kompatibilität gewährleisten

Nun kommt der Schritt, der mich bisher am meisten Zeit gekostet hat. Die Installation soll ja auf so vielen Systemen wie möglich funktionieren und wenn die Kompatibilität nicht gewährleistet ist zumindest eine Fehlermeldung anzeigen, was am Server geändert werden muss.

Die große Frage ist aber: Welche Anforderungen hat das CMS und die mitausgelieferten Plugins eigentlich? Dabei muss zum Beispiel folgendes geklärt werden

• Welche Webserver sind geeignet (Apache, IIS, beliebiege)?
• Welche PHP-Version muss mindestens installiert sein?
• Welche PHP-Version darf maximal installiert sein (entfernte PHP-Funktionen)?
• Welche Apache-Erweiterungen werden benötigt (mod_rewrite,…)
• Welche PHP-Erweiterungen werden benötigt und in welchen Versionen (PECL Pakete,…)

Um diese Anforderungen herauszufinden müsste ich theoretisch jedes Script durchgehen und nachschlagen, ab wann bestimmte Funtkionen, Klassen und Syntaxe(?) vorhanden sind. Das ist im aktuellen Stand eine Menge Arbeit und mit steigender Pluginanzahl ein Ding der Unmöglichkeit.

Also bleiben uns zwei Möglichkeiten:  Ungefähr einschätzen welche Sachen gebraucht werden, oder aber die benötigten Voraussetzungen automatisiert herausfinden. Da die erste Variante leicht zu Fehlern führen kann, habe ich mich für eine Hybrid-Variante entschieden.

Zunächst einmal muss ermittelt werden, welche Funktionen, Klassen usw. von PHP genutzt werden. Für diese Aufgabe habe ich bereits ein Script entwickelt. Das Ganze war nicht wirklich leicht und wird deshalb auch nicht im Detail nach außen gegeben.

Im nächsten Schritt müssen wir die Funktionen herausfiltern, die direkt von PHP kommen. An Hand einer tollen Liste (die auch ganz kompliziert generiert werden musste) kann nun geprüft werden, welche PHP-Versionen usw. erforderlich sind.

Allerdings lässt sich nicht alles automatisiert ermitteln. Wenn es in Richtung Objektorientierung geht, kann man nicht immer herausfinden, welche Klasse eine Variable haben muss. Ein Beispiel:

<?php
	function hello_world($obj)
	{
		$obj->display();
	}
?>

Wenn so etwas im Quellcode steht, lässt sich nicht ermitteln von welchem Typ $obj jetzt ist. Das Problem lässt sich zuwar mit Typehints und PHPDocs verkleinern, allerdings müssen diese dann auch zwingend vorhanden sein. Was noch hinzukommt sind die guten Plugins, die prüfen, ob eine PHP-Funktion schon vorhanden ist und im Fehlerfall einen Workaround machen.

Aus diesen Gründen wird es eine Hybrid-Lösung geben. Das bedeutet, dass die Anforderungen erst automatisch ermittelt, aber vom Entwickler des Plugins manuell angepasst werden können.

Komptabilität zwischen einzelnen Plugins

Die Kernidee von ContentLion ist, dass die Plugins ähnlich wie in einem Framework zusammenarbeiten. Das bedeutet, dass es immer nur kleine Plugins gibt, die dann durch weitere Plugins erweitert werden können. So kann man an einer gemeinsamen Pluginbasis arbeiten und hat nicht 10 Plugins mit sehr ähnlicher Funktion. (mehr dazu).

Dies Konzept erschwert die Installation und das Deployment natürlich noch ein wenig. So müssen Abhängigkeiten zwischen den Plugins beachtet werden. Im Endeffekt können wir hier wie bei den PHP-Funktionen vorgehen. Wir suchen uns alle genutzten Abhängikeiten an Hand der Klassen, Funktionen usw. raus und überprüfen, welche Version der Abhängigkeiten gewährleistet werden muss.

Zeitlicher Ablauf

Zu guter letzt noch einen Kommentar zum zeitlichen Ablauf des Deployments:

1. Plugin-Entwickler checkt sein Plugin mit SVN ein
2. Per SVN Hook wird automatisch die Generierung des Installers angestoßen. Der Hook setzt dabei nur ein Flag. Die Generierung läuft per Cron, um Perfromance-Peaks zu vermeiden.
3. Die Installer heraussuchen, die neu generiert werden müssen. Also die, die das Plugin mit ausliefern
4. Generieren der Installer
5. Nun wird eine Benachrichtigung an die beteidigten Personen verschickt. Ich denke, dass ich dort als erstes nur den Plugin-Entwickler benachrichtige und dieser dann den Commit freigeben muss und die anderen erst danach benachrichtigt werden. So werden keine Benachrichtigungen bei Zwischencommits verschickt
6. Der Installer und das Plugin müssen natürlich noch getestet werden. Dies wird teilweise automatisiert passieren und auch von Hand. Erstmal bin ich einer der Tester und wenn fremde Personen einen Installer generieren, werden auch diese bereits zum Test eingeladen.
7. Ist der Test erfolgreich, wird der Installer als Beta-Version herausgegeben. Nun können wagemutige User schon vorab testen, ob alles klappt
8. Gibt es nach einem fixen Zeitraum keine Beschwerden mehr, wird der Installer dann als Release ausgeliefert

Was meint ihr?

Ich hoffe jetzt habt ihr einen kleinen Blick über die Komplexität des Themas bekommen. Neben den Installer wird später ja auch noch der Updater in den Deployment-Prozess aufgenommen. Hier müssen dann auch ALTER-Statements für neue Spalten o.Ä. generiert werden. Einige Teile des Installers sind aber schon fertig und ich arbeite fleißig daran, dass Thema zu vollenden. Allerdings kann ich nicht jeden Schritt dokumentieren, weil einige Teile wie das Herausfinden der PHP-Versionen und das Generieren der CREATEs usw. erstmal nicht öffentlicht werden.

Aber was meint ihr: Hab ich im Konzept noch einen wichtigen Punkt ausgelassen?