Gleich vorneweg: Es war super! Nein, noch mehr, es war richtig super! Eine mehr als gelungene Veranstaltung. In diesem Wochenende habe ich vieles gelernt und mitgenommen. Die Eindrücke dieser wahnsinnigen .NET-Veranstaltung wirken bei mir noch so immens, dass ich sie hier in einem Blog einfach niederschreiben muss.

Mittendrin statt nur dabei!

Samstag, 9:45 Uhr, ich gehe durch eine unscheinbare Tür, es gibt nur ein kleines Schild „.NET Openspace Süd 2010, 4. OG“. Ich laufe die Treppen hoch und werde von einem lächelnden Gesicht überrascht: „Na, ganz schön sportlich!“ rief die freundliche Check-In-Lady (neudeutsch für Empfangsdame ?!? ;)) mir entgegen. Wohl eher aus Höflichkeit, schließlich tat ich mir nach geleisteter Stufenarbeit merklich schwerer als sonst, das mir entgegengebrachte Lächeln mit einem Zurücklächeln zu erwidern.

Nach dem obligatorischen Check-In mit Teilnehmerkarte und Event-Infos finde ich mich mittendrin in der Sessionplanung für den ersten Tag wieder. „Wahnsinn“ dachte ich mir, endlich sehe ich viele, die ich nur per Twitter, Blog oder anderweitig online kenne. Gleichzeitig freute ich mich, wieder in Gesichter zu blicken, die ich schon kannte. Und ich war gespannt, welche neuen Bekanntschaften ich mit dieser „Erfahrungsaustauschplattform“ Open Space machen würde. Doch zunächst galt es, die Sessionplanung konzentriert umzusetzen. Auf geht’s!

WTF is a Monad?

Die Antwort auf diese Frage hat mir auf anschauliche Art und Weise Steffen gegeben. Er folgte der Aufforderung von Björn, uns allen mal dieses komische „Monad-Ding“ in verständlicher Form widerzugeben. Ich ertappte mich selbst dabei mich nicht daran erinnern zu können, wie lange es her ist, so gespannt und magnetisiert einem Thema und seinem Vortragenden zuzuhören.

Er erklärte unter Anderem, dass die Uhr ein Monoid sei und es nur 3 essentielle Kriterien für das in sich geschlossene System eines Monaden gibt. Das neutrale Element, die „SelectMany“ und „Id“ Methoden (also Bind & Return) [Anmerkung: Das ist mit großer Wahrscheinlichkeit mathematisch total falsch und wahrscheinlich auch nicht richtig - aber so habe ich es verstanden :-/ - Korrektur willkommen.]. Es ging weiter mit der Vorstellung der Population in der Monaden-Welt: Identity, Maybe, Continuation, State.

Ich habe es sicherlich noch nicht richtig begriffen und bin selbst erst am Anfang, die funktionale Programmierung wieder in meine tägliche Programmier-Praxis einzuführen. Doch diese Session war für mich wie ein Paukenschlag zum Auftakt! Super.

3D in your Pocket

„Hmm, das ist schwer zu toppen“, dachte ich mir, noch gedanklich verworren in Monaden, als ich mich plötzlich in der 2. Session über XNA & Windows Phone 7 von Tom wieder langsam aus der Monadenwelt lösen konnte. Doch meine Skepsis erwies sich als unberechtigt. Tom zeigte uns, das XNA keine Abkürzung für Spieleentwicklung ist, sondern eine Abkürzung ist für effektive & professionelle Spieleentwicklung – mit einer für mein Empfinden niedrigen Lernkurve.

Tom ist ein Verfechter von Fakten, also waren auch keine trockenen Slides angesagt – statt dessen gab es Visual Studio, Source Code und den Windows Phone 7 Emulator zu sehen. Ich durfte lernen, dass es gar nicht so schwer ist, Windows Phose 7 „anzuprogrammieren“ und sich auch kein Hexenwerk hinter „Worlds“, „Matrices“, „Meshes“ und „Shadern“ verbirgt. Macht Laune auf mehr.

Design Drivers

Und schon ging es weiter mit den Erkenntnissen in der von Sergey angetriebenen Session über “TDD vs. BDD vs. ATDD”. Es war unerwarteterweise keine trockene Gegenüberstellung von „methodischen Religiösitäten“. Ganz im Gegenteil. Die Session war wohl eine der konstruktivsten Diskussionen über „Erwartungsgetriebene Softwareentwicklung“, bei denen ich dabei sein durfte.

Der Erfahrungsaustausch fand auf breiter Ebene statt, fast jeder konnte irgendwie dazu beitragen. Highlights waren sicherlich die Vorstellung von Fitnesse als Werkzeug für ATDD sowie die anschauliche Erklärung der Agile Testing-Quadranten von Sergey.

Im Übrigen hatte wohl Sergey noch mehr „feine Info’s“ mitgebracht, denn er war es auch, der die „RX – Reactive Extensions Hands On“-Session kräftig mitgestaltete. Ach, ich könnte womöglich noch stundenlang über die weiteren, hochinteressanten Sessions auf diesem .NET Open Space schreiben.

Know How Rollercoaster

Zum Beispiel über die unglaublich erkenntnisreiche Session über „TDD/BDD Do’s and Dont‘s“ – das war geballtes Know-How über testgetriebene Entwicklung. Oder die Session über „verteilte Architekturen“ sowie die Session über „Skalierung & Caching im Web“, die anschaulich die Best Practices dieser Themen an mich, den Teilnehmer transportieren konnten.

Das „Daily Life“ wurde wertwoll angereichert durch die Sessions „Smart Tools for Smart People (Part I + II)“ von Daniel. Das meistern spielerischer Herausforderungen wurde in der AntMe!-Session von Tom gezeigt, einen Kickstart von 0 auf 100 für ASP.NET MVC2 lieferte der Albert. Die weise Erkenntnis der vielen Gemeinsamkeiten und wenigen Unterschiede von xUnit.BDDExtensions zu MSpec zu NaturalSpec wurde in der „United BDD“-Session deutlich. Unüberhörbar waren auch die Berichte von einer spannenden Session über die Erfahrungen mit und um DDD herum von Gregor.

