WIP: Warum hat U7 so lange gedauert?
Diese Frage müssen wir uns unweigerlich stellen lassen, nachdem es nach außen vielleicht zeitweise so wirken konnte, als sei U7 unser Half Life 3 - und wir haben selbst viel zu diesem Eindruck beigetragen, durch Zeitprognosen, die im Nachhinein lächerlich daneben lagen, und auch durch den Umstand, nicht schon viel früher mit einem viel kleineren Featureset an die Öffentlichkeit zu gehen und die kontinuierliche Weiterentwicklung des Produkts damit viel sichtbarer zu machen. Diesen Schuh ziehen wir uns an, und das machen wir künftig anders - soll heißen, besser.
Zugegeben: Wir haben selbst viel lernen müssen - und das betrifft am allermeisten die Abschätzung der Entwicklungsdauer. Aber wir wollten nicht einfach nur ein nächstes Release bauen und im Grunde alles, was wir auf Basis von CentOS 6 gebaut hatten, mal eben auf CentOS 7 hieven (was ungefähr das ist, was wir beim Schritt von CentOS 5 auf CentOS 6 gemacht haben). Wenn ihr wüsstet, wie unfassbar groß das dicke Bündel an Shellscripts geworden ist, mit dem wir in der Vergangenheit Hosts installiert haben; wie viele manuelle Schritte involviert waren; wie viele Inkonsistenzen wir oftmals nachträglich ausbügeln mussten; … das möchten wir heute eigentlich niemandem mehr guten Gewissens zeigen.
Tatsächlich mag sich aus Usersicht U7 gar nicht sooo viel anders “anfühlen” als U6, und das ist ja auch erstmal gar nicht schlecht bzw. auch so gewollt: Auch wenn da viel Neues drinsteckt, soll man sich ja auch ein bisschen Zuhause fühlen und nicht alles komplett neu lernen müssen. Wenn es aber darum geht, wie wir U7 bauen, so liegen zwischen früher und heute regelrecht Lichtjahre. Wo das Deployment eines Features früher “Ich lass da mal pssh auf die bestehenden Hosts los, und dann bau ich noch ein Shellscript, was das auch bei neuen Hosts macht, und notiere das in der README zum Aufsetzen neuer Hosts” war (was dann oft genug erstmal noch schiefging und wir auch mit einer guten Portion Glück ausgestattet waren, dass nicht viel mehr viel öfter geknallt hat), so haben wir heute einen runden Prozess, bei dem ein Feature als User Story definiert wird, Tests geschrieben werden, ein Branch angelegt wird, ein Continuous-Integration-System bei jedem Merge Request einen kompletten Host deployt und testet, wo Code Review und Approval passieren, wo das Anlegen von Hosts und das Deployment von Änderungen auf bestehende Hosts idempotent mit exakt dem gleichen Ansible-Playbook passiert, und wo sich das Aufsetzen eines neuen Hosts im Grunde darauf beschränkt, ihn im Ansible-Inventory einzutragen, einen Knopf zu drücken und einen Kaffee zu trinken. Wir bauen die Hosts nicht mehr; wir entwickeln vielmehr die Baupläne und lassen bauen.
Gleichzeitig haben wir auch die über die Jahre gewachsene Dokumentation komplett neu aufgebaut: Neue Features im Development werden zu Issues in der Dokumentation; sie wird automatisiert zusammengebaut, auch hier mit Branches; die Versionierung der Dokumentation folgt der Versionierung der Hosts - stabile Hosts haben stabile Dokumentation; Entwicklungs-Hosts mit beispielsweise neuen Features haben Entwicklungs-Dokumentation. Auf diese Weise ist auch sichergestellt, dass die Feature-Entwicklung eng verzahnt mit dem Support stattfindet und wir Situationen ausmerzen, in denen “irgendjemand irgendwas deployt” und der Support weiß noch gar nichts davon.
Das mag alles ein wenig enterprisy klingen. Aber vertraut uns bitte und seht’s angstfrei: Wir sind immer noch weitestgehend die gleichen Leute (eher ein paar mehr - Dank euch!); wir haben nur in der Zwischenzeit viel - enorm viel - dazugelernt und im Grunde den Schritt vollzogen, ein ziemlich komplexes und mit den Jahren gewachsenes System, solange wir es noch überblicken konnten, einmal zurück ans Reißbrett zu bringen und sauber neu zu bauen, bevor es unwartbare Zustände erreicht - zu unser aller Wohl, denn von einer Hostingplattform, für die wir intern die Qualitätsmaßstäbe an unsere eigene Entwicklung massiv nach oben geschraubt haben, profitiert am Ende ja vor allem ihr. :-)