DEV300 Visual Studio 2005 Team Foundation Server (TFS) Extensibility

Richard Hundhausen

...und noch eine VS Session. Diesesmal geht um TFS (Team Foundation Server).
Leider war mein Akku schon tot...aber ich versuche, in Gedanken nochmals wiederzugeben, was Richard Hundhausen erzählte. Es ging darum, wie man das VSTS customized.
Er erklärte, das man unterscheide zwischen Customizing und Extending. Customizing ist das "umkonfiguriern" und das Extending ist das erweitern mit Funktionalitäten, die das VS noch nicht von Hause aus mit sich bringt.
Zuerst zeigte er (alles Demo, fast keine Slides) wie und was alles man Customizen kann... Alles, es scheint das wirklich alles mit XML Files konfigurierbar ist. Er zeigte ein Beispiel, wie man (anscheinend sind schon sehr viele im Lieferumfang) Reports anpasst. Die Querys sind im XML Format abgelegt, ebenso die "View" des Reports. Alles lässt sich exportieren, anpassen und wieder importieren. Und die Einstellungen lassen sich dann natürlich Solution, Application oder Enterprise weit ablegen.
Er zeigte auch, wie man zum Beispiel das TaskManagement anpasst. So dass zum Beispiel (jetzt eines das ich an der RTC anlehne) bei einem Task, der ein Architekt einem Devekloper Team zuweist, die Call Nummer erfasst werden muss im VS. Oder in einem Medizinischen Umfeld die Patienten Nummer oder...oder.
Er zeigte auch, wie die Team Sites (SPS) den Bedürfnissen angepasst werden können. Dies ist aber, so denke ich, auch mit normalen SPS Kentnissen nachvolliehbar.
Nun ging es um Source Control. Anscheinend spricht M$ nicht mehr vom Source Safe, sondern eben von Source Control. So heisst es folglich auch Source Control Server.(Yukon). Die ganze Source Verwaltung scheint endlich erwachsen und brauchbar zu werden. Ich hoffe, ich kann noch ein Hands-On Lab machen mit dem Source Control. Hab gesehen, das es ein Lab gibt, muss aber zeitlich noch einwenig koordinieren. Interresant war dann wiederum das Customizing der Check-In Policys. Es hat viele vorbereitete Policys, aber diese lassen sich (XML was den sonst) auch erweitern, bzw, den eigenen Bedürnissen anpassen.

Am Schluss wurde noch kurz über das Erweitern gesprochen. So gibt es ein vollumängliches VS API zu Launch. Zudem ist das Visual Studio Toolkit momrntan in der Beta2 und solltr mit dem VS Launch auch verfügbar sein.

ARC310 Microsoft Visual Studio 2005 Team Edition for Software Architects: Developing Logical Datacenters

Michael Leworthy

Nochmals eine Session über den VSTESA (Visual Studio Enterprise for Solution Architects).
Es geht wieder um das zusammenarbeiten von Application Developers, IT Professionals and Information Workers.

DSI (Dynamic System Iniative, M$ intern) war der Auslöser, und der Zentrale Steuerpunkt ist wiederum das SDM. (System Definition Model = a formal model of a complite solution)
Die verschiedenen Layers des SDM sind: Der Aplication Layer, Aplication Hosts, die Network Topoligie und die Hardware.
Danach werden die im neuen VS integriertn Designer gezeigt: Logical Datacenter Desiner, Deployment Designer, System Designer und der Application Designer.
Die Session ist hauptsächlich auf das theoretische Modeling ausgelegt, und wie man schlussendlich dazu kommt, dass das Model dann auch die Wirklichkeit trifft.(Es wird viel vom MSF 4.0 gesprochen)

ARC309 Microsoft Visual Studio 2005 Team Edition for Software Architects: Developing Service-Oriented Systems

Eric Lee

Diese Session begann wie die letzte, mit einer Übersicht über die VS Architektur.
(siehe bild)