Ach ja, es gab ja auch noch ein Coding Dojo. Ich als „Session-Host“ möchte nicht viele Worte darüber verlieren. Ich möchte viel mehr, dass jeder, der dabei war, seinen Eindruck mitnimmt und seine Meinung dazu bildet. Ich kann nur sagen: mir hat das Dojo mit so vielen interessierten und erfahrenen Entwicklern sehr viel Spass gemacht und ich konnte wieder einiges dazulernen.

Environment.Cool();

Doch dieses gesamte „Excitement“, der Erfahrungsaustausch, die Bekanntschaften, die wunderbar leichten Unterhaltungen am Mittagstisch, die Diskussionen über Vergangenheit, Gegenwart und Zukunft der Software-Entwicklung am gemütlichen Abend, die Betrachtungen über den eigenen Tellerrand hinaus – all das wäre nicht möglich gewesen, ohne die Motivation & Organisation zum .NET Open Space Süd in Karlsruhe. Vielen Dank an die DNUG Karlsruhe, Alex, Ralf, Frank, Aydin und alle, die dabei waren! Ich bin beim nächsten Mal sicher wieder dabei!

Doch eine wichtige Frage bleibt nach dem .NET Open Space Süd immer noch offen: Planen Steffen, Björn, Sergey, Alexander eine Verschwörung? Bildet sich ein verschworene Monaden-Mafia? Welche Rolle spielt dabei „Jean Closure“ – ist er der neue Pate der testgetriebenen Untergrundgeschäfte? Vielleicht hat Christian auch etwas damit zu tun?

Maybe Some<IsTrue>, Maybe None<IsTrue> … to be Continuation-Monad! ;-)

Ich möchte gleich mal eine provokante Aussage in den Raum werfen: Bugtracking für Software-Projekte ist sinnlos. Jedenfalls in den meisten Fällen. Mehr noch, Bugtracking sollte soweit wie nur irgend möglich vermieden werden!

Was will ich damit sagen? Man betrachte einmal das mittlerweile so “selbstverständliche” Tooling bei Software-Projekten: Man nehme ein SCM (z.B. SVN oder git), ein CI-System (z.B. TeamCity oder CruiseControl) und einen IssueTracker (z.B. Bugzilla oder Trac). Man kann das ganze natürlich auch als Gesamtpaket haben, z.B. mit TFS. So, damit hat man die Eckpfeiler einer Software-Entwicklungsumgebung parat und kann frisch und fröhlich programmieren. Ich denke allerdings das dieses Toolset nicht ganz so glücklich gewählt ist.

Bugtracking ist Zeitverschwendung

In einer Zeit, in der viel getan wird, um einen sauberen Code zu produzieren ist meiner Meinung nach die jetzige “Methodik des Bugtrackings” nicht mehr adequat. Entwickler versuchen mit agilen Methoden (teilweise krampfhaft) mehr Qualität und Stabilität in ihre Produkte zu bringen. Ein aktuelles Beispiel ist die Beachtung und Anwendung der Prinzipien der Clean Code Developer Bewegung, die Ihre Kernaussage aus der Craftsmanship-Ideologie von UncleBob schöpft. Darüber hinaus beschäftigt sich die gesamte Softwareentwicklungsindustrie seit Jahren mit Themen wie z.B. Continuous Integration oder Test-Driven-Development, die mitunter das Ziel haben, die Qualität des Softwareproduktes schon während der “Produktionsphase” stetig hoch zu halten. Flankiert wird das ganze auch noch mit agilen Managementmethoden wie z.B. Scrum oder Kanban, die auch einen besonderen Anspruch auf stetige, hohe Qualität legen.

Nichtsdestotrotz findet man in jedem Tool-Setup den altbekannten “Bugtracker” wieder. Wieso? Auf der einen Seite strebt man nach dem “Zero-Defect”, nach hochqualitativer Software. Aber mit dem gleichen Atemzug gibt man sich dennoch geschlagen, indem man von vornherein mit Bugs rechnet. Denn einen Bugtracker zu betreiben ist in den allermeisten Fällen nichts anderes als ein Geständnis. Undzwar das Geständnis sich selbst gegenüber, doch nicht alles “hundertprozentig” zu machen. Es ist ein Widerspruch in sich. Jaaaa, Clean Code, TDD, BDD, DDD und noch eine handvoll anderer bewährter Methoden, von mir aus noch Pair Programming, Continuous Integration / Deployment und Scrum. Aber: Ein Bugtracker muss auf jeden Fall auch her.

Bugtracker ist nicht gleich Liste und schon garnicht Archiv

Man mag mir entgegenbringen, dass mit einem “Issue Tracking”-System nicht nur Bugs verwaltet werden, sondern auch Feature-Requests und ähnliches. Featurelisten sind eine wunderbare Sache, vor Allem wenn man sie priorisieren kann. Aber dazu braucht man keinen Bugtracker. Im Allgemeinen reichen einfachere Tools aus.

Das am meisten erwähnte Gegen-Argument ist wohl, das man mit dem Bugtracker die Bugs “verwalte”, um sie ja nicht zu vergessen und Ihnen angemessene Priorität zu geben. Lächerlich! Eine Farce, denn in der professionellen (wirtschaftlich orientierten) Softwareentwicklung ist solch ein Ansatz absolut kontraproduktiv. Erstens schafft es einen weiteren Verwaltungs- und Organisationsapparat, den es erst mal zu bewältigen gilt. Zweitens mutiert es mit der Zeit zu einer Halde (ich will schon fast sagen Müllhalde) von unwichtigen Bugs und Feature-Requests, die man irgendwann einmal angehen will. Drittens stellt es automatisch und implizit ein Konkurrenzsystem zur Roadmap dar. Warum?

Na ganz einfach: wenn ein Bug wirklich ein wichtiger Bug ist, dann wird er sofort gefixed. Alles andere ist entweder nicht wichtig oder wird dann erst wichtig, wenn die wichtigeren Dinge schon erledigt sind. So einfach ist das.

