Continuous Integration – Lohnt meistens

Ich bin ein großer Fan von Continuous Integration (CI) und ich bin auch der Meinung, dass es sich meistensimmer auszahlt. Umso schöner, wenn sich bei Projekten der Erfolg relativ schnell herausstellt und auch andere die Vorteile erkennen. In einem meiner aktuellen Projekte habe wir letztes Jahr mit relativ wenig Überzeugungsarbeit CI mit CCNet eingeführt. Der Initiale Aufwand hielt sich in Grenzen, wahrscheinlich überalles bei 3-4PT (mit Einführung und Lernphase von Kollegen). Der Hauptgrund für die Einführung war erst mal Nachvollziehbarkeit und eindeutige Identifizierung von Versionen. Nach dem dieses Ziel erreicht ist, stellen wir gerade bei unseren häufigeren Patch-Bereitstellungen für Tests fest, wie schön es ist ein CI-System zu nutzen. Das System deployed nun aktuelle Testversionen schnell auf unseren Testserver, das ganze ist noch nicht perfekt, aber das muss es auch nicht sein.

Allerdings merke ich auch immer wieder, wie wichtig es ist, dass mindestens die wichtigen Personen im Projekt einen nutzen sehen und wenn es auch die politischen Dinge, wie Governance, Nachvollziehbarkeit, …. sind. Im Projekt haben wir keine strengen Restriktionen, daher sind viele Prüfungen nur als Informationen ausgeführt und werden auf der Seite reported (Emails lassen wir auch weg.). CI ist als integraler Bestandteil des Entwicklungsprozess zu sehen und erfordert nicht DEN großen Aufwand. Für Neulinge auf dem Gebiet kann ich CI-Factory empfehlen, dass auch eine Best-Practice Verwaltungsstruktur aufsetzt. Ich habe den Focus auf MS-Projekte und Tools, aber CI gibt’s für alle.

Hier noch mal meine Meinung zu den Steps, die im Build-System ablaufen sollten:

1. Version-Bezeichnung bereitstellen
2. Validieren der Quellen/ Integration (MSBuild)
3. Unit-Testen der Quellen (NUnit oder XUnit)
4. Statische Code-Analyse und Prüfung der Richtlinien (FxCop)
5. Paketieren und/oder bereitstellen der SW (Wix oder XCOPY)
6. Markieren (Labeln oder Taggen) der Version in der Quellcodeverwaltung

Gerade die Schritte 1, 2, 4, 5 und 6 sind einfach umzusetzen und bringen auch schnell einen Erfolg. Richtig klasse wird es, wenn das ganze Team den Nutzen erkennt und gerade für Continous Builds zur Verifikation der Quellen nutzt. Hierfür sind Entwicklungsrichtlinien und er gemeinsame Konsens erforderlich und alle müssen in das System schauen. Irgendwo gab es mal das nette Zitat „If you broke it, fix it!“, so muss das Motto jedes Teams heißen.

Leider habe ich immer wieder das Gefühl, dass Projektleiter am wenigsten von sowas zu überzeugen sind. Die meisten Projektleiter achten auf das Budget und können natürlich 3PT zusätzlich nicht verkraften, außerdem erfordert Governance Arbeit. Ich muss noch deutlich an meiner Argumentation arbeiten, aber Freizeit opfern ist nicht.

Technorati Tags: SCM,Development,Continuous Integration,CI

Resharper im Einsatz

Im moment teste ich gerade mal für mich den Resharper. Es handelt sich dabei um ein VS-Addin mit unheimlich vielen Funktionen und Möglichkeiten. Den Resharper gibt es als Testversion für 30 Tage zum testen, so dass man es beliebig ausprobieren kann.

Die Installation und der Start waren recht unkompliziert, einzig, dass überschreiben aller meiner Key-Bindings fand ich nicht gut. Zum Glück hatte ich noch eine Sicherung meiner IDE-Settings. Die Arbeit ist prinzipiell sehr einfach und man merkt schnell die ersten Features, abgewandeltes Syntax-Highlighting und die veränderte Intellisense-Hilfe. Außerdem ist es nett, wenn das Tool den Namen der Variablen vorschlägt.

Momentan bin ich recht angetan von den vielen Funktionen, aber andererseits nutzt man nicht alles Features der Suite. Wenn es auch die nächsten Wochen halbwegs so weiter geht beim Arbeiten, dann werde ich die Lizenz bei meinem Chef beantragen.