Den Hudson CI-Server habe ich vor längerer Zeit bereits vorgestellt. Nun gibt es eine kurze Ergänzung, wie man das Ant-Buildskript ergänzen kann, um ein Deployment zu realisieren.
Als Voraussetzung gehe ich hier davon aus, dass alle notwendigen Projektdateien in eine Zip-Datei gepackt werden – wenn php 5.3 endlich eine vernünftige Verbreitung hat, kann man auch mit phar-Dateien arbeiten. Die Projektdateien werden um ein simples Deployment für die Datenbank angereichert. Hier kann man notwendige Anpassungen eintragen. Ich habe in einem Beispielprojekt ein kleines Bashskript, dass einen SQL-Dump in den vorhandenen und konfigurierten MySQL-Server einspielt.
Jetzt funktioniert das Deployment so, dass auf dem Ziel-System der Sourcen-Ordner gelöscht wird. Dann wird das Zip-Archiv per scp auf diesen Rechner kopiert und entpackt. Anschließend der SQL-Dump eingespielt und man erhält die aktuelle Version der Applikation.
Da ein vorhandenes System gnadenlos überspielt wird – selbst in der Datenbank werden alle Tabellen mit Drop entfernt – ist diese Art des Deployments nur für eine Continuous Integration Instanz sinnvoll. Auf einer solchen Instanz dürfen Testdaten zwar angelegt werden, aber es ist kein Verlaß, dass diese Daten Bestand haben. In der Entwicklung ändert sich ein Datenbank-Schema auch gelegentlich und somit kann man sich bei einer Migration auf spezielle Versionssprünge beschränken und muss nicht mehrfach am Tag die Daten migireren.
Ein solches System kann man auch für ein initiales Erstellen einer Entwicklungsumgebung nutzen.
Als Werkzeug für dieses Deployment nutze ich ant. Dieses integriert sich reibungslos in die vorhandene Build-Server Struktur, da man das vorhandene Build-Skript um die neuen Targets erweitern muss.
Es wurden die scp und sshexec Tasks von ant genutzt. Man muss daran denken, dass die Abhängigkeit zur Java Secure Channel Bibliothek erfüllt ist. Die Jar legt man zum Beispiel unter ${user.home}/.ant/lib
ab. Dann wird die Bibliothek auch von ant gefunden.
Die Konfiguration ist dann eigentlich selbsterklärend. Man arbeitet genauso wie man es „von Hand“ machen würde und nutzt ssh und scp für die Durchführung. Von Vorteil ist es eine Public Key Authentication zu nutzen, dann kann man sich das ssh-Passwort im Build-Skript sparen. Ein Howto findet man zum Beispiel hier. Verschiedene Distributionen bringen Skripte für eine einfachere Erstellung und Verteilung mit. Es lohnt an dieser Stelle eine kurze Recherche.
Ein Beispiel für die Benutzung des scp Tasks sieht dann so aus:
Dieses Code-Fragment nutzt man in einem sinnvollbenannten Target. Und schon kann ant auch Dateien per scp kopieren.
Der sshexec-task funktioniert prinzipiell genauso, jedoch nutzt man hier ein command
-Attribut. Schließlich will man ja einen Befehl remote ausführen:
Durch geschicktes aneinanderreihen von Befehlen kann man sich nun ein Deployment bauen. Dies ist normalerweise sehr spezifisch und wird daher hier nicht genauer ausgeführt. Bei Interesse ergänze ich aber gerne noch ein Code Fragment, wie ich vorgehe.