Außerdem: Gefühlt implementiert nahezu jeder, der was auf sich hält seine Software mit agilen Methoden und Praktiken. Scrum und XP sind schon längst angekommen; und mit TDD und Clean Code wir bewegen uns auf einem hohen Niveau, oder nicht? Unsere Grundmotivation ist es doch, fehlerfreie Software auszuliefern, oder nicht? Ok, 100%ig gibt es nie, aber wir streben doch zumindest die three nines der “High Quality” an, oder nicht? Ich denke schon – zumindest ist das mein Verständnis. Wenn dem so ist, warum brauchen wir dann ein Bugtracking-Tool?

Bugreporting ist wichtig, Bugtracking jedoch unwichtig

Ich möchte mit meiner provokanten Aussage nicht erreichen, das man grundsätzlich das Issue Management anzweifelt. Es ist eher das Gegenteil der Fall. Ich stärke sogar die Wichtigkeit & Effizienz, zumal nach wie vor ein richtiges Bugreporting und eine Bug Triage entscheidend sind, um die richtige Entscheidung treffen zu können. Mein Augenmerk gilt der Bugverwaltung an sich, also der zentralisierten Auflistung, Verwaltung und Archivierung von Fehlerprotokollen. Im Lean Management sind zentrale Prozesspunkte ein “rotes Tuch”. Statt dem sternförmigen Kommunikations- und Prozessmodell wird dort das, Netzmodell favorisiert. Dieser Ansatz ist meiner Meinung nach besonders auf das Issue Management anwendbar.

Natürlich kann ich nicht generell sagen, dass ein Bugtracking-Tool sinnlos ist. Es gibt immer wieder Situationen und Rahmenbedingungen, die auch ein Bugtracking-Tool und eine zentrale Fehlerverwaltung rechtfertigen. So ist es z.B. bei einem Produkt, bei dem die User-Gemeinde aktiv die Bugs berichten und einsehen kann sicherlich sinnvoll, ein Bugtracking-System einzusetzen. Allerdings ist es nur in den seltensten Fällen wirklich notwendig.

Man könnte ein Bugreporting auch derart gestalten, dass man sich beim Reporter für den Bericht bedankt und ihm verspricht, das Problem zu analysieren. Dann schaut man sich den Fehler an. Ist er wichtig genug, wird er sofort gefixed – und der Benutzer ist glücklich. Ist er nicht wichtig genug (also ist entweder ein anderer Bug oder ein anstehendes Feature wichtiger), so wird der Report weggeworfen. Der Benutzer wird benachrichtigt dass der Fehler momentan nicht korrigiert wird. Ehrlich, sachlich, klar. Der Berichterstatter kann nun nochmals (mit Vehemenz) darauf pochen, den Fehler behoben zu wissen. So kann man z.B. bei benutzerorientierten Produkten auch ein Voting einsetzen (wie z.B. bei Codeplex). Erhöht sich das Voting (die Priorität) nicht, wird der Bug nicht gefixed und weggeworfen. That’s it.

Es gibt nur ein Go oder Nogo für einen Bugfix

Ich bin der festen Überzeugung das diese Verfahrensweise vor Allem dann effizient ist, wenn man in der Software-Entwicklung agile Methoden anwendet. Für mich sind Software Craftsmanship, TDD, XP und all die weiteren modernen Methoden einfach nicht mit dem veralteten Zentralverwaltungs-Muff “Bugtracking” vereinbar. Statt dessen sollte man ein leichtgewichtiges Bugreporting etablieren und die Entscheidung über den Fix oder No-Fix des Bugs schnell herbeiführen. Nur so kann man sich selbst dazu erziehen, von Anfang an in der Software-Entwicklung das Qualitätsbewusstsein zu schärfen und die Qualität konstant adequat hoch zu halten. Denn nur mit dieser “KO-Entscheidung” über den Fix eines Bugs kommt man (leidend, aber relativ schnell) zu der Erkenntnis, dass man wenn man wirklich das Produkt stetig weiterentwickeln möchte auch immer sich zum Ziel setzen muss, ein möglichst fehlerfreies Produkt auszuliefern.

Die Erkenntnis, Bugs nicht zu verwalten und sofort zu entscheiden, ob es gefixed werden soll oder einfach ignoriert werden soll ist meiner Meinung nach ein wichtiger Bestandteil für qualitative, agile Software-Entwicklungs-Methoden.

Ergo: Bugtracking ist sinnlos!

Entscheidend bei der Anwendung von Continuous Integration ist aber nicht nur das Toolset, sondern in großem Maße auch die “Theorie des Softwarebau’s” – dem Software Configuration Management. Ein wenig komisch ist diese Beziehung zwischen dem agilen Continuous Integration und dem formalistischen Software Configuration Management schon. Jedoch sind bei näherer Betrachtung nehmen Gemeinsamkeiten gegenüber den Unterschieden deutlich überhand.

Die wenigsten Software-Entwickler können sich unter dem Begriff Software Configuration Management (SCM) etwas konkretes vorstellen. Meistens wird SCM auf ein Versionskontrollsystem wie TFS, SVN, GIT oder Perforce reduziert. SCM ist jedoch weitaus mehr. In dem kurzen Artikel “Agiles Software Configuration Management” habe ich die Grundlagen des SCM zusammengefasst und den theoretischen Stoff ein wenig aufgearbeitet. Hoffentlich hilft es dem einen oder anderen, diese theoretischen Konzepte auf den praktischen Einsatz abzubilden.

Session 1: Dariusz zu Besuch in Oslo

Abstrakte Kost zum Wachwerden für müde Entwickler-Hirne präsentierte Dariusz mit der ersten Session des zweiten TS-Tages: Oslo – Modellgetriebene Entwicklung. Was ist denn Oslo?

Zunächst einmal wäre da die grundsätzliche Definition einer Entwicklungs-Umgebung und entsprechenden Tools, die eine modellgetriebene Software-Entwicklung ermöglichen sollen. Microsoft verfolgt hier den Ansatz des “neu erfindens”. Mit Oslo wird eine komplett neue Landschaft angeboten, statt bestehende Systeme zu erweitern.

