Azure DevOps mag VB6 nicht
Totgesagte leben (leider) länger
Es ist schon eine Weile her, dass ich VB6 in Jenkins habe kompilieren lassen. Auch die Beschreibung dazu ist schon viele Monate her. Dass es immer noch VB6 Projekte gibt, hat sich allerdings nicht geändert. Und jetzt habe ich festgestellt: Azure DevOps mag VB6 nicht!
Aktuell arbeite ich mit Azure DevOps als CI Umgebung. Und um Suchenden nicht unnötig Hoffnung zu machen: nein, VB6 und Azure DevOps vertragen sich bei uns nicht. Aber das heißt ja nicht, dass man manuell kompilieren muss.
Woran es hapert
Bei dem Versuch VB6 auch mit Azure DevOps zu kompilieren bin ich allerdings auf einige Hürden gestoßen. Und irgendwann ist die Entscheidung gefallen, dass der Aufwand den Nutzen übersteigen würde. Und somit habe ich die Versuche eingestellt.
Einer der Dealbreaker waren die Kompatibilitäten von eben VB6 und Azure DevOps Agents. Denn während unsere VB6 Entwicklungsumgebung auf einem Windows 2008er Terminal läuft, möchte der Azure DevOps Agent gerne eine etwas aktuellere Betriebssystem-Basis.
Nebenbei, auch git wollte nur in einer alten Version installiert werden.
Die Alternative – kleine Brötchen
Ich möchte die notwendigen Schritte zum Erstellen der Setups aber nicht manuell durchführen. Also bleibt der kleine Freund des Entwicklers, die Batch.
Im Projektordner liegt also eine „compile.bat“ Datei, in der all die wiederkehrenden Schritte durchgeführt werden.
- Ausgabeverzeichnis löschen
- Ausgabeverzeichnis neu erstellen
- Kompilieren des VB6 Projektes ins Ausgabeverzeichnis
- Kopieren weiterer Abhängigkeiten oder vorbereiteter Dateien ins Ausgabeverzeichnis
- Aufruf von InnoSetup mit dem vorbereiteten Script
- Kopieren der erzeugten Setup Datei an den Ablageort im Netzwerk
Ist man fertig mit seinen Anpassungen, dann schließt man die VB6 IDE und startet einfach die Batch. Im Vergleich zum vorherigen manuellen Kompilieren und Verteilen der Binaries ist das schon ein guter Fortschritt und pragmatisch gesehen völlig ausreichend.
Fazit
Ja, es geht immer noch schöner. Für unser Team ist so aber eine gute Balance von Aufwand und Nutzen entstanden. Die Ressourcen, um den Prozess noch einfacher zu gestalten, stecken wir lieber in die laufende Ablösung der VB6 Projekte. Entsprechend zählen hier für mich auch kaum mehr Faktoren wie Code-Qualität. Ein Build der Qualitätsparameter wird hier also nicht benötigt. Es geht rein um die Vereinfachung des Deployments. Und das Ziel ist wenigstens erreicht.
