Alte VB6 Projekte in CI/CD wie Jenkins?

VB6 nicht tot zu kriegen

Es ist schon etwas her, dass ich ein paar Snippets gesammelt habe um diesen Artikel zu schreiben. Dann lag die Idee aber eine ganze Zeit auf Eis. VB6 dümpelt in meiner Wahrnemung nur noch in Legacy Projekten herum. Lohnt es also noch, alte VB6 Projekte in CI/CD wie Jenkin zu integrieren? Tot zu kriegen ist VB6 scheinbar nicht. In der jüngsten Zeit hatte ich tatsächlich wieder ein paar Begegnungen mit VB6. Den Wünschen es abzulösen und der Ernüchterung, dass die Ressourcen dafür nicht zur Verfügung stehen oder der Aufwand den Nutzen übersteigen würde.

Migration auf VB.NET nicht so einfach

Dabei ist eine Migration auf VB.NET möglich, aber eben nicht so einfach. Und mit Aufwand verbunden, selbst wenn man das Glück hat, einen Konvertierer nutzen zu können. In einem Projekt aus meiner Vergangenheit wurden u.A. 3.Party Librarys benutzt. Der Hersteller existierte nicht mehr. Eine Portierung war so nicht möglich. Auch die Verwendung von Trim(), Left() und Konsorten hätte viel manuelle Nachkontrolle benötigt. Denn in VB6 gibt es schon ein paar Details in der Verwendung (siehe Stackoverflow). So erlaubt u.A. eines die Verwendung von NULL, und eines nicht. Nach einer Konvertierung wäre jede Verwendung zu kontrollieren. Ab einer gewissen Projektgröße ist das aber nicht mehr sinnvoll nachzuarbeiten. Zumindest wenn es, wie oben genannt, noch weitere Baustellen gibt.

Kompiliert es oder kompiliert es nicht

VB6 war in unserer Projektkonstellation relativ zickig. Es kompilierte nicht immer alles sofort. Manchmal war VB6 im Hintergrund noch aktiv und griff noch auf Dateien zu. Es gab diverse Varianten. Hier war ich froh um die Einbindung in Jenkins. Neuer Build, neues Glück. Automatisch, ohne händischen Aufwand treiben zu müssen. Es wird immer eine frische Version aus dem DVCS gebaut. Und es ist klar welche Quelltextunterschiede es zum letzten funktionierenden Build gibt. Ist der Build-Node eine VM, so kann man hoffentlich sogar im Notfall auf einen Snapshot zurückgehen um eventuelle Fehler am System auszuschließen. All diese Kleinigkeiten lassen mich auch heute noch davon ausgehen, dass insbesondere für solche Legacy Anwendungen der Aufwand, einen Build zu bauen, lohnt.

eigener Buildnode

Das letzte System auf dem ich die VB6 Projekte kompilieren konnte, war ein 32 Bit Windows 7. Wer unbedingt 64Bit möchte, findet z.B. bei Stackoverflow Tipps. Angefangen mit einem einfachen Desktop der dafür abgestellt und später virtualisiert werden sollte. Hier habe ich mich sehr über die Build-Node Funktionalität von Jenkins gefreut. Denn somit blieb das VB6 Legacy Projekt separat vom Rest. Denn um das Projekt zu kompilieren musste einiges "altes Zeug" installiert werden.

der eigentliche (Jenkins-)Build

VB6 Projekte zu kompilieren ist gleichzeitig einfach und langweilig. Einfach, weil man die VB6 IDE nur mit einem zusätzlichen Parameter aufrufen muss. Langweilig, weil man keinerlei Infos direkt erhält. Man muss explizit eine Output Datei angeben.

Das eigentliche Kompilieren wird wie folgt angestoßen:

C:\Programme\Microsoft Visual Studio\VB98\VB6.exe "/make "%WORKSPACE%\VBProject.vbp" /out "$WORKSPACE\!Output.txt"

Die generierte Output-Datei habe ich in die Build Artifacts eingeschlossen und auch im Fehlerfalle via Mail an den Entwickler gesendet.

Unit Tests hatte ich nicht verwendet. Heute würde ich versuchen ein wie zB Testframework zu nutzen. Und dann eben auch im Build auszuführen. Alternativ ließe sich das gerade kompilierte Tool mit einem Parameter starten. Das Tool könnte dann ein paar Selbsttests durchführen und einen entsprechenden Exitcode zurückgeben.

Fazit

Scheinbar bleiben doch oft VB6 Projekte aktiv, auch wenn man sich vielleicht etwas frischeres wünschen würde. Dennoch halte ich nichts davon, solche Projekte im Giftschrank zu halten. Denn wenn dann doch einmal eine Änderung vonnöten ist, ist es gerade von Vorteil auf möglichst viele Komponenten seiner CI/CD Chain zugreifen zu können. Also Augen zu, einmal ran und dann kann man in der Folge von den Vorteilen profitieren.