Zum einen wäre da die “textuelle Modellierungssprache” M – M wie Modell. M ist natürlich keine klassische Programmiersprache, sondern dient der Beschreibung von DSL’s. Im Fokus ist nicht die Objektorientierung, sondern Daten- und Strukturorientierung. M hat eine Reihe von eigenen DSL’s (also Untertypen zu M), darunter MGrammar, um Grammatiken und Syntax für die eigene Textsprache zu definieren, MEntity um verhaltens- und modellbezogene Objekte zu modellieren, sowie MSchema, eine Sprache zur Definition von (relationalen) Datenstrukturen. Dariusz zeigte ein paar Beispiele mit dem neuen “Intellipad” (dem M-Editor), der schon seit einiger Zeit im Netz als das “Emacs.NET”-Gerücht verbreitet wurde.

Modellierung geht natürlich auch – oder besser primär – visuell. Dafür hat Microsoft einiges an Entwicklungsarbeit investiert und die neue Anwendung “Quadrant”. Quadrant ist so etwas ähnliches wie ein flexibler Diagramm-Designer. Die Flexibilität erreicht es zum einen über M selbst sowie auch über eigene “Meta-DSL’s”. Quadrant hat im wesentlichen eine Office-Style-Ribbon-Bar und eine “Workspace” genannte Zeichenfläche. Je nach definierten Modell oder DSL kann man verschiedene Entitäten und Objekte erstellen, auch neue Menü’s und der Kontext ist änderbar. Auf den ersten Blick sieht das Tool ganz nett aus – die Power, die in Quadrant stecken soll, konnte mir Dariusz in den 5 Minuten leider nicht ganz vermitteln.

Ein wesentlicher Teil von Oslo ist “Dublin”. Dublin soll eine Hosting Runtime für Oslo MDA’s werden. Realisiert als Erweiterung für den IIS ist es ein Quasi-Application-Server. Intern werkeln WCF & WF kräftig auf dem Metadaten-Modell und sollen die mit den Oslo-Tools entworfenen Anwendungen ohne weiteres Zutun ausgeführt und zur Verfügung gestellt werden können. Dublin selbst ist noch in der Entwicklung – mal abwarten, wie es am Ende aussehen wird.

Am Rande erwähnt wurde auch, das die gezeigten Oslo-Komponenten (also M und Quadrant) wohl auch irgendwie mit Visual Studio gekoppelt werden – natürlich noch nicht zum VS10er-Release, aber eine Integration sei in Planung.

Fazit: Oslo ist in einer noch sehr frühen Phase, deutet aber schon an, wie MDD in Zukunft aussehen kann. Danke Dariusz.

Session 2: Christian mit Rosario

“Rosario” ist der Codename der neuen Version von Visual Studio Team System / TFS. Wer schon heute mit VSTS mit TFS verwendet, der weiß, das da noch einiges an Platz für Verbesserung vorhanden ist. Das scheint auch Microsoft erkannt zu haben, wenn man den Worten von Christian glauben darf. Bei den Worten wollte er es natürlich nicht belassen und zeigte ein paar Slides und Demos zu den Verbesserungen.

Zunächst einmal werden Kernelelemente wie Skalierungsfähigkeit, Maintenance und das Build- bzw. SCCS-Management verbessert. Wie hinlänglich bekannt, ist Installation und Administration von TFS / VSTS ja keine besondere Meisterleistung von Microsoft. Mit Rosario soll laut Chrisitan TFS innerhalb einer halben Stunde installiert und konfiguriert werden können – da lehnt er sich meiner Meinung nach ziemlich weit aus dem Fenster – aber ich will nicht von vornherein darüber urteilen.

Für den Continuous Build wird Build Agent Pooling und das “Gated Check-In” integriert. Das “Gated Check-In” erlaubt einen serverseitigen Buildrun mit den Änderungen, die eingecheckt werden sollen. Das neue “Branch Management” ist eigentlich nichts anderes als ein Backtracking und eine Visualisierung der Branches auf dem SCCS. Diese Features sind bei der Konkurrenz (siehe z.B. TeamCity) z.T. schon lange Standard – wenigstens schließt hier Microsoft ein wenig auf.

Im Project Management Bereich soll das Reporting und Templating besser ausgebaut werden. Interessant ist die Integration der Kernelemente von Scrum, wie z.B. das Dashboard und Excel Listen für Product Backlog, Sprint Backlog, Sprint Planung, Burndown Charts oder die User Story Work Items. Die Beziehungen der Work Items zueinander wird in Rosarion weiter verbessert. Man kann eine komplette Hierarchie aufbauen, aber auch andere “Link Relations” setzen, wie z.B. Predecessor (Vorgänger) oder Dependency (Abhängigkeit). Auch die Organisation der einzelnen Projekte wird überarbeitet. Über die schon existierenden Team Projects sollen nun organisatorisch mit “Team Project Collections” ganze Anwendungsfamilien verwaltet werden können.

Für das Qualitätsmanagement sollen die Tools für das Unit Testing weiter verbessert werden. Interessant ist, das ein komplett neues “Test Quality Center” aufgebaut wird (Codename: Camano). Neue Features wie Test Impact Analyse, Test Suites und ein neuer “Test Plan Manager” sollen den Testalltag vereinfachen. Auch die Test Cases sind als Work Items gespeichert und können mit Changesets, Tasks und Requirements verbunden werden. Gut gelungen finde ich die Verwaltung der Test Cases mit Test Runs und Test Settings. Ziel dieser feinen Testorganisation soll die Eliminierung der “No Repro Bugs” sein.

Dieses Ziel wird vor Allem durch den neuen “Manual Test Runner” unterstützt, mit dem manuelle oder explorative Tests durchgeführt werden können. Besonders prickelnd: Die Tests können mit einem Test Recorder aufgenommen und automatisiert werden. Weitere Test Tracking Features sind die Videoaufnahme, Log Sampling und Umgebungsanalyse. Übrigens, der Test Recorder soll eine Reihe von UI-Typen unterstützen können, wie z.B. Windows Forms, WPF, die IE Engine und sogar die Firefox Gecko Engine. Ein Highlight beim Qualitätsmanangement ist das “Environment Provisioning”, mit dem eine virtuelle Testumgebung angeboten werden kann. Wie das eben so ist mit virtuellen Maschinen, sind Checkpoints und Flashbacks auf ältere Stände möglich.

