Da ich in der Vergangenheit hier einen bunten Mix an Themen abgearbeitet habe, werde ich in Zukunft alle Technik-Themen auf meinem neuen Blog abhandeln.
Ihr findet ihn unter
www.developersdevelopersdevelopersdevelopers.net
Hier gibt es in Zukunft nur noch Fotos oder irgendwelche Belanglosigkeiten.
Im Visual Studio gibt es ein Feature das “Reconcile” heißt. Wenn es eine Kategorie der unbekanntesten Features in Visual Studio gäbe, dann wäre das sicherlich in den top 10%. (Also irgendwo in der Nähe von “Cloak”)
Mit Reconcile kann ich mir den Unterschied zwischen einem lokalen Folder und dem Stand im TFS anzeigen lassen. Wenn man weiß, wo das geht ist es auch ganz einfach. So kommst Du hin:
Im SourceControl Explorer einen Ordner anwählen, Rechtsklick darauf machen und “Compare” wählen. Im folgenden Dialog ein paar Einstellungen zur Anzeige machen. Hier kannst Du auch wählen, gegen welche Version auf dem Server Du vergleichen willst.
Klicke auf OK. Im nachfolgenden Dialog kriegst Du – abhängig von Deinen Einstellungen – angezeigt, welche Files wahlweise nur auf Platte oder nur auf dem Server vorhanden oder unterschiedlich sind.
Das wichtigste kommt aber noch: Der Reconcile Button! Leider ist der Button recht unscheinbar und auch nur enabled, wenn Du einen Eintrag in der Liste markiert hast: Wenn Du jetzt einen Eintrag aus der Liste markierst und “Reconcile” drückst, erscheint folgender Dialog:
Hier hast Du die Möglichkeit den lokalen Stand auf dem Server einzuspielen, bzw Deinen lokalen Stand zu aktualisieren. Dass kann ganz hilfreich sein, wenn man aus irgendwelchen Gründen mal außerhalb des gewohnten Workspaces arbeitet oder aber mal ein paar Dateien hin und herkopiert hat.
Schön ist: Wenn Du vorher noch wissen willst, welche Unterschiede zwischen Files auf lokaler Platte und auf dem Server bestehen, kannst Du über einen Rechtsklick aufs eine Datei “Compare” aufrufen und die beiden Stände vergleichen.
Von den fleißigen ALM Rangers gibt es wieder wertvolle Beiträge für die Arbeit rund um den TFS und Visual Studio.
Zum einen den Build Customization Guide, zum anderen eine Anleitung wie man am besten Lab Management einsetzen kann.
So, hier noch mal eine Sammlung von wertvollen Links mit Info über die nächste Version von Visual Studio:
Brian Keller (Evangelist bei Microsoft USA):
Hier gibt’s auch ein ganz witziges (aber vielleicht auch etwas unhandliches) Speakflow-Chart zum Download.
Brian Harry (TFS Oberguru bei Microsoft USA):
Christian Binder (Platform Strategy Manager bei Microsoft Deutschland) hat dazu auch einen Webcast gedreht:
http://blogs.msdn.com/b/cbinder/archive/2011/05/28/webcast-preview-visual-studio-vnext-alm.aspx
Jason Zander (Microsoft USA Vice-President) hat auch sehr ausführlich geschrieben was man so erwarten darf:
Hier findet sich auch ein Link zu einem Whitepaper für vNext:
http://go.microsoft.com/?linkid=9772730
Ich freu mich momentan besonders über die wesentlichen Verbesserungen in der Webansicht, über die integrierten Codereviews und über “Intellitrace in Production”. Sehr cool!
Jeder, der den TFS 2010 im Einsatz hat und sich über die hierarchischen Work Items in der 2010er Version freut, wird früher oder später ganze Subttrees von Work Items auf einmal kopieren wollen. Eventuell auch nur die Userstories, aber nicht die Tasks. Oder die Userstories und die zugehörigen Testfälle, aber nicht die Tasks.
Das Ganze wird dann gerne mal – eventuell noch um ein paar Anforderungen erweitert – als Baselining oder Versioning bezeichnet. Der TFS kann das standardmäßig nicht, so dass es bisweilen lange Gesichter gibt, weil einem die hierarchischen Work Items plötzlich gar nicht mehr so wertvoll vorkommen. Aaaaber, wie wir in der Vergangenheit schon des Öfteren gelernt haben, kann der TFS eigentlich alles – es hat sich nur noch nicht für jedes Thema auch schon jemand gefunden der es mal implementiert hat, um zu beweisen, dass es wirklich geht. 
In diesem Fall schon: Seit gestern ist in der Visual Studio Gallery Work Item Tree Copy verfügbar. Damit können Subtrees von Work Items, die auf Parent/Child Beziehungen beruhen rekursiv kopiert werden. Dazu gibt es einen ganzen Sack voller Optionen, inklusive der Möglichkeit Hyperlinks umzubiegen, Changesetlinks zu erhalten etc, etc, etc.
Entstanden ist das Tool übrigens (wieder mal) unter Zuhilfenahme des (großartigen) Feature Builder Power Tools.
Ist das der Hit? Ich würde sagen: Ja! Probiert es aus! Wenn Ihr Fragen habt oder Feature vermisst, meldet Euch beim Autor. Der freut sich bestimmt.
Freudige Neuigkeiten für alle VS2010 Fans: Es gibt einen ganzen Sack voll neuer MSDN Webcasts, die über eine ansprechende Silverlight-App von Christian Binder und Dariusz Parys gebrowsed werden können. Einige der Webcasts habe ich beigesteuert, einen zum Thema Architekturvalidierung und einen zum Thema Code-Visualisierung. Hoffe es hilft ein bisschen bei der Orientierung in diesem umfangreichen Themengebiet…
Edit: Vielleicht nicht zwangsweise informativ, aber immerhin amüsant ist das Announcement auf der offiziellen Visual Studio Website (Monitore te salutant). :-)
Wie schon in einem alten Blogposting erwähnt stellt Microsoft selbst jetzt ein Scrum Prozess Template für den TFS zur Verfügung. Bisher war dieses bereits als Beta verfügbar. Ich bin gespannt, ob die Strukturierung der Workitems über den Workitem-Typen “Sprint” nur als Übergangslösung zu sehen ist, oder ob das die neue Stoßrichtung für Dev11 vorgibt. Bisher wurde die Sprintzugehörigkeit ja ausschließlich über Attribute geregelt. Aus eigener Erfahrung weiß ich, dass das immer wieder für heiße Diskussionen sorgt. Da das Template kostenlos über die VS Gallery kommt, empfehle ich, sich das Ganze einfach mal anzusehen.
Visual Studio versteckt ja so einige Perlen, die man erst nach und nach entdeckt. Eines dieser mitunter wertvollen – aber auch reichlich unbekannten Features - ist das “Cloaking”. Wie geht das, was ist darunter zu verstehen, wofür ist es gut?
Wie geht’s?
Man kann im Visual Studio – unter Verwendung von Team Foundation Server als Quellcodeverwaltungssystem –. beliebige Ordner und Branches im Source Control Explorer über das Kontextmenü “Cloaken”. Einfach Ordner anwählen, rechte Maustaste, Cloak. Die Inhalte der Folder werden dann im SourceControl Explorer ausgegraut dargestellt.
Was bewirkt das?
Das hat zu Folge, dass die “gecloakten” Inhalte nicht mehr vom Team Foundation Server nachgeladen werden – auch wenn zum Beispiel auf den übergeordneten Ordner ein “Get Latest” ausgeführt wird.
Wer braucht das?
Man stelle sich die Situation vor, dass man als Mitglied eines Entwicklungsteams bestimmte Bereiche der Quellcodeverwaltung schlicht und ergreifend nicht benötigt. Zum Beispiel, weil darin Quellcode für Komponenten entwickelt wird, mit denen man nie in Berührung kommt, und deren Schnittstellen einem auch herzlich egal sein können. Oder Branches, auf denen man eben gerade nicht arbeitet. Oder es liegen dort zwar Dateien, diese sind aber nicht für das Produkt selbst, sondern für die Herstellung der Binaries relevant – zum Beispiel Buildskripte. Dann ist genau der richtige Zeitpunkt um zu “Cloaken”.
Welchen Vorteil bringt es?
Das Cloaken bringt folgenden Vorteile mit sich:
1. Zeitersparnis – beim Ausführen des “Get Latest” Befehls werden gecloakte Unterordner nicht mit vom Server geladen. Unterm Strich geht’s also schneller, bis man die neueste Version der benötigten Files auf seiner lokalen Platte hat.
2. Bandbreitenersparnis. Aus genau dem gleichen Grund. Aus eigener Erfahrung kann ich berichten, dass Bandbreite in vielen Firmen noch ein wesentlich limitierender Faktor ist, als man im Jahr 2010 erwarten würde. Gut also, wenn man hier auf einfache Weise was sparen kann.
3. Plattenplatzersparnis – es werden weniger Files geladen. Man kann also, wenn es sinnvoll ist, gewisse gemappte Folder einfach nie getten – nicht mal einmalig. Bei riesigen Quellcodebeständen spart man sich so haufenweise Plattenplatz. Natürlich geht das nur dann, wenn man den entsprechenden Quellcode nicht doch lokal benötigt…
Gibt’s auch Nachteile?
Ja. Größter Nachteil ist, dass man genau wissen muss, was man tut. Es ist zwar einfach zu bedienen, aber man muss sich bewusst sein, dass die gecloakten Files zwar noch physikalisch auf der Platte liegen (wenn sie überhaupt schon da waren) – d.h. sie können auch referenziert werden (bspw Dlls) – aber die neueste Version eben nicht mehr automatisch vom Server geladen wird (was ja auch Sinn und Zweck ist). Wenn man also mal “vergisst”, dass man Cloaking verwendet hat, läuft man Gefahr Inkonsistenzen zu produzieren. Also: Mit Bedacht wählen was gecloakt wird – natürlich kann man es jederzeit wieder rückgängig machen.
Wen betrifft meine Cloaking-Einstellung eigentlich?
Sehr gute Frage, die immer wieder gestellt wird und bereits mit der Überschrift dieses Posts beantwortet wird: “Cloaking is a private thing” – man trifft diese Einstellung also immer nur für sich alleine und immer nur für jeweils genau einen Workspace zur gleichen Zeit. Das ist eigentlich auch sehr logisch. Den Ordner BuildProcessTemplates beispielsweise kann so ziemlich jeder im Team gefahrlos cloaken, bis auf diejenigen, die tatächlich daran arbeiten – also eben z.B. der Buildmanager. Eine Entscheidung auf Teamebene was geclaokt wird und was nicht wäre also ziemlich sinnlos.
Das gleiche gilt für Workspaces: Die Einstellungen für Cloaking kann für den Laptop zuhause grundlegend anders sein, als die Einstellung für den Arbeitsplatzrechner im Büro.