Eric erklärt, für wen sie die 4(!) Visual Studios gedacht haben. ( Express, Standard , Professional and Team System. )
Der Fokus dieser Session ist der Software Architect.
Zuerst erklärt Eric seinen geschichtlichen Hintergrund,er war früher memeber des Windows Server Developer Teams, heute ist er der Technical Product Manager der VS. Er erklärte, wie sie bei der Entwicklung von Windows 2003 Server zum teil Testeten
So hätten sie zwar einige Hardware rumstehen, dennoch seien gerade die Data Centers ja zum Teil Customized. So seien sie alle Major Build (so alle 5-6 Wochen) ein wenig Weg von Redmond gereist und hättem bei Kunden an "Live" Systemen ihren neuen Build getestet...

Die Frage für den Architekten stellt sich immer wieder:
Wie kommuniziere ich das Design den Entwicklern ? Wie erriche ich, das die Operational Policy verstanden wird...
Alle im VS erstellten Visual Documents sind synchronisiert. Jedes dieser Dokumente hat schlussendlich einen irgendwann Einfluss auf den Code.
Key der Architekten-Sicht ist: Executable design, Deployable design. Das Design mit dem Code synchronisieren. Das ganze VSTS hilft zu verringern, das Kommunikationsschwierigkeiten zwischen den Architekten, Development Tester und den Operational-IT Guys entsehen...so zumindest die Ansicht von M$.


Danach folgte eine Demo :
Er zeigt im Designer, wie er an einer bestehenden Web Applikation mit einer DB Connection(Yukon) 3 Webservices hinzufügt. 2 davon existieren bereits "real" 1'er nicht. Er beschreibt den noch nicht existierenden Web service und lässt sich den Code automatisch generieren.
Er fügt die Web Services in die Toolbox, so das er via Drag and Drop jederzeit auf seine "generischen" eigens erstellten Web Services zugreifen kann.
Dies geschieht alles auf der Design Basis.Der Code wird immer automatisch aktualsiert. Ändert ein Developer Sachen im Code, das Design ändert immer mit, so das der Architekt immer ein aktuelles Design hat. Die Dokumentantion enstricht so immer der Realität.Ich denke das wär noch was für uns...siehe SoftinstLib...