Abschließend ging Christian noch auf die neuen Diagramme und Analyse-Möglichkeiten von VSTS 2010 ein. Standard UML die Use Case, Activitiy, Sequence und das bekannte Class Diagram sind nun in VS direkt umsetzbar. Es wird zusätzlich noch das “Laer Diagram” und ein “Architecture Explorer” angeboten. Das Layer Diagram soll eine Tiered Architecture widerspiegeln. Durh Verknüpfung der einzelnen Elemente mit Namespaces ist sogar eine automatische Validierung zur Einhaltung der Layer-Regeln möglich. Der Architecture Explorer ist die visualisierte Fortführung des Object Explorers. Ausgehend von einem “Bird-Eye View” kann man in die einzelnen Namespaces, Klassen und Methoden navigieren und sich besondere Konstallationen näher ansehen. Ein NDepend-Ersatz ist es bei weitem nicht, aber ermöglicht zumindest eine nette und schnelle Analyse.

Fazit: Die neuen Quality-, Test- und Diagramm-Features sind wirklich beeindruckend. Die Verbesserung von TFS ist längst überfällig. Vielversprechend!

Session 3: Nochmal Dariusz mit WCF & WF in .NET 4.0

Da bin ich nun wieder in einer Session mit Dariusz gelandet. Diesmal: WF & WCF in .NET 4.0. Wie immer zu Beginn ein Abriß der Themen. Generell wurde bei der Weiterentwicklung von WF und WCF an der Performance geschraubt. die Workflow Foundation Engine soll eine mindestens 10-fache Geschwindigkeitssteigerung erfahren haben. Doch nicht nur unter der Haube der WF wurde gewerkelt. Die API wurde verbessert, um noch einfacher mächtigere Activities entwickeln zu können. So werden mit 4.0 auch “Variablen” (besser: State Parameter) im Workflow unterstützt, die man relativ elegant mit den Klassen InParameter<T> und OutParameter<T> ansprechen kann.

Besonders hob Dariusz den komplett neu aufgebauten Designer von WF hervor. Er wird nun komplett in WPF umgesetzt, bietet dementsprechend eine ansprechende UI und ist vor Allem besonders gut anpassbar. Auch die Verwendung des Designers in eigenen Programmen (das sog. Rehosting) wird deutlich verbessert und vereinfacht.

Auf der WCF-Seite werden die QoS-Merkmale Konfiguration, Monitoring und Deployment weiter verbessert. Das eigentlich Neue ist aber die engere Verzahnung mit der Workflow Foundation. Zwar ist es schon jetzt möglich, eine WF-Anwendung per WCF in wenigen Schritten zur Verfügung zu stellen – doch ein weiterer Ausbau sei geplant. Diese “Vereinigung” hat auch einen höheren Sinn, nämlich die Entwicklung von Dublin (siehe auch Session 1: Oslo).

Fazit: Kurz & Knackig. Das Zusammenspiel von WCF & WF war hervorzusehen, die Neuigkeiten über WF hören sich gut an.

Session 4: Oliver Scheer über die Zukunft von ASP.NET

Die Zukunft von ASP.NET – das interessiert mich. Also auf zur letzten Session der Technical Summit mit Oliver Scheer. Nach 5 Minuten dachte ich mir: Ups – schon wieder eine Themaverfehlung? Denn Oliver gab ein Überblick über das, was er in einer Stunde zeigen möchte: ADO.NET Data Services, Dynamic Data Sites, ASP.NET MVC, ASP.NET AJAX und AJAX Control Toolkit. Toll – Wo ist JQuery, wo sind die neuen HttpHandler und -Modules, wo sind die MVC-Controls? Anscheinend nicht auf der Technical Summit. Naja – vielleicht zeigt Oliver ein paar Minuten noch neue Features für ASP.NET MVC.

Zunächst zeigte Oliver eine Demo von ADO.NET Data Services. Schön einfach über das Entity Framework die Tabellen zusammenklicken, den Data Service erstellen und die Configzeilen reinschreiben. Fertig. Nix Neues. Punkt.

So – jetzt mal endlich etwas neues für ASP.NET – ASP.NET MVC. Oliver beschreibt die Grundlagen und zeigt die bekannten Getting-Started-Samples. Er geht flüchtig auf die Konventionen ein und beschreibt sehr oberflächlich die Idee des MVC. So, noch kurz das Routing gezeigt und ein wenig erklärt. Ok. Nix Neues. Punkt.

Oh – Oliver holt aus zum nächsten Thema – ASP.NET Dynamic Data Websites. Ich wundere mich jedes Mal, wenn ich das sehe, wer zum Teufel im Alltag den Anwendungsfall für so eine Art Website hat. Es scheint wohl einige zu geben, sonst hätte man nicht so eine Art von Website-Projekt wohl nicht realisiert. Egal – ich jedenfalls kenne niemanden der sowas brauchen kann. Nix Neues. Punkt.

Zu guter Letzt noch ein Ausflug in ASP.NET AJAX und ein Verweis auf das AJAX Control Toolkit. Oliver zeigt wieder mal die gewohnte Extender-Demo. Ok. Nix Neues. Halt! Zu guter Letzt doch noch JQuery! Zu schade – nur ein Hinweis auf die Integration und die Auslieferung mit ASP.NET 4.0. Als Entschädigung dafür zeigt Oliver in seiner letzten Demo, das die neuen, von Microsoft geschriebenen JS-Klassen einen Aufruf von WCF Diensten ohne jegliches serverseitiges Zutun durchführen können. Ok. Wenigstens ein wenig Neu. Punkt.

Fazit: Nahezu Nix Neues. Punkt.

Eine Anmerkung noch: ich finde es wirklich sehr Schade, das gerade die zwei Sessions über ASP.NET für mein Dafürhalten so schwach ausgefallen sind. Man kann ASP.NET mögen oder nicht – aber auf einer Konferenz wie der Technical Summit ASP.NET derart zu vernachlässigen ist spricht nicht gerade für technologische Überzeugung.

That’s it

So, das war also die Technical Summit 08, so wie ich sie erlebt und verstanden habe. Ich denke jetzt muss ich erstmal die Infos und die ganze Veranstaltung noch auf mich wirken lassen und verarbeiten. Im Großen und Ganzen war es eine gute und z.T. sehr aufschlußreiche Konferenz. Das absolute Highlight war für mich die Parallels-Session mit Steve, dicht gefolgt von den beeindruckenden VSTS-Demos von Christian und der hochinteressanten Microsoft-MDD-Interpretation Oslo mit Dariusz.

Konkret ging es dabei um den Release-Prozess einer Software-Komponente. Zunächst sollte ich eventuell klarstellen, was ich mit dem schon beinahe überladenen Wort Release-Prozess meine. Der Release-Prozess umfasst aus meiner Sicht all jene Aufgaben, die ein Entwickler oder ein Unternehmen durchführen muss, um Software in dessen Anwendungsgebiet einsatzbereit zu machen. Insofern beinhaltet ein Release also im Kern das Erstellen des Kompilats der Anwendung, die Paketierung aller notwendigen Dateien zum Betrieb der Anwendung, den Transport des Installationspaketes auf die Einsatzumgebung und schlussendlich die Installation und Konfiguration der Anwendung auf dem Zielsystem. Ich möchte meine Ideen und Vorstellungen zu einem besseren Release-Prozess festigen, indem ich einzeln die Schritte eines Releases beschreibe.

Natürlich beinhaltet ein Release einer Software auch einige weitere Maßnahmen als die oben genannten, wie z. B. die Erstellung oder Aktualisierung von Dokumentationen oder Benachrichtigungen über die Verfügbarkeit der neuen Anwendungsversion bei der jetzigen Anwendern bzw. potentiellen Zielgruppen. Ich möchte hier allerdings nur auf den Kern des Release-Prozesses eingehen.

Erstellen des Release-Builds
Der wichtigste und aus meiner Sicht kritischste Punkt im Release-Prozess erfolgt gleich zu Beginn: Das Erstellen des Release-Builds. Hier ist es für ein sauberes Release entscheidend, dass von vornherein Richtlinien zu diesem Schritt vorhanden sind und beachtet werden. Die wichtigsten Regelungen sind meiner Meinung nach:

• Der Build ist automatisch.
  Folglich erfolgt er komplett automatisch, es ist keine Interaktion zum Bauen des Builds erforderlich.
• Der Build ist integer.
  Er beinhaltet alle Dateien, die zum Kompilieren der Software notwendig sind. Darüber hinaus enthält der Build alle Dateien, die zum reibungslosen Einsatz der Software auf dem Zielsystem erforderlich sind.
• Der Build ist atomar.
  Der Build wird demnach an einem festgelegten Zeitpunkt erstellt und wird während sowie nach dem Release-Prozess nicht mehr modifiziert.
• Der Build ist final.
  Er wird während des Release-Prozesses nur ein einziges Mal erstellt.

Paketierung der Software
Nach erfolgreicher Erstellung des Builds ist der nächste Schritt die Paketierung. Mit der Paketierung werden neben dem Kompilat alle weiteren Dateien wie zum Beispiel Release Notes, Benutzerdokumentation, Anwendungsbeispiele und ähnliches zu einem Gesamtpaket zusammengeschnürt. Hier ist vor allem die Art der Paketierung entscheidend. Im Allgemeinen sollte das Gesamtpaket mit einer Installation und Installationsanweisungen ausgeliefert werden. Leider kommt es in einigen Unternehmen noch viel zu oft vor, dass das Paket ein einfaches ZIP-Archiv ist. Wie beim Build-Schritt auch, sollten bei der Paketierung einige Grundregeln beachtet werden:

• Die Paketierung erfolgt automatisch.
  Es sind keine manuellen Schritte bis auf das Anstoßen der Paketierung erforderlich.
• Die Paketierung erfolgt erst nach erfolgreicher Abnahme des Release-Builds.
  Dies wird im Allgemeinen durch automatisierte Tests und manuelle Verifikation auf Testsystemen gewährleistet.
• Die Paketierung ist integer und final.
  Wie beim Build selbst wird das Auslieferungspaket nur einmal erstellt und während des Paketierungs-Prozesses nicht mehr modifiziert.
• Das Auslieferungspaket ist unabhängig.
  Unabhängig bedeutet in diesem Fall, dass das Paket keine weiteren Komponenten oder Informationen mehr benötigt, um auf dem Zielssystem installiert werden zu können.

Der letzte Punkt bedeutet natürlich nicht, dass man keine Komponenten auf dem Zielsystem voraussetzen sollte. Jede Software hat bestimmte System Requirements. Es soll vielmehr verdeutlichen, dass die Systemvoraussetzungen klar definiert werden sollten und außerhalb dessen keine weiteren Komponenten mehr erforderlich sind. Besonderen Wert auf Betonung lege ich beim letzten Punkt auf „Informationen“. Damit möchte ich zum Ausdruck bringen, das dass Installationspaket (außer den mitgegebenen Informationen) idealerweise keinerlei weiteres Wissen erfordert um es auf dem Zielsystem zu installieren und die Software in Betrieb zu nehmen.

Deployment
Der dritte elementare Schritt im Release-Prozess ist der Transport des Software-Paketes auf die Anwendungsumgebung. Je nach Art und Quantität der Software kann dieser Verteilungs- bzw. Distributionsprozess viele verschiedenartige Formen und Schritte beinhalten. Dennoch lassen sich bei aller Varianz einige allgemeine Aussagen treffen:

• Die Funktionalität der Distribution muss vor der eigentlichen Verteilung verifiziert sein.
  Konkretisiert ist hier der Test und die Abnahme des gesamten Verteilungsverfahrens gemeint, undzwar noch bevor es zum offiziellen Deployment der Pakete kommt.
