Butler – den Hoteliers jederzeit zu Diensten

Doch zunächst zur Entstehungsgeschichte. Die Idee entstand in einem Workshop mit Flying Circus. Zwei Erkenntnisse haben wir dort mitgenommen, die federführend für die Entstehung von Butler sind:

• Standardisieren, standardisieren, standardisieren.
• Wenn der neue Weg dem Entwickler nicht direkt mehr Arbeit abnimmt und einfacher ist, dann wird er auch nicht gegangen.

Durch Drupal 8 mussten wir unseren Entwicklungsablauf radikal ändern. Weg von Entwicklungsservern, weg von gemeinsamen Working Copies, hin zu lokalen Installationen. Damit kamen auf jeden von uns zusätzliche Arbeitsschritte zu, die wir sonst zentral vorbereitet haben:

• Die notwendigen Dienste installieren und korrekt konfigurieren.
• Die Arbeitskopien lokal auschecken.
• Die CMS-Installationen durchlaufen lassen.

Da wir sicherstellen wollten, dass es keinen Wildwuchs in der Konfiguration gibt (um dem „works on my machine“ Argument entgegenzuwirken), wollten wir die Konfiguration der notwendigen Software nicht jedem einzeln überlassen. Und natürlich weil einige von uns keine große Lust haben würden, sich in diese Thematik einzuarbeiten. Also musste ein Tool her, das einfach zu installieren ist und sich um diese zusätzlichen Arbeiten kümmert – sprich: den neuen (komplexeren) Arbeitsablauf einfacher macht als den bisherigen.

So ist Butler entstanden. Das erste, was Butler können sollte, war also die Automatisierung von Konfiguration. Konkret: Den Code für ein Projekt besorgen, ihn an einer definierte Stelle ablegen sowie eine virtuelle Maschine erzeugen und konfigurieren. Dabei haben wir uns auch bestehender Software bedient: Git für die Versionierung (was eh längst im Einsatz war) und Vagrant für die Verwaltung der virtuellen Maschinen.

Keines unserer Projekte kommt üblicherweise ohne Datenbank daher. Also war der zweite Befehl von Butler ebenfalls schnell umgesetzt: die Datenbank einer bereits laufenden Produktionsseite herunterladen und in die virtuelle Maschine importieren.

(R)evolution

Schritt für Schritt ist Butler inzwischen gewachsen und hat dabei seine Ausrichtung verändert und weiter ausdifferenziert. Zunächst war es als Tool für lokale Entwicklung gedacht. Inzwischen ist es ein Multifunktionswerkzeug, das die meisten von uns mehrfach täglich verwenden, um diverse Arbeitsabläufe zu vereinfachen.

Ein Beispiel: Zunächst war nicht angedacht, die notwendigen CSS-Compiler in Butler zu integrieren. Es wurde jedoch schnell klar, das wir sehr viel davon haben, diese ebenfalls in Butler einzubauen: Nun können wir sicherstellen, dass alle am Projekt beteiligten Personen die gleichen Versionen der jeweiligen Compiler installiert haben. Und statt dass wir uns neue Befehle merken zu müssen, lernte Butler einfach ein zusätzliches Verb.

Wobei Butler uns die Arbeit erleichtert

Die Featureliste ist inzwischen recht beeindruckend:

• Lokale Projektverwaltung (Projekte anlegen, löschen)
• Selbst-Update
• Datenbank-Operationen (download, copy, upload)
• Zugriff auf die Errorlogs (auch auf Logs in der Produktion)
• SSH-Sitzungen zu den Produktionsservern eröffnen
• CSS-Kompilierung
• Drupal 8 Konfigurationsexport und -import
• Unterstützung beim Anlegen von Branches

Es gibt noch zwei Goodies, die in der Featureliste gerne untergehen: Butler kann Sequel Pro vorkonfigurieren. So kann man sehr schnell Datenbankverbindungen für Diagnosezwecke herstellen ohne sich mühsam die Zugangsdaten besorgen zu müssen. Und dann gibt es noch einen Befehl, der bei Eingabe des internen Servernamens verrät, welches Projekt dort gehostet ist. Das ist sehr hilfreich in Zusammenarbeit mit unserem Hoster Freistil.

Um uns Hoteliers all diese Arbeit abnehmen zu können, muss Butler über alle Projekte einiges wissen. Daher ist im Zuge von Butler auch eine sehr minimale Projektverwaltung entstanden, in der alle für Butler notwendigen Informationen hinterlegt sind: Das zentrale Code-Repository sowie die Serverinformationen für Stage und Production. Und natürlich das Projektkürzel.

Unter der Haube

Technologisch ist Butler auch spannend: Der Code ist in Swift geschrieben und wird per Installationspaket installiert. Da sich Butler selbst aktualisieren kann, ist dieser Schritt nur einmal notwendig.

Swift deshalb, weil dabei die Installationshürde (und die Vergleichbarkeit der einzelnen Systeme) am Besten gegeben ist. Bei PHP wäre beispielsweise nicht sicher, ob alle Rechner die gleiche PHP Konfiguration fahren. Swift hat einen weiteren Vorteil: Butler ist dadurch sehr flott! Es vergeht kaum Wartezeit beim Ausführen von Butler-Befehlen. Es sei denn, Butler muss für den jeweiligen Befehl noch auf ein anderes Tool (wie Vagrant) zurückgreifen.

Nach zwei internen Workshops zum Einsatz mit Butler ist inzwischen jeder Hotelier firm darin, das Tool in seine Arbeit zu integrieren. Sogar einer unserer Freelancer ist auf den Mac gewechselt, um Butler verwenden zu können. Das interne Feedback ist durchweg positiv.

„Butler ist wohl das tollste was mir beruflich dieses Jahr begegnet ist.“ (Edward)

Wir überlegen inzwischen, Butler soweit von unseren individuellen Firmenstrukturen zu entkoppeln, dass wir das Projekt unter Open Source Lizenz veröffentlichen können. Gleichzeitig ist es spannend zu sehen, welche „Tricks“ unser Butler noch erlernen wird in der nächsten Zeit. Ich glaube, die Reise hat gerade erst begonnen.