OOP 2008: Open Source mit kommerziellen Tools - Adé Gewissensbisse

In der letzten Zeit habe ich einige Projekte dank Google Project Hosting ganz einfach in die Open Source Welt einbringen können. Da gibt es zum Beispiel einen Microkernel oder einen Software Transactional Memory oder den Code zu meiner aktuellen dotnetpro Artikelserie über Mustervisualisierung.

Mit dem kostenlosen Subversion kann man den Quellcode von Google herunterladen. Mit dem kostenlosen NUnit kann man die darin befindlichen Unit Tests laufen lassen. Und mit dem kostenlosen C# (oder VB) Express von Microsoft kann man den Code auch übersetzen. Nein, sogar nur mit dem .NET Framework und MSBuild sollte das möglich sein. Insofern haben mich bisher keine Skrupel geplagt, selbst mit einer kostenpflichtigen Visual Studio Version zu arbeiten. Die Nutzung der Quellen ist ja auch mit kostenlosen Tools möglich.

Aber jetzt habe ich doch Gewissensbisse bekommen. Denn jetzt werden die Projekte so groß (oder meine Bequemlichkeitsansprüche sind gewachsen ;-), dass ich sie nach und nach mit einem automatischen Build-Prozess ausstatten will/muss. Den Anfang macht die dotnetpro Mustervisualisierung dnpPatViz. So sieht deren Quellcodebaum aus:

Diese vielen Projekte halte ich nicht in nur einer Visual Studio Solution/Projektmappe, denn das ist einer echt komponentenorientierten Entwicklung abträglich. Um schnell einen Überblick über die Gesamtkorrektheit meiner Quellen zu bekommen, kann ich daher nicht einfach F5 in Visual Studio drücken, sondern muss viele Solutions übersetzen und dann eigentlich auch noch alle Tests laufen lassen.

Ganz klar also, dass da ein automatischer Build- und Testprozess her muss. Aber womit den aufsetzen? Mit MSBuild oder NAnt wäre wohl die übliche Antwort aus der Open Source Welt. Die sind ja kostenlos.

Doch dazu kann ich mich wirklich, wirklich nicht überwinden. MSBuild- und NAnt sind kostenlos - aber erfordern geradezu ein Studium. Wie lange soll ich mich denn in deren XML-Dialekte einarbeiten? Wieviel soll ich denn tippen, um mal ein paar Projekte zu übersetzen, zu testen und dann noch zu deployen oder in ein Repository zu laden usw.? Ne, tut mir leid, für solche Klimmzüge ist mir meine Zeit zu schade.

Dabei gibt es doch Alternativen. Die Automatisierung von solchen Alltagstätigkeit und noch ganz anderer Prozesse (z.B. FTP-Upload oder Steuerung einer VM) kann auch viel einfacher sein. Viel einfach! Sie muss auch nicht aus Megabytes von XML-Verhauen bestehen. Sie kann nämlich aussehen, wie ein Workflow. Zum Beispiel so:

Das ist das Build-Script für die Mustervisualisierung. Hübsch visuell, intuitiv zu verstehen, leicht zu lesen und ohne eine Zeile Doku zu lesen in wenigen Minuten von der Übersetzung des ersten Visual Studio Projektes über die automatischen Tests bis zum abschließenden ILMerge zusammengesetzt.

Das (!) nenne ich Produktivität.

Und möglich ist´s mit FinalBuilder, einem wirklich coolen Tool. Das kostet zwar ein paar Euro - aber macht nix. Das Geld, was ich bei kostenlosen Tools spare, das habe ich mit FinalBuilder locker, ganz locker schon beim ersten größeren Einsatz wieder reingeholt. Ganz zu schweigen vom nervenschonenden Effekt eines grafischen Tools für "Build Workflows". FinalBuilder ist aus meiner Sicht für den Build-Prozess das, was VB 1.0 mal für die Windows-Entwicklung war. Aber genug des Schwärmens.

Wenn ich oben noch von Gewissensbissen gesprochen habe... dann sind die inzwischen verflogen. Ich habe mich von ihnen verabschiedet und mich entschieden, auch meine Open Source Quellen mit FinalBuilder Scripts auszustatten.

Open Source ist ja auch nur das: Open Source. Es sagt nichts darüber aus, mit welchen Werkzeugen die Open Sources zu bearbeiten sind. Die können von mir aus gern kostenlos sein. Aber wenn ich schon für meinen Entwicklungsaufwand in Form von freien Quellen kein Geld bekomme, dann will ich mich nicht auch noch für Admin-Angelegenheiten oder Organisatorisches verbiegen und durch aufwändige MSBuild-/NAnt-Programmierung draufzahlen.

Kostenlose Quellen: ja. Kostenlose Tools, um mit den Quellen zu arbeiten: nur, sofern der Aufwand den Nutzen nicht übersteigt. Und die Grenze ist aber beim Build-Prozess überschritten. Deshalb habe ich jetzt keine Gewissensbisse mehr. Ein schönes Gefühl.