Das Problem bei den IT-Operational People sei, wie beschreibe ich meine Policys? Wie komme ich auf Policys, welche der Business Logik und den Developer Bedürnissen entsprechen...
Darauf wird das SDM als "die" Lösung präsentiert.(SDM = System Definition model (XML File, das generiert werden kann. Diese System Definition dient danach allen als Grundlage, egal ob wir auf Hardware Level, Host Level etc. arbeiten. Grundlage ist immer das SDM.

DEV260 Microsoft Visual Studio 2005 Team System: Managing the Software Lifecycle with Visual Studio 2005 Team System

Zuerst wurde versucht, einen gesamt Überblick darzustellen.
Das Team System ist auf 3 verschiedene Rollen zugeschnitten, bzw. gedacht.
Architects, Developers and Testers.
Es wurde die grundlegende Schematik vom Studio aufgezeigt, welche zeigt, das die "Engine" natürlich immer die selbe ist und für die einzelne Rollen spezialisierte Versionen entwickelt wurden.(Extensions)
Ziel sei es, fuer den gesamten Entwicklungsprozess nur nochh ein Tool zu benoetigen, eben VS.
Danach wurde eine Demo mit einer kleinen Web Applikation gezeigt, mit Outlook Extension und dem Team Foundation Server..
Die Web Applikation war so aufgebaut, das der Speaker auf New Task klicken konnte, und die entsprechenden Entwickler erhalten im Studio und im Outlook einen neuen task ...
Danach wurden die Visualisierungs-Tools gezeigt, wo man die Prozesse abbilden kann, mit den Properties belegen... wie lange z.b. braucht die Entwicklung dieser Komponente. Wie soll sie aussehen...(dies ist die rolle des architekten) und am
Ende klickt er auf Project Plan und wir haben einen Projektplan, der genau so aussieht wie wenn man ihm mit Project erstellt hätte... aber auch hier kann man wieder "reinklicken" und die Details die man mit vorher angegeben
hatte anzeigen. Das ganze kann auch auf einer SharePoint Seite dargestellt werden, so dass alle sehen können, wo steht das Projekt, wie geht es weiter etc.

Danach wurde im Designer gezeigt, wie man einer Komponente W2K3 SP1 als zwingend angibt... es wurden die vielen verschiedenen Views gezeigt...und dann klickten sie deploy to my ...und dann kam nach einem kurzen Moment eine Meldung in der Taskliste die besagte, das 1 Server noch nicht sp1 habe und auf diesen nicht verteilt werden kann...

danach bauten sie im Designer ein paar Klassen, die Methoden etc. und im Hintergrund wurde immer gleich der Code automatisch generiert.
Danach mal auf eine Klasse, Rechte Maustaste, "build unit tests"... und gleich werden alle Units Tests automatisch generiert. Natuerlich kann man auch gleich die Tests anstossen. Klassen, die durch die Unit Tests abgebildet werden, sind grün dargestellt.Solche, die nicht gedeckt werden oder den Test nicht bestehen, sind rot.

Unit Testing und Code coverage... wow ! eindrücklich, ich will gleich damit arbeiten ! ..hat mich impraegniert ...

Dann zeigten sie noch den Performence und Analyse Report... dieser kommt gleich mit Vorschlaegen, wie die Klassen optimiert werden könnten....


Gewaltig, das gsamte Studio scheint noch riesieger geworden zu sein, denke, dass biss man das Teil versteht und damit alle arbeiten können, werden noch ziemlich viele Tage vergehen....
Zu guter letzt wurde noch die check-in Policy erklaert.
...er wollte was einchecken, das gegen die Policy verstiess (kann auf solution ebene frei definiert werden vom Architekt)...danach kam ein Dialog mit einer Erklaerung, weshalb er nicht einchecken koenne so (Er hatte den KlassenNamen nicht nach der Vorgabe erstellt),trotzdem konnte er dann aber "check-in,ignore policy" klicken und musste dann einen Grund angeben weshalb er gegen diese Policy vertoesst.
M$ hat mit der hauseigenen Security Initiative all ihren Code mit einem Checker getestet...dieser koenne man auch einschalten, dann kommen Meldungen, was nicht sicher sein soll und gewisse Sachen (welche bekannt sind) werden auf Wunsch auch gleich geändert...

Zum Testen:

Waehle "create a test"...rechte maustaste... web test... und es wurde automatisch ein interface gemacht... und dann konnte man die Klasse in einem Web Fenster testen... sah aus wie die seite, die man macht, wenn man einen web service "testet". (natuerlich ist alles in XML)
WOW...dann zeigte er, wie der Tester sich durch die Tests angelt... am Anfang hatte er bei einer Komponente (mit DataSet) als requirement angegeben, das die Zeit zum laden der Daten nicht mehr als 3 sekunden dauern duerfe. ..er spielte im Test einwenig rum, und plötzlich kam eine Meldung, das aus der Architektur Phase designte requierement nicht erfüllt werde.... Dazu gleich wieder ein Report in HTML ....

Mich habe sie schon... bin ein kleiner Fan vom neuen Studio !

KEY001 Ready For Business Andrew Lees

Die Keynote hat mich nicht wirklich vom sockel gehauen.
IHMO war es ein guter Marketing speech... Die Demo mit den RFID Tags war dann aber schon noch spannend. Sie zeigten eine Graphik wo man das RAI sah (RAI= Conference Center) und viele kleine Punkte...die Punkte sind dann die einzelnen Delegates. War lustig zu sehen, wie sie "rumlaufen". Das war es dann aber auch schon...bin dann rausgegangen, kaffe trinken und ein feines "Gipfeli" essen... die liegen einfach da und rufen einem zu ..."iss mich".. ;-)

Ich bin mir noch nicht klar, welche Sessions ich am Nachmittag besuchen soll... es sind gleich mehre, die mich interressieren. Schade ist, das diese alle nur 1x stattfinden...
Melde mich wieder, wenn ich erste Session Infos hab.