Continuous Deployment mit TYPO3 Surf Step by Step

Als Ergänzung zu dem bereits veröffentlichten Artikel Deployment mit TYPO3.Surf ist dieser Artikel zu verstehen. Es geht hauptsächlich um den grundsätzlichen Systemaufbau. Automatisches Deployment wird immer beliebter. Das hängt zum einen damit zusammen, dass die Tools einfacher werden und die Abhängigkeiten die eine Webapplikation mitbringt steigen. Im PHP Umfeld leistet composer (https://getcomposer.org) als Dependency Manager großartige Arbeit. Composer reicht allerdings in manchen Fällen nicht aus um eine Applikation auf dem Server zu aktualisieren, da evtl. noch ein Cache gelöscht werden soll oder die Datenbank aktualisiert werden muss.

Bei der Verwendung von TYPO3 Applikationen, egal ob Neos oder Flow habe ich bereits gute Erfahrungen mit TYPO3.Surf gemacht. Für TYPO3 CMS habe ich TYPO3.Surf noch nicht eingesetzt, jedoch sollte auch das möglich sein.

Aufbau der Systemumgebung

Ich entwickele lokal auf dem MacBook. Ich habe ebenfalls lokal einen Webserver sowie eine Datenbank installiert. Das könnte z.B. XAMPP sein. Der Quellcode liegt in einem GIT Repository. Daneben habe ich einen Testserver welcher aus dem Internet erreichbar ist. Das ist zur Zeit eine virtuelle Maschine auf einem zweiten Rechner der hier im Büro steht. In der Fritz Box sowie in Virtualbox habe ich die Ports so weitergeleitet, dass man von außen auf die virtuelle Maschine kommt. Damit ich nicht alle 24 Stunden eine neue IP Adresse herausgeben muss habe ich außerdem einen DynDNS Service genutzt. Meine Fritz Box ist so konfiguriert, dass diese den DynDNS Service über neue IP Adressen informiert.

In der virtuellen Maschine habe ich einen Apache Webserver installiert und konfiguriert. Außerdem ist dort eine Datenbank installiert. Die notwendigen Abhängigkeiten die meine Applikation noch mitbringen habe ich dort ebenfalls von Hand installiert. Da ich nicht eine zweite virtuelle Maschine dauerhaft auf dem Server laufen lassen wollte habe ich zusätzlich noch TeamCity installiert.

TeamCity ist ein Continuous Integration Server von Jetbrains. Auf die Konfiguration und genauen Funktionen von TeamCity werde ich in einem gesonderten Artikel eingehen.

TYPO3.Surf ist ebenfalls auf dem Server installiert. Dazu habe ich in einem Ordner der nicht aus dem Internet erreichbar ist ein TYPO3 Flow installiert. Die genauen Schritte hierzu habe ich in dem Artikel Deployment mit TYPO3.Surf beschrieben. Die Installation von TYPO3.Surf liegt also in meinem Fall auf dem selben Server wie die Webseite. Dies ist jedoch nicht unbedingt erforderlich. Der Server auf dem die Webseite läuft muss lediglich von dem Deployment Server erreichbar sein. Im Idealfall liegt ein SSH Key des Deployment Servers auf dem Webserver so dass die Authentifizierung mittels Public/Private Key stattfindet.

Ablauf Deployment

Wie läuft jetzt so ein Deployment auf den Webserver ab. Ich führe einen Commit in meiner IDE aus und Pushe die Änderungen zu Bitbucket. Ich arbeite mit Bitbucket, da es dort beliebig viele private Repositorys gibt solange die Teams nicht zu groß werden.

Der TeamCity Server ist so konfiguriert, dass er bei Änderungen im GIT ein Deployment ausführt. Ein Deployment heißt in diesem Fall, dass ein Shell Skript ausgeführt wird. Der Inhalt des Shell Skriptes ist der folgenden:

cd /home/smeier/surf
./flow surf:deploy mein-deployment

Es wird also in dem Verzeichnis gewechselt in dem das Deployment TYPO3 Flow installiert ist. In diesem Verzeichnis wird das Deployment durchgeführt. Dabei wird automatisch die Datenbank aktualisiert und der Cache gelöscht und beliebige weitere Dinge geändert die noch in der Deployment Config von TYPO3.Surf geändert werden.

Der Einsatz von TeamCity hat den Vorteil, dass ich noch weitere automatischen Tasks vor dem eigentlichen Deployment durchführen kann. Das können z.B. automatisierte Tests oder Code Analysen sein. Wie das genau funktioniert und was sonst noch alles möglich ist, werde ich in einem späteren Artikel beschreiben. Da stehe ich teilweise auch noch am Anfang und muss das selber erst einmal genau verstehen.

 

TYPO3 Neos vs. TYPO3 CMS

Was sind die Unterschiede zwischen Neos und CMS. Beides sind Produkte unter dem Label TYPO3. Ursprünglich war der Plan, dass Neos nach Fertigstellung das CMS ablösen sollte. Dieser Plan ist gescheitert und beide Produkte werden nach wie vor noch weiter entwickelt. Zum aktuellen Zeitpunkt ist die Oberfläche von Neos beeindruckender und intuitiver für Redakteure zu bedienen.

Aus der offiziellen Demo von TYPO3 Neos stammt der folgende Screenshot.Bildschirmfoto 2015-05-03 um 20.57.37

zum Vergleich dazu hier ein Screenshot aus der Version 7.1 vom TYPO3 CMS.Bildschirmfoto 2015-05-03 um 21.00.16
Beide Demo Versionen sind über http://demo.typo3.org erreichbar.
Leicht zu erkennen ist, dass man bei Neos das Frontend sieht und die Backend Elemente nur darüber gelegt sind. Auch das bearbeiten von Inhalten erfolgt direkt im Front/Backend. Die neue Version von TYPO3 CMS erinnert immer noch stark an die vorherigen Versionen, auch wenn das Backend deutlich moderner aussieht.

Die Hürde sich in Neos einzuarbeiten sollte man als Entwickler jedoch nicht unterschätzen. Gerade wenn es etwas anspruchsvollere Aufgaben zu meistern gilt als nur Inhalt anzuzeigen kann es mit viel ausprobieren verbunden sein bis die richtige Lösung gefunden wird. Hilfreich ist es sicherlich wenn man sich vorher schon einmal mit TYPO3 Flow beschäftigt hat, das Framework auf dem TYPO3 Neos basiert.

TYPO3 CMS kann auf eine Vielzahl an Plugins, sowie den Extension Manager, zur einfachen Installation verweisen. Dagegen gibt es im Neos Projekt keinen Extensionmanager. Eventuelle Plugins bzw. Erweiterungen müssen als abhängige Pakete in der composer.json hinterlegt und über composer installiert werden. Viele Funktionen für die man unter TYPO3 CMS ein Plugin benötigt kann man in Neos jedoch von Haus aus realisieren. Ich habe gerade in einer Installation von TYPO3 CMS nachgesehen und die Extensions:

  • Formhandler
  • Realurl
  • Gridelements

werden neben einigen Kundenspezifischen Extensions dort genutzt. Ich denke viel mehr Erweiterungen habt ihr auch nicht im Einsatz. Ich vergleiche das jetzt einmal und schaue wie ich diese Dinge mit Neos realisieren würde. Schöne URLs liefert Neos von Haus aus und auch für die Darstellung von externen Daten besteht die Möglichkeit schöne URLs zu erzeugen. Formulare kann Neos auch mehr oder weniger von sich aus. Dazu wird das Paket TYPO3.Form verwendet, welches in einer Standardinstallation automatisch mit installiert wird. Bleibt Gridelements als Extension, auch diese Funktion kann man mit Neos ohne eigenes Plugin realisieren. Dazu muss nur ein entsprechender NodeType konfiguriert werden, welcher entsprechend weitere ChildNodes konfiguriert hat. Die Funktion für die ich bei TYPO3 CMS noch Plugins benötigte sind bei Neos von Haus aus dabei.

Die Entscheidung TYPO3 Neos oder TYPO3 CMS kann man immer nur selber treffen, jedoch ist Neos meiner Meinung nach inzwischen so weit, dass es sich definitiv lohnt einen Blick darauf zu werfen. Ich werde in den nächsten Tagen und Wochen weitere Artikel veröffentlichen die sich mit dem ein oder anderen Problem bei Neos oder auch bei CMS beschäftigt.

Deployment mit TYPO3.Surf

Ich habe mich in den letzten Wochen mit den Einstellungen und der Konfiguration von TYPO3.Surf beschäftigt. Geplant war schon viel eher ein weitere Artikel in dieser Reihe, jedoch ist durch einen Umzug und weitere Projekte einfach nicht die Zeit dazu vorhanden gewesen. Aber nun geht los. Step by Step Continous Deployment mit TYPO3.Surf.

Als erstes benötigen wir eine frische Installation von TYPO3.Flow. Eine Installationsanleitung habe ich hier niedergeschrieben: TYPO3.Flow installieren

In diese Installation installieren wir als nächstes TYPO3.Surf. „Deployment mit TYPO3.Surf“ weiterlesen