kirjoittaessani

Vor ein paar Wochen hatte ich von Gitzilla berichtet, das aus git-Commits automatisch Bugzilla-Kommentare generiert. Gestern ist mir eine neue Idee gekommen. Dazu muß ich aber etwas weiter ausholen.
Ein Rechencluster funktioniert ein bisschen wie eines von den ganz alten Rechenzentren. Dort hat man sein Programm in Form eines Stapels Lochkarten abgegeben. Wenn ein Rechner frei wurde, hat ein RZ-Mitarbeiter (Operator) den Stapel abarbeiten lassen, und das Ergebnis wurde vom Schnelldrucker ausgegeben, so daß man es sich später abholen konnte.
Heutzutage ist der Lochkartenstapel einer Datei gewichen, die Aufgabe des Operators hat eine Software namens Batch-System übernommen, und die Ausgabe landet statt auf dem Schnelldrucker auf der Festplatte -- aber das Prinzip ist gleich geblieben, interaktives Arbeiten wie auf dem PC am Arbeitsplatz gibt es hier nicht.
Unser Cluster ist meist bis zum Anschlag voll mit Jobs, aber gelegentlich sind doch einige Nodes frei -- besonders die älteren haben nicht immer voll zu tun. Weil Strom teuer ist,1 haben wir ein Lights-Out-Management, das unbenutzte Nodes abschaltet.2
Idealerweise sollte das vom Batchsystem erledigt werden, denn das ist die Instanz, die am besten weiß, welche Sorte Nodes wann in welcher Zahl benötigt wird. Die SGE kann das aber nicht, und so läuft bei uns ein externes System. Neben dem bloßen Ein- und Ausschalten nach Bedarf kann es auch noch ein paar weitere Sachen, zum Beispiel kann man defekte Nodes als "poweroff" markieren.
Das Lightsout-Management solche Nodes dann für neue Jobs, wartet ab, bis die aktuellen abgearbeitet sind, und schaltet die Node dann ab. Jetzt kann sich einer der Kollegen an die Reparatur machen -- wenn er merkt, das die Node aus ist.
Da wäre es doch schön, Lightsout und Bugzilla so zu integrieren, das eine Meldung über das Abschalten gleich in dem Bug erscheint, der für die defekte Node angelegt worden ist. Ich habe große Teile des heutigen Tages damit verbracht, eine sinnvolle Implementation dazu zu finden -- aber viel gebracht hat das nicht, außer, daß ich einiges über Web-Services gelernt habe. Die Kurzform geht ungefähr so: es gibt verschiedene Protokolle, z.B. JSON, REST, XML/rpc und SOAP. Leider unterstützt Bugzilla nur JSON und XML/rpc, für Ada habe ich aber nur eine Bibliothek für SOAP gefunden.3 Da ist wohl eine Eigenentwicklung angesagt. Look for me on Github. Mal sehen, wie aufwendig das wird.

1. typischerweise erreichen die Stromkosten über drei Jahre Dauerbetrieb den Anschaffungspreis [↩]
2. und bei Bedarf natürlich auch wieder an [↩]
3. Und REST? Mir schwirrt schon der Kopf [↩]

(Hinweis: der Artikel ist sicher leichter zu verstehen, wenn man sich die Grafik auf Vincents Seite daneben legt)

Nachdem ich Gitflow nun einige Zeit in mehreren Projekten verwendet habe, möchte ich noch ein paar Dinge berichten, die mir aufgefallen sind. Zur Erinnerung: Man benutzt mehrere Zweige,1 die nebeneinanderher laufen. Neben develop, auf dem die Entwicklung vorangetrieben wird, gibt es master, der nur veröffentlichte Versionen2 enthält, Feature-Zweige (auf denen größere Neuerungen entwickelt werden; ein Zweig pro Feature), Hotfixes3 und Releases.4

