Kann man bei euch eigentlich…

Ein Klassiker im Support ist die Frage, ob und wie man bei uns Dinge wie Wordpress, Ghost, Nextcloud, (…) möglichst einfach installieren kann. Die Antwort ist meistens “klar geht das, wir haben das im Wiki verlinkt oder schau doch mal bei der Suchmaschine deiner Wahl.” Viele von euch schreiben Anleitungen für die Installation, die dann aber irgendwo veröffentlicht werden müssen. Wir haben da bisher immer darum gebeten, im Zweifelsfall selbst eben einen Blog aufzusetzen oder den Artikel als Gastbeitrag in einem anderen Blog zu veröffentlichen. Das hat natürlich Grenzen und nicht jeder hat Lust und Zeit dazu, für eine einzelne Anleitung gleich einen eigenen Blog aufzusetzen. Das ist mehr als verständlich und so verstaubt sicherlich die eine oder andere Anleitung unveröffentlicht auf lokalen FestplattenSSDs. Das muss doch irgendwie anders gehen…

Moin zusammen! Gehen wir gleich ans Eingemachte. Im letzten Blogartikel schreiben wir:

Zwar ist Uberspace 7 nicht feature complete, aber so gut wie „fertig“ genug, um es endlich für Euch aufzumachen. Das heißt, wir spucken nun nochmal ordentlich in die Hände, gehen Montag in den letzten, zweiwöchigen Sprint und dann… machen wir erst nochmal Urlaub und erholen uns ordentlich. 🌴😎

Die Entwickler unter euch werden wissen: Der letzte Sprint ist nie der letzte und so mussten wir natürlich auch hier (was ETAs angeht hätten wir eigentlich aus der Vergangenheit lernen müssen…) noch mal das Skalpell ansetzen und aus einem Sprint mehrere machen.

Update 18.01.2017

Der erste Server ist (voll automatisch) aufgesetzt, alle Kollegen haben einen Account, schauen sich um und finden (und beheben) gerade die ersten Bugs. Die letzten grundlegenden Funktionen sind (oder werden gerade) implementiert und in ein paar Tagen trauen wir uns, die ersten User auf das System zu lassen. Wir haben bereits eine Hand voll Tester rekrutiert und werden diese Gruppe langsam vergrößern. Auch hier wird dann zu gegebener Zeit ein Update erfolgen, in dem wir euch die Möglichkeit geben, einen Account zu testen.

Es geht [gut voran] 1, mit unserer neuen Arbeitsweise sind wir inzwischen gut vertraut und sie ist uns in Mark und Bein übergegangen. Wir wollen euch nun mal kurz unsere Bürotür öffnen und euch zeigen, woran wir gerade arbeiten und wie die nähere Zukunft aussieht.

Wir tauschen unser HTTPS-Frontend aus

Inzwischen ist es spruchreif: Wir tauschen unser HTTPS-Frontend aus. Bisher haben wir auf [Pound] 3 gesetzt, mit Uberspace 7 setzen wir auf [nginx] 4. Das bringt folgende Vorteile:

From stateful to stateless - the whole enchilada

Bei Uberspace habt ihr die Möglichkeit, eure eigenen Domains aufzuschalten, Ports in der Firewall zu öffnen und Zertifikate einzutragen. Bei all diesen Aktionen interagiert ihr mit Konfigurationsdateien, auf die ihr eigentlich keinen Zugriff habt - mit dem Webserver, unserem HTTPS-Frontend und der Firewall.

In Uberspace 7 - Episode 2 haben wir das Thema Tests angerissen:

Nachdem Features definiert wurden sollte man anfangen, Tests zu schreiben und damit die Anforderungen an die Features genau definieren.

Aber wie sieht so ein Test eigentlich aus? Beispiel: Jeder User bekommt mit seinem Account eine Mailbox, die er mit seinem SSH-Kennwort abrufen kann. Ein Test dafür würde folgendermaßen aussehen:

1. Einen User auf dem Server anlegen
2. Ein SSH-Passwort setzen
3. Eine Mail an User schicken
4. Der User loggt sich per IMAP ein
5. User holt Mail 1 per IMAP ab (Es kann nur eine Mail da sein, der User ist ganz frisch angelegt und das Postfach war vor der Testmail leer)
6. Wir überprüfen den Inhalt der Mail auf einen bestimmten String
7. Profit!

Diesen Test haben wir mit Ansible realisiert. Und jetzt mal Butter bei die Fische, so sieht das in Code aus: Die Variablen testuser und dummypassword haben wir bereits an anderer Stelle definiert, in ansible_fqdn steht der Hostname des Servers. <{{ testuser }}@{{ ansible_fqdn }}> ist also die E-Mail-Adresse des Testusers.

Die Phasen der Entwicklung

… und was wir anders machen würden, wenn wir nochmal von vorne anfangen würden.

Die Sache mit den ETAs

Eines unserer Grundprinzipien ist: Wir geben keine ETAs. Features kommen, wenn sie fertig sind und nicht zu versprochenen Zeitpunkten. Wir sind der Meinung, dass es nicht gut sein kann, unter Zeitdruck an etwas zu arbeiten und sind fertig, wenn wir eben der Meinung sind, dass wir fertig sind; wenn wir soweit hinter unserer Arbeit stehen, dass wir sie vertreten können und gut finden. Wir haben kein Venture Capital und keine Abteilung im Rücken, die darauf pocht, neue Features schnellstmöglich und unpoliert auf den Markt zu werfen und profitabel zu machen. Daher nehmen wir uns die Zeit, die wir eben brauchen und finden diese Herangehensweise richtig und wichtig. Allerdings haben wir bei einer Sache mit diesem Grundprinzip gebrochen und das ist Uberspace 7. Unser erster ETA war Ende 2015, dann war es Anfang 2016. Jetzt haben wir daraus gelernt und wollen euch in einer Reihe von Blogeinträgen ein wenig an unserem Lernprozess teilhaben lassen und erklären, warum das alles (gefühlt) so schrecklich lange dauert. Aber erst mal ein Schritt zurück: Uberspace 7?

Eines der (wenigen) Dinge, die ich von meinem Studium mitgenommen habe ist: Was mehr als zwei mal getan werden muss, sollte automatisiert werden. Und damit geht es wohl in keiner Branche so sehr darum, sich selbst abzuschaffen, wie in unserer. Nach dem automatisiertem Zertifikatsimport haben wir uns natürlich nicht zurück gelehnt und die Füße baumeln lassen, sondern die durch die weggefallenen Supportanfragen gewonnene Zeit genutzt, um munter weiter in die Tasten zu hauen. Et voilà: Jetzt ist es soweit. Es hat sich ein bisschen etwas getan hinter den Kulissen: