Die Umgebung aufgeschrieben statt gemerkt

Jedes Team hat dieses Gespraech gefuehrt. Ein neuer Entwickler kommt, verbringt zwei Tage mit Installieren, und das Projekt meldet weiter einen Fehler, den niemand kennt. Derselbe Code laeuft auf einer Maschine und verhaelt sich auf einer anderen seltsam, und der Unterschied ist eine Bibliotheksfassung, eine Spracheinstellung oder ein Pfad, den jemand vor drei Jahren in ein Shell-Profil geschrieben hat. Das Wissen darueber, wie die Umgebung zu bauen ist, existiert, aber es lebt in Koepfen und in den Lesezeichen eines Veteranen, und damit besitzt eine Organisation es nicht wirklich.

Vagrants Antwort ist, dieses Wissen aufzuschreiben. Eine Konfigurationsdatei erklaert die Fassung des Systems, die weiterzuleitenden Anschluesse, die im Gast sichtbaren Ordner des Wirts und die Schritte, die beim ersten Start laufen. Aus dieser Datei wird die Umgebung gebaut: ein Befehl hebt die Maschine, ein Befehl meldet sich an. Die Umgebung ist nicht mehr das, was jede Person aus dem Gedaechtnis installiert, sondern das, was alle bekommen, weil es dieselbe Beschreibung ist.

Die Folgen reichen weiter als Bequemlichkeit. Reviews werden aussagekraeftig, weil die pruefende Person die Umgebung der meldenden exakt nachbauen kann. Einarbeitung ist keine muendliche Ueberlieferung mehr. Und die Frage, ob etwas auf einer sauberen Maschine laeuft, wird zu einem Befehl statt zu einer Debatte.

Einmal erklaeren, ueberall nachbauen

Das Kluge am Entwurf ist, dass er nichts neu erfindet. Die eigentliche Virtualisierung geht an eine reife Plattform darunter, sei es VirtualBox, VMware, Hyper-V oder ein Container-Rueckgrat, und Vagrants Aufgabe ist nur, Erklaerung in Handlung zu uebersetzen. Diese Trennung ist der Grund fuer ihr langes Leben: Als die Technik darunter besser wurde, erbte das Werkzeug die Verbesserung, ohne seine Oberflaeche zu aendern.

Ein oeffentlicher Katalog fertiger Abbilder sorgt dafuer, dass gaengige Systeme nicht von null gebaut werden muessen; man startet von einer vorhandenen Kiste und beschreibt nur die eigenen Abweichungen. Und weil die Konfigurationsdatei im Ablagefach neben dem Code liegt, bekommen Umgebungsaenderungen dieselbe Behandlung wie Codeaenderungen: einen Unterschied, eine Durchsicht, einen Eintrag und den Weg zurueck zu der Fassung, die lief.

Lehre profitiert von derselben Eigenschaft. In einem Kurs ist die Umgebung der Lehrperson und die der Teilnehmenden byteweise gleich, was eine ganze Klasse von Supportfragen beseitigt und die Sitzung ueber das Thema statt ueber die Installation fuehren laesst.

Ein praktischer Hinweis, der einen Nachmittag spart: Die Konfigurationsdatei ist ein Programm und verdient dieselbe Sorgfalt wie Code. Benennen Sie die Maschine nach ihrem Zweck und nicht nach einer Person, halten Sie die Einrichtungsschritte in einer eigenen Datei, die sich ueber Projekte wiederverwenden laesst, und binden Sie die Fassung des Abbilds, statt sie treiben zu lassen. Eine treibende Fassung ist der Grund, warum ein Bau im Maerz im September scheitert und die Ursache zwei Tage kostet.

Und noch etwas, das selten aufgeschrieben wird: Diese Datei ist auch Dokumentation. Wer neu ins Team kommt, liest sie und versteht, welche Dienste die Anwendung erwartet, welcher Port wohin geht und welche Schritte beim ersten Start passieren. Ein guter Teil der Architektur erklaert sich damit von selbst.

Der Beitrag von Vagrant ist, die Umgebung von einer muendlichen Absprache zu einer schriftlichen zu machen: Konfiguration als Code, Umgebung als nachbaubare Tatsache. Weniger Streit, ruhigere Lieferung.

Vernuenftig damit arbeiten

Drei Gewohnheiten. Die Konfigurationsdatei im Ablagefach halten und mit denselben Versionsnummern wie der Code entwickeln, damit Umgebungsaenderungen eine Geschichte und einen Rueckweg haben. Nicht mehr gebrauchte Maschinen regelmaessig entfernen, denn virtuelle Platten schrumpfen nicht, wenn man darin Dateien loescht, und ein Notebook fuellt sich schneller als erwartet. Und vor einem wichtigen Versuch einen Schnappschuss nehmen, denn die Maschine ist entworfen, um entbehrlich zu sein, und es gibt keinen Grund, mutig zu sein.

Fuer leichte Faelle, in denen eine ganze virtuelle Maschine zu schwer ist, passt ein Container besser, und beide koennen im selben Projekt nebeneinander bestehen. Wenn die Aufgabe aber wirklich ein vollstaendiges System mit eigenem Kern und eigenem Startvorgang braucht, bleibt dies der direkteste Weg, aus diesem System eine Beschreibung statt eines Nachmittags zu machen. Es ist kostenlos, laeuft auf den drei Plattformen und verlangt nur, dass man aufschreibt, was man ohnehin weiss.