Man kann zwar mehrere Feature-Zweige gleichzeitig offen haben, um einen neuen Hotfix- oder Release-Zweig zu starten, muß der vorhergehende aber abgeschlossen werden. Das war zunächst etwas schwer verdaulich für mich, ist aber letztlich sicher sinnvoll: Releases folgen aufeinander, sie können nicht parallel laufen; eigentlich könnte man auch mit einem einzigen Release-Zweig leben, nur wird dann das Tagging schwieriger. Für Hotfixes gilt das nicht so eindeutig, aber git flow verwendet einen Hotfix-Zweig pro Version, nicht einen pro zu behebenden Bug.

Heute habe ich dann etwas Dummes gemacht: nachdem ich einige Zeit an Feature X gearbeitet hatte, habe ich ein paar Bugs in der Produktionsversion behoben -- ein klassischer Hotfix. Die git flow Tools sorgen dafür, daß diese Fehlerkorrekturen in develop und in den Releases auftauchen -- nur mein Feature-Zweig war weiter verbuggt. Was tun? Ich habe mich dafür entschieden, den Feature-Zweig mittels Rebase an der aktuellen develop-Version zu starten. Das war ein großer Fehler. Durch das Rebase gab es nämlich Diskrepanzen zwischen meinem lokalen Repository und der zentralen Version, die sich nicht leicht (und vor allem nur fehleranfällig) korrigieren ließen. Git flow bemerkt das auch und verweigert an viele Stellen gleich den Dienst. Ich habe es zwar hinbekommen, aber mein Commit-Graph ist ziemlich unübersichtlich geworden.

Lektion gelernt: man kann jederzeit Feature-Zweige nach develop Mergen,5 aber nicht umgekehrt. Die letzten Bugfixes sind bei einer reinen Entwicklerversion oft auch überflüssig; und wenn man sie wirklich braucht, ist wahrscheinlich Cherry-Picking die beste Methode.

Übrigens hat git eine unangenehme Eigenschaft, die mich überhaupt erst in diese missliche Lage gebracht hat: Man kann die Geschichte umschreiben (rewriting history), i.e. es gibt git-Kommandos, die nicht nur neue Vertizes zum Commit-Graphen hinzufügen, sondern bestehende Vertizes löschen oder ändern. Das widerspricht meinen Erwartungen an ein Versionskontrollsystem sehr, es liegt aber wohl im Konzept der verteilten Repositories, und ließe sich nur mit schweren Nachteilen ausschließen.

1. Branches [↩]
2. oder zumindest solche, die man veröffentlichen könnte [↩]
3. schwerere Bugs, die zwischendurch behoben werden müssen [↩]
4. Feinschliff zur nächsten Version [↩]
5. ich schrieb ja schon, daß man diese Begriffe nicht sinnvoll übersetzen kann [↩]

Das Versionskontrollsystem git habe ich ja schon gelegentlich erwähnt. Heute ist mir aufgefallen, daß git bei aller Komplexität und Mächtigkeit dadurch, daß sich Repositories so einfach einrichten lassen, auch wunderbar leichtfüßig1 ist. Früher2 habe ich echte Versionskontrolle3 nur für größere Softwareprojekte verwendet, kleinere Projekte habe ich allenfalls mit RCS verwaltet.

Derzeit stecke ich mehr und mehr auch Kleinkram in git: Konfigurationsdateien -- früher mehr schlecht als recht in RCS4 -- lassen sich so wunderbar handhaben. Ganz nebenbei bietet git auch noch eine Art Deployment: ich kann auf meiner Maschine entwickeln und dann einfach auf den Server, den ich eigentlich konfigurieren will, klonen. So bleiben alle Projekte und Projektchen schön übersichtlich beisammen; und dank Gitzilla ist auch für eine sinnvolle Dokumentation gesorgt.
Das einzige, was ich jetzt noch vermisse, ist eine gute und universelle Testumgebung: irgendetwas, das für ein neues Projekt keiner aufwendigen Neukonfiguration bedarf, das aber das Testen von neuen Konfigurationen ermöglicht, bevor sie auf den Produktionsserver geschoben5 werden.

