So verläuft der Prozess einer Änderung an der Baustatik

Im Rahmen der Softwareentwicklung finden bei uns einige Prozesse statt, die meiner Ansicht nach ganz interessant sind: Darum hier eine kurze Beschreibung des Ablaufs.

Gearbeitet wird grundsätzlich im Visual Studio. Alle Quellcode-Dateien (der Baustatik, wir haben aber auch noch andere Projekte, zum Beispiel die der Webseite) sind dabei auf knapp 100 Projekte einer Visual Studio "Solution" verteilt.

Nach jedem Änderungsschritt wird die Änderung in unser Revision-Control System (wir verwenden Visual Studio Online mit TFS) "eingecheckt" – das bedeutet, die Änderung respektive die geänderte Datei landet in der Datenbank des RCS.

Das hat mehrere Konsequenzen: Zum einen sind ab diesem Zeitpunkt die neuen Änderungen auch für alle anderen im Team erreichbar – zum anderen löst dieser Vorgang einige andere Prozesse aus.

Handelt es sich bei der eingecheckten Datei um einen übersetzbaren Quellcode – also ein Teil des "Baustatik" Programms in von Menschen lesbarer Form – dann führt das auf einem unserer Server automatisch dazu, das eine neue Version der Baustatik hergestellt wird. Diese Version enthält dann bereits die Änderung: Wenn der Herstellungsprozess klappt, dann ist sichergestellt, das durch die Änderung zumindest formal nicht "kaputt gemacht" wurde.

Wenn doch irgendwas dabei nicht klappt, dann kann man auch gleich nachsehen, was das war:

Ging alles glatt, dann wird hinterher ein Testdurchlauf angeworfen. Der läuft auf einem anderen unserer Server – der lustigerweise in der Küche unseres Münchner Büros steht. Egal an welchem Standort die Änderung durchgeführt wurde – der Testlauf findet immer in der Küche in München statt.

Beim Testlauf werden einige Tausend Baustatik-Dokumente neu berechnet und die Ergebnisse dieser Berechnung werden mit Referenz-Ergebnissen verglichen. Wenn alles OK ist, dann dürfen die "neuen" Ergebnisse natürlich nicht von den Referenzen abweichen. Das Resultat dieses Testlaufs wird dann an alle Beteiligten per Email verteilt aber auch über eine interne Webseite veröffentlicht.

Trat ein Fehler auf, dann kann man den auch sofort anzeigen lassen, natürlich mit Details, die den Fehler genau beschreiben.

Handelt es sich aber nicht um eine Quellcode-Datei, sondern um einen Teil der Dokumentation zum Programm, die ja auf der Webseite verfügbar ist, dann passiert ein bisschen etwas anderes.

In einem solchen Fall wird ein Prozess in unserem Azure-Cluster ausgelöst: Dieser Prozess holt dann die geänderte Datei aus der Quellcode-Verwaltung ab, bringt sie in das richtige Format für den Webserver und kopiert sie dann an die passende Stelle im Webserver – dadurch ist die Dokumentation immer auf dem neuesten Stand. Ganz ohne das einer der Dokumentierenden irgendwas dafür tun muss.