Generelles Fazit

Ich möchte Euch natürlich meine pers.Eindrücke von der TechEd schildern. Die Sessions habe ich ja bereits die meisten kommentiert.
Leider war der Anflug nicht so angenehm. Wir hatten fast 2 Stunden Verspätung und jede menge Turbulenzen. Aber ich habs ja dann geschafft. Das Wetter war,bis auf Donnerstag, ziemlich kalt und nass. Aber ich war ja nicht da, um Ferien zu machen.
Die Leute scheinen so ziemlich die selben zu sein, wie vor 2 Jahren in Barcelona. Soger der Guy mit dem Irokesen Schnitt und dem Windows Tatoo lief wieder herum ;-)
Ich muss Euch leider enttäuschen, ich werde Euch keine Gadgets heimbringen können. Ich war zwar 2 mal kurz in der Austellerhalle, aber es hatte sooo viele Leute und es war so ein riesen Gedränge, das ich keine Lust hatte, für ein T-Shirt oder sonst was, mir die Rippen mit den Elbogen von wildfremden Leuten massieren zu lassen. Es war grundsätzlich schwieriger als vor 2 Jahren, ich hatte auch den Eindruck, das sparsamer mit den Giveaways umgegangen wurde. Zudem musste man überall irgendein Spiel machen oder zuerst ne Show anschauen etc. was sehr Zeitintensiv ist. Da ich alleine da war, habe ich eher geschaut, alles Sessions, die mich interressieren, zu sehen. Und das war nicht einfach, da es doch mehrer Tracks gab, die mich wirklich interressiert hätten. Ich habe meinen Fokus auf das VSTS gelegt, denke auch, das dies noch am ehsten etwas ist, was wir in der RTC einsetzen bzw. als nächstes sehen werden.(Ok, SMS sind wir noch lange nicht soweit und WSUS steht eh vor der Tür. Zudem waren die Sessions über SharePoint und InfoPath IHMO auf einem Level, den wir bereits heute erreicht haben)


Die Organisation des Events war wiederum nahzu perfekt. Einziger Nachteil gegenüber Barcelona war, das man am morgen mit dem ÖV aufs Gelände musste. Dies aber nur deshalb, weil die Trams immer so überfüllt waren, dass es beinahe unmöglich war, Platzt zu finden. In Barcelona war ja noch ein Shuttle Dienst organisiert worden. Dies war aber wohl eher aus dem Grund, weil in Barca der Öv nicht so zentral vor das Ausstellungszentrum fuhr, wie hier.
Wireless Access war zwar überall möglich, aber funktionieren tat es eigentlich nur am frühen Morgen oder späteren Abend. Denke, dass das Netz einfach über belastet war. Das ständige Connection verlieren und wieder Netzt suchen ...verbinden etc. war sehr mühsam, und ich hatte so sogar einige Datenverluste. (Wenn du am bloggen bist, und beim publishen eines Eintrages die Connection weg geht, kann dies vorkommen) .
Microsoft legte an dieser TechEd den Fokus ganz klar auf:

SystemCenter 2005 (War überall präsent, nur nicht so in den Sessions)
SQL2005
Visual Studio Team System and Foundation Server
Indigo

Des weiteren wurden gewisse Begriffe gepusht. So war das SDM (System Definition Model) und DSI (Dynamic System Iniative) immer und immer Thema oder wurde angesprochen.

Tech Ed Party (Studio7)

Die Party war, wie nicht anders zu erwarten, DER HAMMER. Es war aber auch wieder einfach gut gemachte Werbung, und das können Sie definitiv. Wer schon mal an einer TechEd Party war, weiss was ich meine. Diesemal fand ich die Party allerdings nicht so gut wie in Barcelona, vermutlich war es aber darauf zurückzuführen, das ich 1. Alleine war und 2. wusste was mich erwartet. Gegessen wird sicherlich jeder Besucher genügend, gab es doch auch wieder reichlich Auswahl und Mengen, die sicherlich nicht gesund sind ;-)

Dieses Mal waren 2 Live Bands auf der Bühne. Die ScizzlerSisters und die Band NU2. Die Sister waren gut, brachten shon ziemlich Stimmung in die Halle. Bei der 2.Band handelt es sich um eine U2 Coverband. (holändisch N = sprich neuw) . Diese spielte sehr gut, sogar der Sänger sah beinhahe wie Bono aus.