1. lightweight [↩]
2. ^TM [↩]
3. z.B. CVS [↩]
4. oder gar nicht verwaltet [↩]
5. deployt? deployed? [↩]

Erkenntnis des Tages: Gitflow macht Spaß!

Außerdem fange ich an, ein zweites kürzlich entdecktes Werkzeug regelmäßig zu nutzen: Gitzilla. Das ist -- man ahnt es fast -- eine Git--Bugzilla-Integration. Nach der Installation läuft Gitzilla unsichtbar im Hintergrund. Wenn man nun in einem Git-Commit-Text eine Bugnummer aus dem angeschlossenen Bugzilla erwähnt, dann erscheinen automatisch Informationen zu diesem Commit als Kommentar in dem Bug.
Das ist sehr praktisch, um eine Gesamtdokumentation zu erstellen (statt Bugzilla und Git-Historie nebeneinander her laufen zu lassen)

Wer mag, kann die Bugnummer sogar erzwingen, aber für mich als Einzelkämpfer ist das übertrieben.

Zum Schluß noch ein kleiner Tipp für alle, die es selbst ausprobieren möchten: Gitzilla wird beim Push in ein (zentrales) Repository aktiv, nicht schon beim lokalen Commit. Das steht zwar in der Dokumentation, ich habe mich zunächst aber trotzdem gewundert, als nichts passiert ist. Diese Repositories habe ich mit mit --shared --bare in /home/git auf meiner Maschine angelegt, so sind sie zwar mir zugeordnet, aber trotzdem von meinen eigenen Daten getrennt.

Jeder weiß, daß man Dokumente, in denen viel Hirnschmalz in wenig Text verpackt ist1, in einem Revision Control System hält. Ich habe früher CVS für größere Projekte und RCS für Kleinkram2 verwendet.

For ein paar Jahren bin ich dann auf git umgestiegen: Neben dem einfachen Einrichten des Repository3 macht vor allem das leichte und schnelle Branchen Spaß. Zugegeben, git hat auch seine Schwächen, und die Bedienung ist nicht immer einfach4.

Trotzdem überwiegen in meinen Augen zumindest gegenüber SVN und CVS (und natürlich RCS) die Vorteile. Vor ein paar Tagen bin ich zufällig über einen Blog-Eintrag von Vincent Driessen gestolpert, der dem Werkzeug git sozusagen als Überbau noch einen Prozeß oder einen Satz Richtlinien hinzufügt -- Anweisungen, wann man welche Branches erzeugen soll, und wohin sie gemerget werden. Das Modell gefällt mir auf Anhieb recht gut, und weil es dazu auch ein Tool gibt, das das Einhalten des Prozesses stark vereinfacht, werde ich meine Repositories demnächst wohl nach und nach umstellen.

Vincents Modell hat natürlich auch Kritiker, und wer tiefer einsteigen will, sollte sich die Diskussion zu Jeffs Blog-Eintrag durchlesen. Wahrscheinlich am meisten nachgedacht hat Adam Dymitruk. Die Feinheiten seines Modells sind für mich zu dieser späten Stunde definitiv zuviel, aber mir gefällt die Idee, Feature Branches unabhängig zu halten, so daß man jedes Feature jederzeit wieder ausbauen kann.5

Edit: HTML an falscher Stelle
Edit 2: Typo

1. z.B. Source Code und Konfigurationsdateien [↩]
2. z.B. Dateien aus /etc [↩]
3. ja, ich benutze normalerweise auch lieber deutsche Begriffe, aber heute lasse ich das aus gutem Grunde mal sein: wenn man gut eingeführte termini technici übersetzt, versteht am Ende niemand etwas [↩]
4. manche Kommandos muß ich heute noch immer wieder nachschlagen, checkout -b vergesse ich regelmäßig, wenn ich es nicht oft genug benutze [↩]
5. jedenfalls bis zum nächsten Release [↩]