Als Webentwickler sind wir stets bestrebt, die Effizienz und Produktivität unserer täglichen Arbeit kontinuierlich zu verbessern. Entweder durch die Verbesserung der Werkzeuge, mit denen wir arbeiten (Editoren, Workstations usw.), oder durch die Verbesserung der etablierten Entwicklungsabläufe (Aktionen, die Sie normalerweise durchführen, wenn Sie sich mit bestimmten Entwicklungsaufgaben befassen). Das könnte heißen, Server zu verwalten, sich mit ihnen zu verbinden – FTP, SSH, Dateien zu bearbeiten, Backups, Uploads, Downloads, usw. Lesen Sie mehr über die Erstellung eines eleganten Joomla-Entwicklungsworkflows mit Akeeba UNiTE.
Ein wichtiger Aspekt jedes guten Entwicklungs-Workflows ist auch die Einrichtung der Entwicklungs- gegenüber der Produktionsumgebung und der Aufbau eines vernünftigen Implementierungssystems, das diese beiden Umgebungen verbindet. So erhalten Sie eine flexible und unterstützungsorientierte Arbeitskonfiguration, die weniger kompliziert und fehleranfällig ist.
Vor kurzem stand unser Team vor der Herausforderung, ein solches Implementierungssystem zu entwickeln, und im folgenden werde ich die grundlegenden Schritte dieses Prozesses sowie das Konzept, das wir dabei verfolgt haben, skizzieren.
Die Situation
Wie bei den meisten Entwicklungsprojekten gab es eine zugrundeliegende Situation oder ein Problem, das ein sofortiges Handeln von uns erforderte. Unsere Schwierigkeiten waren vielfältig:
- Zahlreiche Joomla-Seiten: 20+, mit mehreren Usern/Entwicklern, die an ihnen arbeiteten.
- Direktumsetzung (Live) Seitenänderung. DEV – PROD Workflow oder System war zu diesem Zeitpunkt nicht vorhanden.
- Eingeschränkte Kontrolle über den Produktionsserver. Abgesehen von einem einfachen FTP-Zugang hatten wir keine andere Möglichkeit, irgendwelche Einstellungen auf dem Server zu ändern oder zu modifizieren. Der Produktionsserver hatte die volle Kontrolle über unseren Kunden.
- Der Kunde wünschte, dass wir die Live-Seiten-Edits minimieren
- Der Kunde hatte ein aggressives Frontend-Caching implementiert.
- Wir hatten Mühe, effizient zu debuggen.
- Wir verloren Zeit damit, DEV-Seiten manuell zu erstellen.
Deshalb brauchten wir ein System, das (halb-)automatisch Entwicklungsseiten (DEV-Seiten) für uns erstellt und aktualisiert, die uns eine mehr oder weniger problemfreie Umgebung für die Arbeit ermöglichen und uns einfach erlaubten, die Änderungen wieder in die Produktionsseiten, zu integrieren.
Hauptfunktionen
Als Ausgangspunkt haben wir die wichtigsten Funktionen für unser System/Tool wie folgt definiert:
- Klonen
- Kopie der PROD-Seite auf dem DEV-Server erstellen
- Bestehende DEV-Seite überschreiben
- Implementieren
- DEV-Seite auf PROD-Server kopieren
- Bestehende PROD-Seite überschreiben
- Sperren
- DEV-Seite sperren, um ein Überschreiben zu verhindern
- Wird während der Entwicklung auf DEV verwendet 🙂
- Einfrieren
- Einfrieren der PROD-Seite, um Änderungen am Backend zu verhindern
- Zugriff auf /administrator sperren
Der Entwicklungsprozess
Da es sich hierbei ausschließlich um Joomla-Seiten handelte und wir alle Erfahrung mit der Akeeba Backup-Erweiterung hatten, haben wir uns entschieden, diese für unser Tool zu nutzen. Wir wussten bereits von dem Kommandozeilen-Framework, Akeeba UNiTE, das Akeeba entwickelt hatte, und beschlossen, es auszuprobieren.
Wir begannen mit der Erstellung des Entwicklungs-Servers als Replikat für die Produktion, wobei alle Seiten in beiden Umgebungen vorhanden waren. Das Setup sah wie das folgende Schema aus:
| Development | Production |
|---|---|
| cl–site1-com.dev.server.com | site1.com |
| cl–site2-com.dev.server.com | site2.com |
| cl–site3-com.dev.server.com | site3.com |
| cl–site4-com.dev.server.com | site4.com |
| deploy.dev.server.com | deploy.site.com |
Wie Sie wahrscheinlich bemerkt haben, haben wir auch eine separate Domain namens deploy in jeder Umgebung erstellt. An dieser Stelle wurden unsere Implementierungsanwendungen platziert. Wir haben uns für einen zweiteiligen App-Ansatz entschieden, bei dem Instanzen über einige einfache HTTP-Anfragen miteinander kommunizieren.
Benennung der Standorte
Außerdem haben wir uns auf eine Namenskonvention für die Entwicklungsseiten geeinigt. Sie erhielten das cl– Präfix und ersetzten alle Punkte in den Ordnernamen der Produktionsseiten durch einen Bindestrich auf dem Entwicklungsserver. Auf diese Weise können wir automatisch die Stammverzeichnisnamen der Live-Seiten sowie die Domainnamen abrufen.
Akeeba UNiTE hat sich für unseren Zweck als mehr als ideal erwiesen. Es ermöglichte völlig automatisierte Seitenwiederherstellungen sowie Remote-Backups zur gleichen Zeit.
Erstellen von Remote-Backups
Um UNiTE die Erstellung von Remote-Backups zu ermöglichen, mussten wir in der Konfiguration des Akeeba Backup-Backends an jeder Produktionsseite die: „Einstellung für Frontend und Remote-Backup aktivieren“. Außerdem mussten wir dort ein geheimes Wort hinterlegen.
Das Einzige, was UNiTE benötigt, um ein Remote-Backup + eine Wiederherstellung in einem bestimmten Ordner/Server durchzuführen, ist eine einfache XML-Datei mit einigen erforderlichen Konfigurationsdaten:
<?xml version="1.0" encoding="UTF-8"?>
<unite scripting="02_angie">
<remote>
<host>http://www.example.com</host>
<secret>test</secret>
<component>com_akeeba</component>
<profile>1</profile>
<downloadmode>http</downloadmode> <dlurl>ftp://user:pass@ftp.example.com/administrator/components/com_akeeba/backups</dlurl>
<delete>1</delete>
</remote>
<siteInfo>
<package from="remote"></package>
<deletePackage>0</deletePackage>
<localLog>test.log</localLog>
<emailSysop>0</emailSysop>
<name>My Shiny Restored Site</name>
<email>nicholas@dionysopoulos.me</email>
<absolutepath>/Users/nicholas/Sites/restored</absolutepath>
<homeurl>http://www.example.net</homeurl>
<livesite>http://www.example.net</livesite>
</siteInfo>
<databaseInfo>
<database name="site">
<changecollation>0</changecollation>
<dbdriver>mysqli</dbdriver>
<dbhost>127.0.0.1</dbhost>
<dbuser>mydbuser</dbuser>
<dbpass>password</dbpass>
<dbname>example</dbname>
<dbprefix>exmp_</dbprefix>
</database>
</databaseInfo>
</unite>Beispiel UNiTE XML Datei
Der Abschnitt <remote> stellt die wichtigen Daten der Produktionsseite dar, wie etwa host, das Remote-Backup-Geheimwort, die Backup-Profil-ID, den Download-Modus und die eigentliche Download-FTP-URL.
Die Sektion <siteinfo> enthält eine sehr wichtige Information, und das ist der <absolutepath>. Hier fügen Sie Ihren Stammordnerpfad für die Entwicklungsseite hinzu. Desweiteren teilen Sie UNiTE im <package> mit, dass das Paket aus einem Remote-Backup der Live-Seite stammen soll (Remote-Abschnitt oben).
Die Sektion <databaseinfo> enthält alle Verbindungsdaten der Datenbank der Entwicklungsseite, so dass UNiTE weiß, wo die zuvor gesicherte Datenbank wiederhergestellt werden muss.
Weitere Informationen zu den UNiTE XML-Einstellungen finden Sie in der UNiTE-Dokumentation.
Der Anwendungsablauf
Der Entwicklungsteil der App hatte eine Schnittstelle wie die folgende:
Erstellen des Site Clones
Die Schaltfläche “NEW CLONE” leitet den Cloning-Prozess ein. Die Anwendung erstellt zunächst dynamisch die UNiTE-XML-Datei und führt dann die ausführbare UNiTE unite.phar php-Archivdatei mit einem PHP-Ausführungsaufruf aus:
<?php $command = "php -f unite.phar clone.xml 2>&1"; exec($command, $output, $return);Das ist im Grunde genommen alles, was Sie tun müssen. Mit diesem Aufruf liest UNiTE die XML-Datei, erstellt ein Echtzeit-Remote-Backup von der Produktionsseite und stellt sie dann unter dem Entwicklungspfad wieder her. Und das alles hinter den Kulissen und ohne jegliche Benutzerinteraktion.
Klonen in umgekehrter Reihenfolge
Die DEV TO PROD Taste startet einen umgekehrten Prozess. Zuerst erstellt die App ein Backup der Entwicklungsseite mit einem CLI Akeeba Backup-Aufruf. Das Backup-Archiv wird an den Temp-Ordner des Produktionsservers gesendet und mit einem HTTP-Aufruf an die Production Deploy App wird derselbe UNiTE-Wiederherstellungsprozess eingeleitet. Zum Beispiel sendet die DEV App diese Postanforderung:
$http = JHttpFactory::getHttp();
$data = [ 'token' => self::TOKEN, 'task' => 'restore', 'jpa' => $jpa, 'dir' => $dir ];
$res = $http->post(self::REMOTE_URL, $data);Die Production Deployment App übernimmt dann den dir- und jpa-Wert aus dem Request und beginnt mit der Erstellung der UNiTE-XML-Datei. Diesmal durch direktes Auslesen der Live-Seiten configuration.php Datenbankdaten. Dann ruft es die gleiche UNiTE unite.phar-Datei wie zuvor auf und stellt die Produktionsseite sofort wieder her.
Einfrierfunktionen
Die anderen beiden Funktionen: Freeze Clone und Freeze Live führen tatsächlich eine einfache Sperrung der Entwicklungs- bzw. Produktionsseiten durch, so dass die Anwendung keine Cloning- oder Wiederherstellungsprozesse durchführen darf, während diese aktiv sind.
Einfache Kommentare
Wir haben auch eine einfache Kommentarfunktion implementiert. Wann immer der Benutzer also die Entwicklungsseite aktualisiert, kann er/sie einen Kommentar hinzufügen, der beschreibt, warum die Seite aktualisiert wurde und an welchen Aufgaben er/sie arbeitet.
Das Ergebnis
Als das Werkzeug in die Praxis übernommen wurde, begann es sofort, unsere Produktivität positiv zu beeinflussen, da sich der Arbeitsablauf erheblich verbesserte.
Die Entwickler hatten mehr Freiraum beim Testen von neuem Code oder beim Debuggen auf Entwicklungsseiten. Fehler an den Produktionsseiten traten seltener auf oder konnten vollständig vermieden werden.
Die Entwickler hatten immer die neuesten Inhalte aus den Produktionsseiten und konnten neue Ergänzungen problemlos hinzufügen und testen. Dann kopierten Sie das Ganze schnell und einfach wieder zurück in die Produktionsseiten.
Die unmittelbare Auswirkung eines solchen Setups war für das Team von unschätzbarem Wert. Nach der ersten “ Eingewöhnungsphase “ äußerten sich fast alle Teammitglieder positiv über eine solche Veränderung ihres Arbeitsablaufs. Letztendlich waren wir alle verwundert, wie wir es überhaupt geschafft haben, unsere Arbeit vorher ohne ein solches Werkzeug zu erledigen.
Mögliche Stolpersteine
Da unser Tool über einen Webbrowser mit einem Webserver-Backend (Apache) läuft und UNiTE nicht direkt wie ein php-cli-Skript ausführt, gibt es ein paar Dinge, die man beim Aufbau eines solchen Systems beachten sollte..
- Verfügbarkeit der PHP-Systemaufruf-Funktionen wie exec(), shell_exec, system() etc. In einigen Hosting-Umgebungen ist es üblich, diese Funktionen zu deaktivieren, wegen ihrer potenziellen Auswirkungen auf die Sicherheit, falls sie nicht ordnungsgemäß verwendet werden.
- Php.ini’s max_execution_time Einstellung. Man sollte hier die Standardeinstellung ändern können, die für diese Sicherungs-/Wiederherstellungsfunktionen definitiv nicht ausreicht. Nach unserer Erfahrung dauerte der Cloning-Prozess auf einigen Seiten schnell länger als 2 Minuten.
Wenn einige dieser Punkte nicht erfüllt werden, wäre der Aufbau eines solchen, ähnlichen Systems von vorneherein eine Herausforderung.
Wird das für mich nützlich sein?
Dieser ganze Prozess und das Werkzeug als Produkt daraus war nur unsere Lösung für die Bedürfnisse, die irgendwann in unserem Entwicklungsprozess auftraten. Aber ich bin sicher, dass auch andere Entwickler von einem solchen System profitieren könnten. Vor allem (aber nicht ausschließlich), wenn sie eine Vielzahl von Joomla-Instanzen verwalten. Mit den Möglichkeiten von Akeeba UNiTE konnte mit geringem anfänglichen Aufwand eine schöne und intelligente Implementierungsumgebung aufgebaut und eingerichtet werden. Und das wird sicherlich positive Trends für Ihr Workflow-Ergebnis und Ihre Effizienz generieren.
Möchten Sie mehr erfahren? Bleiben Sie dran für unseren Artikel über die Zentralisierung von Ressourcen auf mehreren Joomla-Websites.