Es gab noch 2 Lounges, die Scizzlers Lounge und die Vertigo Lounge. (Für jede Band eine).In der Scizzlers gab es verschiedene Shots aus dem Reagenzglas, in der Vertigo gab es Wodka und sonstig hartes Zeug in Eis Form. War sehr süss und lecker. Stellt euch eine Glaceverpackung vor, die man oben aufreissen kann. Es befindet sich kein Stil in der Verpackung sondern einfach Eis, das man dann durch die Öffnung in den Mund drückt. Den Alkohol merkte man aber überhaupt nicht, sondern es war einfach sehr süss.

Lustig war auch die Karaoke Ecke und sehr lustig, wie sich mancher im Singen versuchte. Interressant, zu was sich so seriöse IT Hoschis hinreissen lassen, wenn man ihnen 2 , 3 Heinekens gibt. Dann gab es noch einen "Echten" Töggelikasten. In diesem Standen anstelle der "Töggel" dann einfach echte Jungs. War lustig zum zuschauen.



Ach ja, ein Kino hatte es auch noch, aber Sie zeigten leider Movies die ich schon gesehen habe. Ich ging dann relativ bald ins Hotel zurück, hatte ja noch was zum schreibe. (unter Anderem dieser Bericht).
Am Freitag morgen waren dann wieder aufällig wenig Leute an den Sessions.....

Hands-On VSTS

Am Freitag wollte ich noch ein sog.Hands-On Lab machen. Ehrlich gesagt habe ich eine Stunde rumgeklickt,hab ganz tolle Sachen gemacht mit dem neuen Studio....
Ich kann und will hier eigentlich nicht mehr schreiben... Ich bin kein wirklicher Freund dieser Labs, weil man einfach nach Anleitung arbeitet, und eigentlich nie weiss, weshalb man was macht. Jetzt klicke hier und mache dies, dann tu dies etc. Weshalb das man dies tut, ist schwierig zu ergründen. Somit hält sich dann auch der Lernprozess in Grenzen, zum. bei mir.

DEV466 Microsoft Visual Studio 2005 Team System: Enterprise-Class Source Control

Brian A. Randell, Ashwin Karuhatty

So, und nun die letzte Session... wieder über das neue Studio, jetzt geht es aber nur um Source Control. Dies ist ein Thema, das mich brennend interressiert, hatten wir in der Vergangenheit mit dem Vorgänger Source Safe schon unsere einschlägigem Erfahrungen gemacht.
Der Zufall wollte es, das sich neben mich Eric Lee setzte... cool guy !
Mit Source Control seien der Check-in über das internet mögliche, und es werde nie korrupte Files geben.
Natürlich kommt jetzt der geschichtliche Abriss ,und der Hinweis, das Source Safe nicht sehr gut war. (Wem sagen sie das...) Dies war auch Grund, nun was "richtiges" zu machen. Es braucht nicht das Studio um Files einzchecken zu können, es gibt ein seperates Program. Nun erklären sie, was sie unter Team Foundation verstehen.

Es geht im Workflow und die Prozesse, welche in einem Software Lifecycle vorhanden sind. Die Build Automation war das Hauptaugenmerk bei der Entwicklung.Jedes Projekt hat eine SharePoint Portal Seite und die Zugriffe können sehr granular gestaltet werden. Jetzt kommt die Aussage: SOURCE SAFE IS DEAD !! und dafür erhalten sie tosenden Applaus.
Das neue Source Control ist von Grundauf neu entwickelt worden. Es können auch WorkItems , Tasks etc. mit eingecheckt werden. Das Source Control ist eine 3-tier Applikation, basierend auf SQL2005, und einem ASP - Web Service. Visual Studio 2005 enthält alle Tools, so auch den Source Control Explorer. Wer Studio hat, braucht keine zus.Tools. Ziel war es auch, das Team Orientiert gearbeitet werden kann. Das Visual Studio Team Foundation Team braucht intern seit Januar das Source Control, das seien 700 Programmierer...und nicht selbstverständlich, das M$ ihre Tools brauche. Bis Ende Jahr werden bei M$ alle Produkte Teams mit dem Foundation Server und Source COntrol arbeiten (+20'000 People (!)) . Der Key - Feature Support sei: Atomic Check-In, Work Item Integration, Checkin Policies (also Enterprise Policies), Shelving, Delta File Storage, Delta Binary File Storagem, Large File Support (>4GB), Distributed Team Support, E-Mail Checkin Notification, Non-Windows Support, Shared Checkout, VS2003 Integration (!). Pinning is not Supported.
Pinning is eval ... und werde nicht benötigt, so wie Sie es danach in der Demo beweisen werde. Foundation Server habe besser Lösungen zu bieten.Nun erklären Sie, wie die Check-in Policies funktionieren. Der Policies check geschieht auf dem Client und dem Server, und man kann konfigurieren, was wo gecheckt wird. Die Policies lassen sich via policy plug-ins erweitern. Der Compiler macht eigentlich schon den check, ob sich was kompilieren lässt. Aber es gibt eine Menge andere Sachen, die via Policies gesteuert werden müssen bzw. können. (Formatierung, Casing,Naming etc.)
Nun folgt eine Demo des Check-In Prozesses. Beim Checkin wird der gesamte Code, Zeile für Zeile gescannt.Sie zeigen, wo und wie man die Policies aktivieren kann. (Auch für den Project Manager, der diese natürlich global setzten kann.) Sie zeigen die Dialoge, welche erscheinen, wenn man den checkin machen will. Es erscheinen Fehler etc, wenn zb. die Policy nicht "trifft".

Sahred checkout... derjenige der auscheckt, kann entscheiden, ob es sich um ein Shared Checkout oder Exclusive Checkout handelt. Default ist Shared Checkout. Natürlich lässt sich dies auch wieder enterprise-wide Regeln. Sie zeigen wie man definiert, das .jpg und bmp files nur exclusiv ausgecheckt werden dürfen. Wie ein File ausgecheckt wurde, ist im Source Explorer jederzeit anhand verschiedener Icons ersichtlich. Es sind für jedes File beliebig viele Workspaces(!) definierbar. Nun ändert er ein File, und die Änderung ist nur in diesem File für diesen Workspace erfolgt. Ich kann ein File nur für diesen Workspace einchecken. Wenn das File im Studio offen ist, kann oben jederzeit der Workspace geändert werden, und ich habe das selbe File im Projekt in versschieden Versionen. Wenn ich jetzt das File bzw. die Version einchecken will, welche nicht gändert wurde, kommt eine Warnung. Ich kann nun Resolve Conflicts klicken, und ein neuer Dialog erscheint, wo ich die Files sehe und was geändert hat wo und wann, von wem etc...
Branches...pooh, ziemlich komplexe Geschichte.Das Promotion Modell erlaubt, nur spezielle Änderungen un den Build einfliessen zu lassen. Ich kann nun Weiterentwickeln. Bei einem Patch kann nun gesagt werden, das in diesem File nur die Änderung xxx in die Build Version einfliesst. Bsp: Wir entwickeln weiter am Release 5.08. Im August müssen wir einen Patch liefern. Die Änderung wird getätigt, der Build basiert jetzt aber auf 5.07 mit der Patch Änderung. Dies obwohl das gesamte File Weiterentickelt wurde.M$ nennt die Branches, Producion, Test , Developer Branch etc. Ich kann jederzeit schauen, was wie wo anders ist in den verschiedenen Branches.
File Storage. Die Original Files und das letzte eingecheckte File werden komplett gespeichert. Die Files werden beim einchecken komprimiert. Jede Nacht läuft ein "Deltafier", der nach den Deltas sucht ... . Aussage: Diese Art des Speicherns spart ca 70% File Space gegenüber den "herkömmlichen" Speicherarten von Source Controls. Beim Auschecken wird zuerst geschaut welche Version des Files bereits lokal liegt, und nur das Delta kommt auf den Client. So seien auch grosse Files via Internet ein und auszuchecken ohne Probleme und riesen Bandbreite.Dazu kann ein Source Control Proxy eingesetzt werden. Nun zeigen Sie, wie der Proxy funktioniert und was dieser für ein "Performance boost" bringe.

Es gibt wieder ein Command Line Tool. Der Automated Build lässt sich aber nun auch via Gui steuern. Es wird Unix,Linux und Mac OS Supported. Nun zeigen sie eine Demo auf einem Linux Client. Dies natürlich nicht ohne markante Sprüche zu machen... Lustig, wie sie mühe haben, das File auf der Platte zu finden. So oft arbeiten sie bestimmt nicht mit Linux.Sie ändern das File, checken es wieder ein und zeigen dan auf dem XP Client, das die Änderung selbstverständlich nachvollzogen wird. Ziel sei es, das an einem Projekt mehre Leute mit verschieden OS arbeiten. Es soll so möglich sein, auch gleich Cross-Platform Entwicklungen und Tests mit Source COntrol zu machen.
Nun folgt die Übersicht, wie momentan das Foundation Team arbeitet bzw. die aktuellen Zahlen über die Benutzter von Source Control.

Sehr interressante Session, ich freue mich jetzt schon darauf, wenn wir bei uns Source Control einstzen werden... und hier noch das blog, werde ich selbst sicherlich nachlesen.. http://www.mcwtech.com/cs/blogs/brianr/