• Das Ziel – also alle bekannten Betriebsumgebungen – muss noch vor der Verteilung klar definiert und anvisiert sein.
  Dies kann auf vielfältige Art und Weise erfolgen, zum Beispiel mit einer automatischen Update-Funktion auf den Zielsystemen. Klar muss hier jedoch die Menge, Arten und idealerweise auch die Positionen der Zielumgebungen sein.
• Das Deployment muss beweisbar sein.
  Damit wird sichergestellt, dass das Installationspaket die Zielumgebung auch definitiv erreicht hat. Schlussendlich ist damit die Sicherstellung der Bedienung des Kunden der Software gemeint.

Installation & Inbetriebnahme
Der finale Schritt im Release-Prozess ist die Inbetriebnahme der Software auf dem Zielsystem. Auch hier sind abhängig von der Art und dem Einsatzgebiet der Software viele unterschiedliche Maßnahmen möglich. Doch wie auch im Deploymentschritt können über diesen letzten Schritt auch generelle Punkte zur Beachtung aufgeführt werden:

• Die Installation und Konfiguration muss nachvollziehbar sein.
  Im Detail heißt das: Die Installationsroutine sowie auch die gesamte Grundkonfiguration der Software muss protokolliert werden. Bei der Installation ist dies bei Verwendung geeigneter Installationssoftware nicht sonderlich aufwendig. Etwas komplizierter wird es beim Konfigurieren der Software. Es kann sich hier als einen ausgesprochenen Vorteil erweisen, einen guten Konfigurationsassistenten für die Software anzubieten.
• Die Installation und Konfiguration muss reversibel sein.
  Man mag vielleicht im ersten Augenblick denken, das sei selbstverständlich. Der Alltag beweist leider oftmals das Gegenteil. Vor allem bei Installationen von neuen Versionen einer Software, welches im Unternehmensumfeld wesentlich öfter vorkommt als im privaten Bereich, sind bei manchen Softwareherstellern deutliche Defizite erkennbar.
• Die korrekte Durchführung aller Schritte zur Inbetriebnahme muss überprüfbar sein.
  Konkret: hat man alles richtig gemacht, sollte im Idealfall der Kunde als auch der Hersteller darüber informiert sein. Es versteht sich fast von selbst, dass hiermit auch die Rückmeldung an den Hersteller gemeint ist, wenn es nicht gut gelaufen ist.

Abschließend bleibt mir eigentlich nur festzustellen, dass meine hier aufgezeigte, allgemeine Vorstellung eines Release-Prozesses doch noch in manchen Punkten von der Realität abweicht. Ergo: Es ist höchste Zeit, Änderungen in Gang zu bringen :-) .

Am einfachsten gelingt der Einstieg in das Tool mit dem Plug-In für Firefox. Damit kann man Tests sozusagen „live“ aufnehmen, abspeichern und bei Bedarf laden und wieder ausführen.

Möchte man noch einen Schritt weiter gehen und die Tests z.B. mit jedem Nightly Build automatisch ausführen, sollte man einen Blick auf Selenium RC werfen. Der ermöglicht es, mit .NET Unit- und Interface-Tests zu schreiben und Selenium automatisch zum Ausführen der Tests zu bewegen.

Ist man einmal soweit dass man seine Web-Anwendung automatisiert testen kann, möchte man das Tool nicht mehr missen. Bei richtiger Verwendung trägt es deutlich zur Verbesserung der Software-Qualität bei.

Dabei wurden nahezu alle Aspekte des Team Foundation Server durchleuchtet: Source Code Control, Work Item Management, Process Management & Communication, Build Management sowie Reporting Services. Kurz davor wurde noch auf den Aufbau des TFS, die unterstützten Prozesse und die verschiedenen Benutzergruppen (Projektrollen) oberflächlich eingegangen.

Source Control
Beim Source Control Management wurde die konzeptionelle Änderung der “Concurrency” gegenüber VSS deutlich gemacht. Bei einem solchen „Key Feature“ kann man einem User von Subversion nur ein müdes Lächeln abringen. Fakt ist allerdings auch, dass TFS die von z.B. SVN gewohnten Funktionen mitbringt: Check-in/-out, History, Tagging (unter TFS Labels), Branching, Merging – das gewohnte Repertoire. Elegant gelöst, aber bei weitem nicht neu sind die Check-in Policies. So kann man z. B. Kommentare, Code Analysis, Builds oder Test Runs vor dem Check-in erzwingen. Ein nettes Gimmick ist auch das sog. „Shelving“. Dabei werden die Source Code Files an den Server gesendet, allerdings nicht in einem Changeset (Revision) committed. Praktisch also nur am Server zur freien Verfügung abgelegt. Der praktische Einsatz in größeren Teams ist aus meiner Sicht für so etwas doch relativ begrenzt. Allenfalls lässt sich das Feature für Prototypisierung und Easy Change anwenden.

Work Items
Als nächstes Stand das berüchtigte Work Item Management an. An und für sich bietet hier der TFS eine art Issue Tracking System. Natürlich wurde die Integration in Visual Studio, Excel, Project und Sharepoint nicht unerwähnt gelassen. Interessant dabei war, dass man – sozusagen als Workaround – Work Items mit Hilfe von Excel auch offline bearbeiten und anlegen kann. Ein weiterer Aspekt bei Work Items ist die Flexibilität. Praktisch jedes Feld eines Items kann definiert werden – auch wie letztendlich dann das Formular für die Eingabe auszusehen hat.

Zusätzlich zu dieser Indiviualität des Work Items gibt es bestimmte, feste „Anhaltspunkte“ für Work Items. So kann man z.B. Items thematisch mit Hilfe von sog. „Areas“ – ähnlich Themengebieten kategorisieren. Dies kann übrigens – entgegen weitläufiger Meinung – auch hierarchisch gegliedert sein. Eine weitere Kategorisierungsmöglichkeit – diesmal mit Zeitbezug – beiten die Iterationsdefinitionen.

