Hätt ich das mal eher benutzt – Continuous Integration

Hätt ich das mal eher benutzt – Continuous Integration

Team Foundation Server

Bei Continuous Integration war ich dank des Team Foundation Servers recht früh dabei. Aufgrund des Gesamtumfanges der Aufgaben, die man ohne Mentor vor der Brust hat, habe ich viele tolle Features eines CI Servers aber erst spät benutzt. Die Build-Funktionalität und das Verbinden von Tickets und Checkins ist ja quasi schon drin. Andere Funktionen erzeugen ein wenig mehr Aufwand in der Einrichtung und kamen erst spät hinzu. Aber allein die Tatsache, dass die Quelltexte wie sie im Repository vorliegen, auf einem unabhängigen System kompilieren halte ich schon für einen sehr großen Vorteil.

Testausführung

Wie in diesem Post beschrieben, kam ich erst spät zu Unit Tests. Durch die Ausführung der Tests während des Builds ergibt sich aber ein riesiger Vorteil. Noch bevor das Setup erstellt wird, bekommt man die Information, welche Tests fehlgeschlagen sind und kann das System entsprechend reagieren lassen. Durch den Build kann es auch nicht passieren, dass die Tests in Vergessenheit geraten und nicht ausgeführt werden. Spätestens beim nächsten Build laufen sie. Nachdem ich Tests eingesetzt habe, gab es mehrere Fälle wo etwas lokal auf meinem Entwicklersystem kompilierte und die Tests liefen, auf dem Buildserver aber Tests fehlschlugen. Diese Fehler wären auf dem Zielsystem dann auch aufgetreten und hätten zu einem Bug geführt. Dank der Builds war ich frühzeitig gewarnt und konnte die Probleme korrigieren.

Code Style Checks

Als Entwickler gesteht man es sich ungern ein, aber die meisten Quelltexte, die ich gesehen habe, waren mehr oder weniger nah an „Spaghetti-Code“. Für meine eigenen gilt das natürlich nicht. 😉 Während einige Code Smells „nur“ zu schlechterer Wartbarkeit führen, können sich hinter anderen echte Fallen verstecken. Entweder meinte der Entwickler schon direkt etwas anderes, als er tatsächlich programmiert hat, dann ist es direkt ein Bug. Oder es ist nur die Basis für einen späteren Zeitpunkt oder einen anderen Entwickler in eine Falle zu tappen.
Performance ist ein weiterer Punkt, bei dem mir Tools wie „Style Cop“ schon ein paar hilfreiche Tipps geben konnten. Manchmal ist es auch einfach nur der Anstoß um sich in eine Funktion tiefer einzulesen. Spontan fällt mir dazu der allseits beliebte und oft übermütig verwendete StringBuilder. Lies mal nach, wenn Du den gerne verwendest.

Erzeugen eines Setups mit Versionsinformationen

Eine Zeitlang habe ich die Verteilung der intern entwickelten Software über eigene Tools realisiert. Dabei wurde das fertige Setup einfach in einen Netzwerkpfad gelegt und von einem anderen Tool auf den jeweiligen Rechnern installiert. Mit Unterbrechungen und Anpassungen nutze ich ein ähnliches System auch Heute noch. Mit dem Setup lege ich aktuell eine XML Datei ab, die Informationen über das neue Setup enthält (z. B. Version, Changelog, Dateiname). Dadurch können in der Anwendung vor Installation eben diese Informationen angezeigt werden. Die Transparenz für den Nutzer steigt enorm. Selbst wenn die Version intern eh eingespielt werden muss, steigt die Akzeptanz bei den Usern.

Installation auf Testsystem

Eine automatisierte Installation auf einem Testsystem bringt eine ganze Menge Vorteile. Wenn man die Möglichkeit hat den Installationserfolg zu testen, ist direkt klar, ob das Setup korrekt funktioniert. In meinem Falle habe ich so aber auch immer direkt die aktuellste Version auf einem System zur Verfügung. Bei der Benutzung muss ich dann nicht erst auf die entsprechende Version aktualisieren.

Fazit

Die Grundfunktionalität des CI Servers macht ihn für mich schon unverzichtbar. Aus den im Repository liegenden Quelltexten zuverlässig ein vollständiges Setup zu generieren (wenn ich das so wünsche). Mit jeder zusätzlichen Funktionalität wird er stärker in die Entwicklung eingebunden und hebt die Qualität jedes Mal auf eine neue Stufe. Ich bin daher froh, schon so lange auf einen CI Server zurückgreifen zu können und wünsche mir bei der einen oder anderen Funktionalität ich hätte sie früher ausprobieren können. Und Du? Hast Du auch einen CI Server?

Michael Grünwaldt

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert