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/
Keine Kommentare:
Kommentar veröffentlichen