Besonders hervorheben möchte ich auch das integrierte „Workflow-Management“ für Work Items. Im weitesten Sinne arbeitet eine stark vereinfachte Workflow-Engine nach jeder Änderung eines Items definierbare Regeln und State-Transitions ab. Der Witz dabei ist die sehr bequeme Definition des Workflows mit Hilfe eines visuellen Editors. So kann man z.B. einfach und schnell den Workflow für den Work Item Typ „Bug“ an seine Bedürfnisse anpassen.

Apropos Anpassungsfähigkeit – der Team Foundation Server ist im Großen und Ganzen sehr flexibel und lässt sich in sehr vielen einzelnen Punkten anpassen. Angefangen bei Work Items über Process Guidance, Check-In Policies, Process Templates bis hin zur Sharepoint-Modifikation ist alles möglich. Allerdings bringt diese große Flexibilität auch Fallstricke mit sich. Anpassungen sind mit einem relativ hoen Zeitaufwand verbunden und greifen zum Teil Tief in das TFS-System ein. Dabei ist die Wahrscheinlichkeit einer Fehlkonfiguration deutlich höher als mit anderen etablierten Tools.

Das Thema Work Items bei TFS hat seit dem Release des TFS immer wieder eine Frage mit sich gezogen: Warum kann man Work Items nicht im Sharepoint editieren? Diese Frage ist mittlerweile mit „Verwende einfach TeamPlain“ zu beantworten. TeamPlain ist ein inzwischen von Microsoft aufgekauftes Drittprodukt zu TFS, welches für Work Items und einiges mehr eine Web-Oberfläche bietet. Das Tool funktioniert gut, ist stabil und freundlich zu bedienen. Im Übrigen ist der TFS von Haus aus sowieso „nahezu unverwendbar“ (O-Ton Sprecher des Vortrages). Erst das „Power Tool“ für TFS und weitere Add-Ons wie z.B. TeamPlain machen TFS für den Alltag richtig fit.

Testing
In diesem Zusammenhang möchte ich auch ein wenig in die Test-Thematik eingehen. TFS sieht von Haus aus eine „Tester-Rolle“ innerhalb des Entwicklungsprozesses vor. Dieser wird mit Hilfe der Tester-Edition von VSTS in die TFS-Familie eingebunden. Das einzig herausragende hierbei ist die Verknüpfungsfähigkeit von Tests zu Work Items und Builds. Für Automation stehen dem Tester „Test-Lists“ zur Verfügung, die z.B. nach einem Build automatisch durchgeführt werden können. Alle Test-Projekte werden auch in die Versionsverwealtung des TFS aufgenommen.

Schade ist nur, dass Team Foundation Server nur die eigenen – also von Visual Studio angebotenen – Test-Typen und –Projekte akzeptiert. Eine werksmäßige Unterstützung für andere Test-Frameworks sucht man leider vergeblich.

Es ist wohl eine Art von Brauch bei Microsoft, Produkte zu entwickeln die die Integration von bestehenden Systemen bzw. Dritt-Systemen schwerlich unterstützen. Generell ist bei TFS – bis auf das SDK – die mangelnde Zahl an offenen Schnittstellen ein Minuspunkt. Hoffentlich wird dies im Laufe der Evolution des TFS verbessert werden.

Build-Management
Beim Build Management wurde der Vortrag lebendiger; die Praxiserfahrungen wurden offen ausgetauscht. TFS unterstützt hiebei eine Reihe von Funktionen, die helfen sollen, bessere Releases und Roll-Outs durchzuführen. Das aus meiner Sicht wichtigste allerdings wird sträflich vernachlässigt: Automated Builds und Continious Integration. Vergeblich sucht man im Standardumfang des TFS Möglichkeiten für automatische Buildprozesse. Zwar kann man mit einigem Aufwand und ein paar Hilfswerkzeugen sich eine automatisierte Build-Umgebung zusammenschustern, aber bei einem System, welches den Anspruch hat den Software-Entwicklungsprozess optimal zu unterstützen ist diese Tatsache schon fast ein Armutszeugnis.

Ein weiterer Minuspunkt ist der mangelhafte Komfort beim Editieren der Buildscripts. Wenn man z. B. den TFS – welcher intern MSBuild verwendet – dazu bewegen möchte ein .NET 1.1-Projekt zu bauen, hat man außer der Installation von MSBee noch viele Stunden Scriptarbeit vor sich.

Alles in allem ist die Buildunterstützung für heutige Verhältnisse eher unbefriedigend. Da bleibt einem nur der Trost, dass Microsoft gerade hier kräftig nacharbeitet und mit TFS for Orcas deutlich verbesserte Buildfunktionalitäten anbieten möchte.

TFS – Vor- und Nachteile
Ich habe vor dem Vortrag den TFS schon kennenlernen dürfen. Nach dem Vortrag muss ich sagen, dass sich mein eigener Eindruck von TFS bestätigt hat. Kurz zusammengefasst die Pros and Cons aus meiner Sicht:

Vorteile:

• Gutes Konzept, Unterstützt nahezu komplett den Entwicklungsprozess
• Integration in Visual Studio
• .NET-Entwicklungen sehr gut unterstützt
• Extreme Anpassungsfähigkeit (Prozesse, Work Items, Workflows)
• Gutes Reporting und Monitoring

Nachteile:

• Langsam
• Fehlerbehaftet und z.T. Instabil
• Continious Integration absolut unbefriedigend
• Web-Oberfläche / Sharepoint-Support eingeschränkt
• Keine Backup-Funktionen oder –Strategie
• De Facto nur Online-Modus, keine Offline-Funktionalität (Thema Off-Site/On-Site)
• Installation, Wartung und Individualisierung aufwendig
• Kein klares Konzept bei Dokumentationsaufgaben (kein Wiki, keine Sandcastle-Integration)

So, nachdem ich aus einem Meeting-Bericht schon fast ein TFS-Artikel produziert habe, befürchte ich, dass meine Leserschaft ein wenig zu Müde ist für weitere Themen wie Bewertung von TFS aus Unternehmenssicht, Einführung des TFS in die Entwicklung, Vergleich von TFS zu anderen Systemen und noch einiges mehr. Falls Interesse besteht, etwas mehr in das Thema Team Foundation Server einzusteigen – einfach kommentieren oder bei mir melden.