Der Team Foundation Server bietet ein extrem flexibles und leistungsfähiges Konzept zur Definition von Work Items. Damit lassen sich viele Szenarien über eine reine Konfiguration abbilden. Um die Mächtigkeit zu demonstrieren, hier ein paar Beispiele. Diese Beispiele nutzen den Process Template Editor der Bestandteil der kostenlosen Team Foundation Server 2010 Power Tools ist. 1.) Nur bestimmte Benutzer sollen ein Workitem eines bestimmten Typs anlegen dürfen Ein verbreitetes Szenario ist, dass nur ein bestimmter Personenkreis Workitems eines bestimmten Typs (in diesem Beispiel der Typ Bug) anlegen dürfen, andere Benutzer sollen diese aber weiter bearbeiten können. Auch wenn die Umsetzung nicht ganz ideal ist lässt sich diese Funktion mit dem TFS relativ einfach erreichen. Wie im Screenshot zu sehen, ist der Status Active für diesen Benutzer ungültig. Damit kann er das Workitem nicht speichern. Wie gesagt, nicht gerade schön aber wirkungsvoll. Wie erreichen wir nun diese Funktion? Im Process Template Editor sehen wir im Workflow des Bug-WIT eine Transition von nirgendwo nach Active Diese Transition wird verwendet wenn ein neues Workitem angelegt wird. Auf dieser Transition können wir nun eine Berechtigung einstellen. Dazu geben wir in das Feld “For” eine TFS Gruppe ein die diese Funktion ausführen darf. Alternativ kann bei “Not” eine Gruppe angeben die diese Transition nicht nutzen darf. Dieses Feature kann natürlich auch für Transitions zwischen zwei Status genutzt werden, also z.B. um zu steuern wer den Bug schließen darf. 2.) Ein Feld muss gefüllt sein wenn ein anderes einen bestimmten Wert hat In der Praxis kommt es häufiger vor, dass iin Abhängigkeit eines Wertes ein anderes Feld ausgefüllt sein muss. In unserem Beispiel nehmen wir mal an, dass auf dem Bug die Repro-Stepsausgefüllt sein müssen wenn der Bug die Priorität 1 hat. Dazu stellen wir auf dem Feld Repro Steps eine WHEN-Regel ein Und sagen wenn diese Bedingung erfüllt ist, dann soll das Feld ein Pflichtfeld sein 3.) Befüllen einer Auswahlliste in Abhängigkeit eines anderen Feldes Das dritte Beispiel soll uns die Auswahlliste eines Feldes in Abhängigkeit eines anderen Feldes befüllen. In unserem Beispiel soll das Feld Team in Abhängigkeit der Area befüllt werden. Dazu definieren wir für das Feld Team das wir zuvor hinzugefügt haben 2 When-Regeln An dieser Stelle verwenden wir für die Regel nicht das Feld AreaPath da hierarchische Felder in Regeln nicht richtig unterstützt werden. Diese produzieren dann beim Import des WIT den Fehler "TF26204: The account you entered is not recognized". Der Umweg über die AreaID umgeht diese Problem. Dann stellen wir einfach die AllowedValues für die beiden Fälle ein. Man sieht also, dass der TFS einiges an Flexibiölität zu beieten hat. Es lohnt sich damit mal etwas zu experimentieren. Generell möchte ich aber vor Überregulierung warnen weil dies in der Praxis meist dazu führt, dass die Anwender behindert werden und somit die Akzeptanz des Tools sinkt.
Im Team Foundation Server lassen sich die Work Items sehr einfach anpassen, neue Work Item Types lassen sich erzeugen und damit ein individuelles Process Template erzeugen. Das ganze geht sehr einfach und intuitive wenn mann den Process Template Editor aus den Team Foundation Server Power Tools verwendet (http://visualstudiogallery.msdn.microsoft.com/en-us/3e8c9b68-6e39-4577-b9b7-78489b5cb1da) Wer mal auf den Geschmack gekommen ist, das Process Template im TFS anzupassen, wird durch ausprobieren und rumspielen schnell vor der Frage stehen, wie kann ich nun in einem bestehenden Projekt einen Work Item Type wieder löschen den ich nicht mehr brauche? Hier hilft das Kommandozeilentool witadmin weiter das sich dirckt über die Visual Studio Eingabeaufforderung ausführen lässt. witadmin destroywitd /collection:http://<Servername>:8080/tfs/<Team Project Collection> /p:<Team Projekt Name> /n:<Name des Work Item Types> löscht den angegebenen Work Item Type. Vorsicht, mit diesem Kommando werden aber auch alle Work Items gelöscht, die diesen Typ verwenden, diese können ja vom System nach löschen der WITD nicht mehr verwaltet werden. Wenn man also den WIT bestehender Work Items verändern möchte, dann sollte man diesen umbenennen und anschließend so anpassen dass er den neuen Anforderungen entspricht. Zum Umbenennen eines WIT hilft ebenfalls witadmin witadmin renamewitd /collection:http://<Servername>:8080/tfs/<Team Project Collection> /p:<Team Projekt Name> /n:<Alter Name des Work Item Types> /new:<Neuer Name des Work Item Types>
Bei der weltweiten Usergroup Team System User Group Virtual Edition hat sich in den letzten Tagen einiges geändert, z.B. der Name. Wie das Produkt das im Zentrum unserer Aktivitäten steht, wurde die Gruppe in Visual Stuido ALM User Group umbenannt. Gleichzeitig haben wir eine neue Website online geschaltet. Sie finden uns jetzt unter http://www.vsalmug.com/default.aspx In diesem Zuge werden wir zukünftig die Benachrichtigungen für unsere Meetings nicht mehr per E-Mail zustellen, sondern sie können sich Neuigkeiten unseren Blog mit den Ankündigungen per RSS abrufen (http://www.vsalmug.com/CMSPages/BlogRss.aspx?aliaspath=/Meetings/Announcements). Zusätzlich ahben wir auf LinkedIn eine Gruppe eingerichtet über die sich die Mitglieder besser untereinander vernetzen können: http://www.linkedin.com/groups?home=&gid=2860483&trk=anet_ug_hm Abschließend möchte ich auf unseren nächsten Vortrag noch hinweisen. Am Donnerstag, 06.05.2010 ab 19:00 wird Martin Woodward vorstellen wie die Integration mit nicht Microsoft-Plattformen über den Team Explorer Everywhere (vormals Teamprise) gelingt.  Team Explorer Everywhere 2010 Meeting Date: Thursday, May 6th, 2010 Time: 10:00AM PT (UTC-0700) [Add to Calendar] [Join Meeting] Did you know that Team Foundation Server can be used for software development by your entire organization - not just the team using Microsoft platforms and technologies? In this session Martin Woodward will show you how you can get your Java, Mac, Linux, and Eclipse developers on board using Team Explorer Everywhere 2010. This session shows you how you can standardize on Team Foundation Server for the Application Lifecycle Management of your entire enterprise. See how to manage work items, version control, and build automation across technology and platform boundaries in your company and understand the features and functionality available to the people in your organization. Speaker: Martin Woodward Martin Woodward is the Program Manager for the Microsoft Visual Studio Team Foundation Server Cross-Platform Tools Team and co-author of the book "Professional Application Lifecycle Management with Visual Studio 2010". Before joining Microsoft, Martin was voted Team System MVP of the Year and has spoken about Team Foundation Server at events internationally. Not only does Martin bring a unique insight into the inner workings of the product he has experience from over a half-decade of real world use at companies big and small that he is always happy to share. When not working or speaking, Martin can be found at his blog http://www.woodwardweb.com.
So langsam reift bei den letzten Source Safe Moikanern die Erkenntniss, dass es nun langsam Zeit wird sich nach einer anderen Quellcodeverwaltung umzusehen und eigentlich liegt da inzwischen nichts näher als der Team Foundation Server 2010 der nicht nur eine erstklassige Versionsverwaltung mit bringt sondern der acuh eine Vielzahl weiterer ALM-Funktionen beinhaltet und vor allem inzwischen in der MSDN Subscription kostenloas enthalten ist. Wer wissen will, wie er schnell und einfach von Source Safe auf TFS migriert, findet alle notwendigen Infos hier : http://msdn.microsoft.com/en-us/library/ms253060.aspx
In der TFS Adminconsole oder im TFS Configuration Wizard können die Reporting Services für den TFS konfiguriert werden.  Man gibt hier den Server und ggf. die Instanz der Reporting Services an und klickt auf “Populate URLs”, dann werden die entsprechenden URLs automatisch ausgefüllt – normalerweise zumindest. Ich hatte die Situation, dass der User mit dem ich den TFS installiert habe auf dem Server auf dem die Reporting Services liefen kein Administrator war. Normalerweise ist das der einfachste Weg, den TFS Account auf dem Reporting Server als lokalen Administrator einzutragen, das ist aber nicht in allen Fällen erwünscht. Dann bekommt man die Fehlermeldung TF255050: A connection cannot be made to the Report Server WMI provider. Verify the following: 1. You have entered the correct name for the server, including the instance name. 2. The Windows Management Instrumentation service is running on vs2010rcdemo. 3. The service is not blocked by Windows Firewall. 4. You have the required permissions to connect. Details: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) Eine damit verwandte Fehlermeldung ist TF255186: The following SQL Server Reporting Services Instance could not be found: MSSQLSERVER. The server name is: vs2010rcdemo. In beiden Fälle fehlen dem User WMI-Berechtigungen auf dem Reporting Server. Im ersten Fall der Remote-Zugriff auf die WMI generell, im zweiten Fall auf den Remote-Zugriff für die Reporting Services in der WMI. Um die gewünschte Operation ausführen zu können muss dem User zunächst Remote-Zugriff auf WMI gegeben werden: - Auf dem Reporting Server dcomcnfg.exe starten
- Im linken Bereich Console Root\Component Services\Computers\My Computer öffnen
- Aus dem Kontextmenü von “My Computer” den Eintrag “Properties” öffnen
- Im Bereich “Launch and Activation Permissions” auf “Edit Limits” klicken
- Den Benutzer mit “Add hinzufügen und ihm “Remote Launch” und “Remote Activation” vergeben
Anschließend kann der Remote-Zugriff per WMI auf die Reporting Services konfiguriert werden. - Auf dem Reporting Server wmimgmt.msc starten
- Im linken Bereich auf WMI Control (Local) aus dem Kontext-Menü “Properties” auswählen
- Auf den Reiter Security wechseln und im Baum Root\Microsoft\SqlServer\ReportServer auswählen
- Auf den Button “Security” klicken und den gewünschten benutzer mit “Add” einfügen
- Dem Benutzer “Enable Account” und “Remote Enable” als Rechte vergeben
- Auf “Advanced” clicken, den Benutzer auswählen und dann auf “Edit” klicken
- Bei “Apply to” “This namespace and subnamespaces” wählen
Mit diesen Einstellungen sollte nun das “Populate URLs” in der TFS Administration Console funktionieren.
Beim Deployment einer Environment auf meinen Host bekam ich den Fehler TF259115:  Speicher war eigentlich genug frei auf meinem Host und so war ich zunächst erstaunt, warum er das nicht deployen wollte. Des Rätsels Lösung liegt darin, dass die Placement Policy standardmäßig auf “Conservative” eingestellt ist. Das bedeutet, dass der Host beim Deployment den Speicherbedarf aller VMs auf dem Host ermittelt, unabhängig davon ob diese gestartet sind oder nicht. Im Betrieb könnten ja dann alle gleichzeitig gestartet werden was dann zu Problemen führt. D.h. im Idealfall hat man immer soviel Ressourcen, dass alle Environments die deployed sind gleichzeitig laufen können, momentan nicht benötigte Environments werden in der Library abgelegt. Da ich aber auf meinem Demo-Notebook nicht soviel Speicher habe und dabei nie alle Environments gleichzeitig laufen sollen, wollte ich diese Limitierung umgehen. Dies kann man erreichen, indem man die Placement Policy auf Aggresive stellt. Dies erreicht man am besten durch einen TFSConfig-Aufruf: TfsConfig Lab /hostgroup /CollectionName:labcollection /Edit /Name:"All Hosts" /LabEnvironmentPlacementPolicy:Aggressive Logging sent to file C:\ProgramData\Microsoft\Team Foundation\Server Configuration\Logs\CFG_SET_URL_0413_225508.log Command: lab TfsConfig - Team Foundation Server Configuration Tool Copyright (c) Microsoft Corporation. All rights reserved. Are you sure you want to update the settings for this host group ? (Yes/No) y The requested changes were successfully applied. Die TFSConfig findet befindet sich im Pfad C:\Program Files\Microsoft Team Foundation Server 2010\Tools Weitere Infos unter http://msdn.microsoft.com/en-us/library/dd547199(VS.100).aspx
Team Foundation Server 2010 bietet nun eine verbesserte Integration mit SharePoint. Für die einzelnen Team-Projekte wird die Verbindung zu einer SharePoint Site typischerweise beim Anlegen des Projektes einrichten, alternativ kann man das auch im Nachhinein konfigurieren. Dazu einfach im TeamExplorer auf dem Team Projekt rechte Maustaste und dann unter “Team Project Setting” “Portal Settings” auswählen. Hier wählt man dann unter “Configure URL” eine der konfigurierten Web Applications aus. Bekommt mann beim Bestätigen des Fensters folgen Meldung, dann hat der aktuelle Benutzer nicht ausreichen Berechtigungen auf die Site / SiteCollection: Server was unable to process request. ---> Failed to activate feature 'TeamFoundationWeb' (ID: 310284e3-35d9-4b5d-99b5-c42147379877) at scope 'http://sarmoss02/sites/TFS2008/BI_KaBIS'. Diese Berechtigungen müssen im SharePoint eingetragen werden.
Mit dem TFS 2010 ist es nun möglich, denn Application-Tier über einen NLB-Cluster zu betreiben. Damit kann man Ausfallsicherheit und Load-Balancing für den App-Tier erreichen. Mit einem SQL-Cluster als Data-Tier skaliert der TFS nun sehr schön, sowohl in Punkte Performance als auch in Bezug auf die Ausfallsicherheit. Nun liegt es natürlich nahe, die Reporting Services ebenfalls über den NLB zu betreiben, was an sich auch kein Problem ist. Man muss nur ein paar Einstellungen vornehmen. So hats bei mir funktioniert: 1.) Das Scale-out Deployment für die Reporting-Services auf beiden Servern aktivieren (setzt SSRS Enterprise voraus) 2.) Die Web Service URL auf die IP-Adresse des NLB einstellen 3.) In der TFS Admin Console die Reporting Services über den NLB registrieren. Das hat bei mir nur über die IP-Adresse funktioniert, nicht über den Namen. Da muss ich bei Gelegenheit mal danach schauen. 4.) In der Datei C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer\rsreportserver.config unter <Service> folgendes Tag einfügen: <Hostname>sartfsnlb01</Hostname> 5.) In der Web.config unter C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer\ und unter C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportManager\ im Abschnitt <system.web> folgenden Tag einfügen: <machineKey validationKey="627BF72BB33AA8D28CA2C3E80920BA4DF0B726F97EEFBB0F4818350D63E6AFA380811F13ED1F086E386284654DB3DAF676707464EEB73EBF79858F477D8E4F5C" decryptionKey="F40B6E5A02B29A181D2D213B5ED8F50B73CFCFD0CC56E137" validation="SHA1" /> Achtung die Parameterwerte dürfen nuicht umgebrochen werden. Einen eigenen Key kann man sich einfach unter http://aspnetresources.com/tools/keycreator.aspx generieren lassen. 6.) Reporting Srevices neu starten. 7.) Nun werden bei einem Ausfall eines App-Tiers alle Reporting-Anfragen über den anderen App-Tier abgewickelt, der Anwender merkt davon nichts außer dass es beim ersten Zugriff nach dem Ausfall ein wenig länger dauert.
Mit Team Foundation Server 2010 wird der TFS nun auch für kleinere Teams noch interessanter als bisher. Es gibt eine Reihe von Vorteilen gegenüber der aktuellen Version: - Preis
Es gibt im Moment noch keine abschließenden Informationen über das Pricing, aber voraussichtlich wird der Preis zukünftig wohl kaum noch ein Argument sien, den TFS nicht zu nutzen. - Systemanforderungen
Die Anforderungen an das System sind deutlich geringer als bei TFS 2008. So kann der TFS nun auf einem Domänen-Controller und sogar auf Client-Betriebssystemen installiert werden. Zudem können nun einige Komponenten wie SharePoint und Reporting optional installiert werden. - Installation
Der Installationsvorgang wurde deutlich vereinfacht. Damit kommt Microsoft dem Slogen “ALM for the masses” einen großen Schritt näher. Weitere Details gibt es auf dem Blog von Brian Harry: http://blogs.msdn.com/bharry/archive/2009/10/01/tfs-2010-for-sourcesafe-users.aspx
Mit dem Work Item Type Designer (WIT Designer) können Work Item Type Definitionen einfach und bequem angepasst werden. Der WIT Designer ist Bestandteil der TFS Power Tools. Mit dem WIT Designer kann man auch die Workflows auf den Work Item Types grafisch bearbeiten. Dazu kann man aus der Toolbox einfach neue States und Transistions auf das Workflow-Diagramm ziehen … zumindest wenn die Toolbox Elemente enthält. Sollte die Toolbox einmal leer sein, dann gibt es eine nicht ganz elegante aber wirksame Methode, man löscht einfach alle toolbox*.tdb Dateien und zwar au dem Ordner C:\Users\<USERNAME>\AppData\Local\Microsoft\VisualStudio\8.0. Danach erscheinen die Elemente ganz normal.
Beim Installieren eines Team Foundation Server 2010 Beta 1 habe ich einen Fehler TF254038 bekommen. Beim Anlegen einer SharePoint Web Application auf dem TFS hat der Wizard behauptet ich hätte die SharePoint Extensions nicht installiert. Ich habe für den TFS und den SharePoint Server zwei getrennte Maschinen. Das Problem lag letztendlich darin, dass die Firewall auf der SharePoint Maschine den Zugriff auf die SharePoint Central Administration (Port 17012) geblockt hat. Nachdem ich den freigegeben habe, lief die Installation problemlos durch.
 Im Juni werden wir beim EMEA-Meeting der Team System User Group Virtual Edition Ed Blankenship als Sprecher haben. Ed ist MVP für Team System und Release Manager bei Infragistics, dem führenden Hersteller von UI-Komponenten. Er wird in seinem Vortrag über die Erfahrungen bei der Einführung von VSTS bei Infragistics berichten. Dabei werden die verschiedenen Bereiche wie Versionsverwaltung, Build Management, Work Item tracking, das Management globaler Teams, automatisiertes Testen und vieles mehr aus einer Anwendersicht beleuchtet. Ein wirklich sehenswerter Erfahrungsbericht aus der Praxis. Weitere Informationen unter www.tsug-ve.com.
Eigentlich versuche ich meinen Blog weitgehend werbefrei zu halten. Diesesmal möchte ich aber doch kurz auf die Seite www.alm-tools.de hinweisen, die mein Arbeitgeber artiso betreibt. Hier haben wir vor Kurzem eine Reihe neuer Tools rund um das Thema TFS und ALM (Application Lifecycle Management) veröffentlich, zum Teil kostenlos. Zudem gibt es hier inzwischen auch ein kleines Archiv mit Videos rund um das Thema das wir kontinuierlich ausbauen.
Mein Kollege Mark Bulmahn hat in einem Screencast ein Problem näher untersucht, das beim Merge in der TFS Source Countrol auftreten kann. Dabei geht es vor allem darum, dass Verschiebe-Operationen im Visual Studio Solution Explorer in der Source Control nicht als Verschiebe-Operation sondern als Delete und Add ausgeführt wird. Das führt dann zu Problemen bei einem späteren Merge.In dem Screencast sieht man, wie dieses Problem vermieden und auch wieder repariert werden kann.
Wenn schon mit Pre-Releases arbeiten, dann richtig habe ich mir gedacht und versucht den Team Foundation Server 2010 Beta 1 auf dem Windows 2008 Server R2 RC zu installieren. Nach einer kurzen Recherche im Internet bin ich auf diesen Blog-Post gestoßen. Mit den Informationen dort ist es mir tatsächlich gelungen, den TFS 2010 Beta1 und VSTS 2010 Beta1 auf dem Win2008R2 RC zu installieren. Damit komme ich nun auch auf meiner Demo-Maschine in den Genuss der Desctop-Experience von Win2008R2 
 Im Mai haben wir bei der TSUG-VE Ian Ceicis als Sprecher zum Thema Projekt Management mit TFS 2010. Er wird in seinem Vortrag die Neuerungen rund um das Workitem-Tracking in TFS 2010 vorstellen. Want to get the skinny on the latest enhancements coming in TFS 2010, come see demos of the updated MSF Agile template, the new Agile workbooks, the new Excel reports, and the Microsoft Project client improvements such as Hierarchical work items, rollups, and project summary tasks. This session will be packed with demos from Beta 1 and will be a great way to start getting familiar with the new tools coming in 2010. Bring your hardest questions, join the conversation, and walk away with the ability to see how your next project will run smoothly if you start using TFS 2010. This month's meeting is being presented by Ian Ceicys. Ian is a member of Microsoft's Global ALM Practice and an active member of the VSTS Rangers. Das Treffen findet am Donnerstag, 21.05.2009 um 19:00 statt. Weitere Infos unter http://www.tsug-ve.com
&
Mit der Version 3 des Design-Tools für WPF und SilverLight, Expression Blend bekommt nun endlich die Unterstützung für den Team Foundation Server um die Source-Dateien in der Versionsverwaltung abzulegen. Hierzu muss ein entsprechendes Hotfix installiert werden. Dann hat man im Project-View zusätzliche Icons die den Auscheck-Status der Dateien anzeigt und im Kontext-Menü befinden sich entsprechende Kommandos für die Versionsverwaltung.
Hinweis: Damit das beim ersten Start auch wirklich funktioniert, muss man im Visual Studio den Team Explorer wenigstens einmal gestartet haben und dort den Server registrieren. Sonst bekommt man die Meldung "Unable to determine workspace" im Expression Blend.
Beim Checkin ist auch die sehr nützliche Funktion zur Verknüpfung von Workitems beim Checkin verfügbar.
Damit kann Expression Blend nun endlich in den Entwicklungs-Prozess von Software-Anwendungen integriert werden und steht nicht nur als separates Design-Tool bereit.
Auf einer neuen TFS-Instanz hatte ich eben ein seltsames Phänomen. Ich konnte das erste Team-Projekt problemlos anlegen. Dazu verwendete ich einen Team_Explorer mit einer Visual Studio Shell Installation auf dem Server. Als ich allerdings das zweite Projekt anlegen wollte, kam eine Fehlermeldung, dass mir die Berechtigungen auf den Reporting Services fehlen. Seltsam nur, dass es beim ersten Projekt geklappt hat und dazwischen nichts geändert wurde. Mit einem kleinen Trick konnte ich dann doch ein zweites Projekt anlegen, nämlich indem ich alle Projekte aus dem Team-Explorer entfernt habe. Dann konnte ich wieder genau ein neues anlegen. Die eigentliche Lösung für das Problem brachte aber die Installation des SP1 auf dem Server. Dabei ist zu beachten, dass das SP1 für den Team-Explorer nicht Bestandteil des Team Foundation Server SP1 ist, sondern des Visual Studio SP1. Also das Visual Studio SP1 installiert und danach lief es wunderbar.
 Grade erst wurden die EMEA-Meetings der Team System User Group Virtual Edition ins Leben gerufen, schon können wir mit einem Highlight aufwarten. Für unser April-Meeting konnten wir Brian Harry als Sprecher gewinnen. Brian wird über die Internal Adoption von VSTS sprechen. Brian ist Technical Fellow und Manager der Product Unit für den team Foundation Server. Also gleich als Mitglied registrieren und am 16. April dabei sein! Weitere Informationen zum Meeting gibt’s unter www.tsug-ve.com.
Der Tatsache, dass Testen eine wichtige Bedeutung in der Software-Entwicklung hat, trägt Microsoft ja bereits seit einiger Zeit Rechnung indem eine spezielle Edition des Visual Studio für Tester generiert wurde. Diese Edition besitzt umfangreiche Funktionenzu verschiedenen Test-Methoden. Das Ranger-Team hat nun einen Quick Reference Guide veröffentlicht der auf 83 Seiten diese Funktionen beschreibt und verschiedene Best Practices anbietet. Hierbei sind die Erfahrungen eingeflossen, die Service Labs, ein großes Test-Center, bei der Adaption von Team Test gemacht hat. Das Dokument enthält viele wertvolle Hinweise, wie VSTT in der Praxis eingesetzt und individuell erweitert werden kann. Definitiv lesenswert für jeden, der etwas mehr über dieses Toolset erfahren möchte. Download VSTT 2008 Quick Reference Guide
Die Integration von Visual Studio 2005 / 2008 mit dem TFS ist ideal gelöst. Jedoch gibt es auch noch andere Entwicklungs-Plattformen die keine direkte Integration mit dem Team-Explorer erlauben wie z.B. ältere Visual Studio Versionen und leider auch immer noch das SQl Server Management Studio. Diese IDEs überstützen doch recht häufig den sog. MSSCCI-Standard und es gibt bereits seit längerer Zeit einen entsprechenden MSSCCI-Provider für den TFS 2008. Dieser hatte bisher immer noch den nachteil, dass er reine Sourcecontrol Features unterstützt hat und z.B. das Verknüpfen von Workitems beim Checkin nicht möglich war. In der neuesten Version ist dies nun auch möglich und somit ist auch bei IDEs die den Team Explorer nicht integrieren ein komfortables Arbeiten mit dem TFS möglich. Ich habe hier mal ein Beispiel für das SSMS 2008. Zunächst muss der TFS MSSCCI-Provider unter Optionen eingestellt werden. Legt man nun ein Datenbankprojekt an, dann kann man das in gewohnter Art und Weise mit der Source Control verbinden und man erhält Fenster “Pending Checkins”. Führt man hier nun den Checkin aus, kommt der aus dem Team-Explorer bekannte Dialog Hier können nun z.B. Checkin-Kommentare angegeben oder Workitems verknüpft werden. Sogar die Checkin-Plicies funktionieren hier wie gewohnt. Damit ist ein komfortables und problemloses Arbeiten auch mit solchen Umgebungen möglich, die den Team-Explorer nicht direkt integrieren. Und damit wieder ein Grund mehr, nun endlich auf den TFS zu setzen und SourceSafe und Konsorten endlich in Rente zu schicken.
 Am 16.03.09 geht ein neuer Webcast von mir online mit dem Thema "Team Build mit Custom Build Tasks erweitern". Ich möchte hier schon mal die entsprechenden Infos veröffentlichen. In TeamBuild lassen sich eigene Build-Task integrieren. Diese können sehr einfach erstellt werden. Hierzu wird eine Klasse erstellt und diese von Task abgeleitet. Im folgenden Beispiel wird ein Build-Task erstellt, der im Rahmen des Builds die Version der Anwendung setzt. Und zwar soll hier die Build-Nummer in der Versionsnummer der Assembly abgebildet werden. Dies bietet Vorteile, wenn zu einer bestimmten Anwendungsversion der entsprechende Build identifiziert werden soll. 1: using System; 2: using System.Collections.Generic; 3: using System.Text; 4: using Microsoft.Build.Utilities; 5: using Microsoft.Build.Framework; 6: 7: namespace Artiso.BuildTasks 8: { 9: /// <summary> 10: /// Creates a AssemblyVersion out of a BuildNumber 11: /// </summary> 12: /// <remarks> 13: /// AssemblyVersion.Minjor and AssemblyVersion.Minor will be defined fiexed in 14: /// the Build-Script. If the BuildNumber is Dev_Versioning_20090305.4 we use 15: /// two digit year and month for AssemblyBuildNumber and day and 3 digit BuildRevision 16: /// for AssemblyRevision. BuildRevisio 17: /// </remarks> 18: /// <example> 19: /// Dev_Versioning_20090305.4 => xx.yy.0903.05004 20: /// </example> 21: public class ExtractRevision : Task 22: { 23: #region [rgn] Fields(3) 24: private string buildRevision; 25: private string buildVersion; 26: private string buildNumber; 27: #endregion 28: 29: #region [rgn] Properties(3) 30: /// <summary> 31: /// Input Build Number 32: /// </summary> 33: [Required] 34: public string BuildNumber 35: { 36: set { buildNumber = value; } 37: } 38: 39: /// <summary> 40: /// Returns the sortened date of the build 41: /// </summary> 42: [Output] 43: public string BuildVersion 44: { 45: get { return buildVersion; } 46: } 47: 48: /// <summary> 49: /// Returns the Build Revision (number of build at this day 50: /// </summary> 51: [Output] 52: public string BuildRevision 53: { 54: get { return buildRevision; } 55: } 56: #endregion 57: 58: #region [rgn] Methods(1) 59: public override bool Execute() 60: { 61: buildVersion = "0"; 62: buildRevision = "0"; 63: 64: if (buildNumber != null && buildNumber.Contains(".")) 65: { 66: string[] buildNumberParts = buildNumber.Substring(buildNumber.LastIndexOf('_')+1).Split('.'); 67: 68: // Dev_Versioning_20090305.4 -> 0903.02005 69: // use year (2 digits) and mont for buildversion 70: buildVersion = buildNumberParts[0].Substring(2, 4); 71: 72: // use day and number of build in this day for build revision 73: buildRevision = buildNumberParts[0].Substring(6) + buildNumberParts[1].PadLeft(3, '0'); 74: } 75: return true; 76: } 77: #endregion 78: } 79: }
Das Property BuildNumber wird als Input-Parameter verwendet und mit dem Attribut [Required] versehen. Darüber kann die BuildNumber in unseren Task übergeben werden. Durch das Attribut [Output] werden die beiden Properties BuildVersion und BuildRevision als Rückgabewerte definiert. Beim Ausführen des Builds wird die Methode Execute aufgerufen. Hier werden nun aus der Build-Number die entsprechenden Informationen extrahiert und diese dann in BuildVersion und BuildRevision zurückgeschrieben. Dies ist natürlich nur ein einfaches Beispiel, aber mit diesen Grundlagen können nun beliebige Build-Tasks definiert werden. Im nächsten Schritt schauen wir uns an, wie wir diesen Custom Build Task nun in unseren Build-Prozess einbinden. Hierzu kopieren wir zunächst die Assembly in einen entsprechenden Ordner. Hier bietet sich an unter c:\Program Files\MSBuild einen entsprechenden Ordner anzulegen und dort die Assemblies abzulegen.
Nun muss das Build-Script entsprechend angepasst werden. Diese liegt in der Quellcode-Verwaltung und muss zum Bearbeiten zuerst aus- und danach wieder eingechecked werden. Um diesen Vorgang zu vereinfachen empfehle ich die TFS Sidekicks (http://www.attrice.info/downloads/index.htm) die direkt im Kontextmenü des TeamExplorers entsprechende Kommandos einfügt. Das nun ausgecheckte PROJ-File kann nun bearbeitet werden.
1: <?xml version="1.0" encoding="utf-8"?> 2: <!-- DO NOT EDIT the project element - the ToolsVersion specified here does not prevent the solutions 3: and projects in the SolutionToBuild item group from targeting other versions of the .NET framework. 4: --> 5: <Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5"> 6: 7: <!-- Do not edit this --> 8: <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" /> 9: <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"/> 10: 11: <UsingTask AssemblyFile="$(MSBuildExtensionsPath)\ArtisoBuildTasks\ArtisoBuildTasks.dll" 12: TaskName="ExtractRevision"/> 13: 14: <PropertyGroup> 15: <!-- Assembly version properties. Adjust here Major and Minor Version--> 16: <AssemblyMajorVersion>1</AssemblyMajorVersion> 17: <AssemblyMinorVersion>3</AssemblyMinorVersion> 18: <AssemblyBuildNumber>1</AssemblyBuildNumber> 19: <AssemblyRevision>1</AssemblyRevision> 20: </PropertyGroup> 21: ...
In Zeile 11 wird unser BuildTask entsprechend registriert. In Zeile 9 werden noch weitere Build-Tasks registriert. Hier gereicht es uns zum Vorteil, dass Team-Build auf MSBuild basiert. D.h. es können entsprechende Tasks für MSBuild problemlos integriert werden. Diese gibt es in großer Zahl für sehr viele Anwendungsbereiche zum großen Teil frei Verfügbar zum Download. Wir verwenden hier die MSBuild Community Tasks ( http://msbuildtasks.tigris.org/). Wir werden aus diesem Paket Aktionen verwenden.
In den Zeilen 14 bis 20 wird eine sog. PropertyGroup angelegt. Darin werden einzelne Properties definiert und mit Default-Werten vorbelegt. Diese Properties lassen sich mit Variablen innerhalb eines Software-Codes vergleichen. Die AssemblyMajorVersion und AssemblyMinorVersion werden hier festgelegt. AssemblyBuildNumber und AssemblyRevision werden wir im weiteren Verlauf überschreiben.
Am Ende des Scripts direkt vor dem schließenden </Project>-Tag wird nun ein Target-Block eingefügt.
1: ... 2: <Target Name="AfterGet"> 3: <ItemGroup> 4: <AssemblyInfoFiles Include="$(SolutionRoot)\**\assemblyinfo.cs" /> 5: </ItemGroup> 6: 7: <Message Text="Get Revision Number from BuildNumber "$(BuildNumber)"." /> 8: <ExtractRevision BuildNumber="$(BuildNumber)"> 9: <Output TaskParameter="BuildRevision" 10: PropertyName="AssemblyRevision" /> 11: <Output TaskParameter="BuildVersion" 12: PropertyName="AssemblyBuildNumber" /> 13: </ExtractRevision> 14: 15: <!-- Update all the assembly info files with generated version info --> 16: <Message Text="Modifying AssemblyInfo files under "$(SolutionRoot)"." /> 17: <Attrib Files="@(AssemblyInfoFiles)" Normal="true" /> 18: <FileUpdate Files="@(AssemblyInfoFiles)" 19: Regex="AssemblyVersion\(".*"\)\]" 20: ReplacementText="AssemblyVersion("$(AssemblyMajorVersion).$(AssemblyMinorVersion).$(AssemblyBuildNumber).$(AssemblyRevision)")]" /> 21: <FileUpdate Files="@(AssemblyInfoFiles)" 22: Regex="AssemblyFileVersion\(".*"\)\]" 23: ReplacementText="AssemblyFileVersion("$(AssemblyMajorVersion).$(AssemblyMinorVersion).$(AssemblyBuildNumber).$(AssemblyRevision)")]" /> 24: <Message Text="AssemblyInfo files updated to version "$(AssemblyMajorVersion).$(AssemblyMinorVersion).$(AssemblyBuildNumber).$(AssemblyRevision)"" /> 25: </Target> 26: 27: </Project>
Über den Namen des Target-Blocks mit "AfterGet" wird festgelegt, dass dieser Block ausgeführt wird, nachdem der Build-Prozess die Quelldateien aus der Versionsverwaltung geholt hat. Genau zu diesem Zeitpunkt wollen wir unsere Versionierung anpassen. In den Zeilen 3 bis 5 erstellen wir eine ItemGroup die alle assemblyinfo.cs Dateien unserer Solution enthält. In diesen Dateien wollen wir die Version anpassen. In Zeile 7 wird eine Meldung in das Build-Log geschrieben. Dies ist hilfreich, um Fehler im Ablauf des Scriptes besser einordnen zu können.
In den Zeilen 8 bis 13 wird nun unser Build-Task aufgerufen. Wir übergeben die Buildnummer $(BuildNumber) in den Parameter BuildNumber und lesen die Output-Parameter aus und schreiben diese in AssemblyRevision bzw. AssemblyBuildNumber (die Properties die wir weiter oben definiert hatten). In Zeile 17 heben wir den Schreibschutz der AssemblyInfo-Dateien auf und in den folgenden Zeilen wird mit Hilfe eines Ersetzen-Vorgangs die Version in den AssemblyInfo-Dateien ersetzt. Für diese Aktionen nutzen wir die Community Build Tasks.
Damit können wir nun die Version unserer Anwendung bei jedem Build entsprechend setzen.
In einem nächsten Schritt wollen wir den Build-Task nun noch erweitern um das Build-Result in einer ZIP-Datei zu verpacken und diese anschließend per Mail zu versenden. Auch hierbei greifen wir auf die MSBuild Community Tasks zurück. Das entsprechende Target-Tag fügen wir einfach nach dem zuvor definierten ein. Als Name geben wir "AfterCompile" an so dass diese Aktionen nach dem Kompilieren ausgeführt werden. 1: <Target Name="AfterCompile">
2: <CreateItem Include="..\Binaries\Release\**\*.*" Exclude="..\Binaries\Release\**\*.pdb;..\Binaries\Release\**\*codeanalysis*"> 3: <Output ItemName="ZipFiles" TaskParameter="Include"/> 4: </CreateItem> 5: 6: <Message Text="Zipping Buildresult to \\tfs\deploy\BuildDemo\BuildDemo_$(AssemblyMajorVersion).$(AssemblyMinorVersion).$(AssemblyBuildNumber).$(AssemblyRevision).zip" /> 7: 8: <Zip ZipFileName="\\tfs\deploy\BuildDemo\BuildDemo_$(AssemblyMajorVersion).$(AssemblyMinorVersion).$(AssemblyBuildNumber).$(AssemblyRevision).zip" 9: Files="@(ZipFiles)" 10: WorkingDirectory="..\Binaries\Release\"/> 11: 12: <Mail SmtpServer="tfs" 13: To="tschissler@tfs" 14: From="build@tfs" 15: Subject="BuildDemo v$(AssemblyMajorVersion).$(AssemblyMinorVersion).$(AssemblyBuildNumber).$(AssemblyRevision) released" 16: Body="A new version of the BuildDemo was released. Please find the newest files attached to this mail. You can also download them from the download folder." 17: Attachments="\\tfs\deploy\BuildDemo\BuildDemo_$(AssemblyMajorVersion).$(AssemblyMinorVersion).$(AssemblyBuildNumber).$(AssemblyRevision).zip"/> 18: </Target>
Hier sammeln zunächst alle Dateien aus dem Build-Drop-Verzeichnis exklusive der PDB- und Codeanalyse-Dateien In Zeilen 8-10 werden diese Dateien in ein ZIP-File verpackt dem wir im datei-Name die Version mitgeben. Anschließend versenden wir eine e-Mail der wir dieses ZIP-File als Attachment anhängen.
Als zweite Variante wollen wir im Rahmen des Builds ein Click-Once Paket erstellen. Die Herausforderung bei der Erstellung des ClickOnce-Paketes ist dass dort die Deployment-Url hinterlegt werden muss. Vor allem wenn verschiedene Pakete für unterschiedliche Kunden erstellt werden sollen, ist dies nur durch eine Automatisierung im Rahmen des Builds sinnvoll handelbar. Hierzu ersetzen wir den AfterCompile-Target durch folgendes Script:
1: <Target Name="AfterCompile"> 2: <!-- Publish using ClickOnce --> 3: <Message Text="modify Publish directory for $(SolutionRoot)" /> 4: <!-- Update directory where to publish the project --> 5: <ItemGroup> 6: <ProjectFiles Include="$(SolutionRoot)\Source\Dev\BuildDemo\BuildDemo.csproj" /> 7: </ItemGroup> 8: <PropertyGroup> 9: <PublishDir>\\tfs\Deploy\BuildDemo\ClickOnce\</PublishDir> 10: <InstallUrl>\\tfs\Deploy\BuildDemo\ClickOnce\</InstallUrl> 11: </PropertyGroup> 12: <Attrib Files="@(ProjectFiles)" Normal="true" /> 13: <FileUpdate Files="@(ProjectFiles)" 14: Regex="<PublishUrl>.*</PublishUrl>" 15: ReplacementText="<PublishUrl>$(PublishDir)</PublishUrl>" /> 16: <FileUpdate Files="@(ProjectFiles)" 17: Regex="<InstallUrl>.*</InstallUrl>" 18: ReplacementText="<InstallUrl>$(InstallURL)</InstallUrl>" /> 19: 20: <MSBuild Projects="@(ProjectFiles)" 21: Properties="PublishDir=$(PublishDir);ApplicationVersion=$(AssemblyMajorVersion).$(AssemblyMinorVersion).$(AssemblyBuildNumber).$(AssemblyRevision)" 22: Targets="Publish" /> 23: 24: </Target>
In den Zeilen 5 bis 7 lesen wir das csproj-File der Anwendung in eine ItemGroup. Anschließend definieren wir zwei Properties für PublishDir und InstallUrl. Diese werden dann über eine Ersetzung in die csproj-Datei eingefügt. Anschließend wird ein MSBuild-Task gestartet der das ClickOnce-Paket erstellt und an der angegebenen PublishDir und mit der Versionsnummer veröffentlicht.
Das Ganze wird in dem genannten Webcast Live demonstriert. Über Feedback würde ich mich sehr freuen.
Details zur Veranstaltung: Team Build mit Custom Build Tasks erweitern [1032405249] - Microsoft Deutschland GmbH
Hier hatte ich beschrieben, wie man die Test-Results aus Visual Studio nach Excel übertragen kann. Heute möchte ich ein Tool vorstellen, das es erlaubt, TRX-Files nach HTML zu konvertieren. Zunächst speichert man das Test-Result in ein TRX-File. Dies geht über den Button "Export Test Run Results". Anschließend kann man mit dem Tool trx2html das HTML-File erstellen. trx2html ist ein Open-Source Projekt von CodePlex. Es wird als Commandozeilen-Tool ausgeführt und als Parameter wird einfach das TRX-File angegeben. Als Ergebnis wird nun ein HTML-File erstellt das die Testergebnis entsprechend dokumentiert und auch einige Drill-Down-Funktionen bietet: Durch einen Klick auf das rote Kreis-Icon neben einem der Test kann z.B. ein Stack-Trace eingeblendet werden. trx2html - Home
Die Team System User Grroup - VE ist eine virtuelle Usergroup die zwei mal im Monat ein Treffen hat in deren Rahmen Vorträge rund um das Thema Team System gehalten werden. Die Treffen finden virtuell in Second Life und über Live Meeting statt. Für Europäer ist das jeweils zweite Treffen zeitlich günstig am Samstag Nachmittag. Team System User Group - Virtual Edition
Auf MSDN gibt es einen neuen Bereich zu Team System. Die Seite ist in einer ersten Iteration veröffentlicht und wird nun kontinuierlich mit weiterem Content ergänzt. Hier sind die Inhalte wesentlich übersichtlicher aufbereitet als auf den alten Seiten. Wer also mit Team System arbeitet oder das vorhat, einfach mal vorbeischauen. Feedback zu der Seite ist sehr willkommen und kann hier abgegeben werden. Team System Home auf MSDN
Der Team Foundation Server verwendet in den Versionen bis 2008 eine XML-Datei um den Build-Prozess zu steuern. Diese Datei wird Build Project File genannt und wird in der Versionsverwaltung abgelegt um vom Buildcomputer genutzt werden zu können. Jeder der diese Datei aber schon manuell bearbeitet hat, kennt das umständliche Vorgehen umd die Date erst aus der Quellcode-Verwaltung auszuchecken, und nach dem Bearbeiten wieder einzuchecken. Einfacher geht das mit den TFS Sidekicks, die direkt im Context-Menü des Team-Explorers eine Checkout und Checkin-Funktion für das Project-File anbietet. Darüber hinaus bieten die TFS Sidekicks noch weitere sehr nützliche Funktionen, auf jeden Fall ist das Tool einen näheren Blick wert. Attrice Corporation - Team Foundation Sidekicks
Today I had my second talk on the TechEd in Barcelona. It was about closing tool gaps in development processes and using the TFS API. Thanks to all attendees joined my session. We had some very interesting discussion at the end, and I got a lot of positive feedback like “This was what I was looking for”. For all here comes the promised downloads for the slides and demos. Feel free to use them in either way. And here the link to download WorkitemManager. At www.alm-tools.com you can download the Open version which is free and also the source code. And if you are interested in one of the tools I showed, please just send me an e-Mail to tschissler (at) artiso (.) com.
Mit ein wenig Verspätung wurden die TFS Power Tools October 2008 nun released. Dafür wurden aber noch ein paar wichtige Bugs gefixed. Damit stehen nun die größten Power-Tools zur verfügung, die jemals veröffentlicht wurden. Über die Features habe ich bereits hier gebloggt. ich denke damit werden ein paar wichtige Lücken geschlossen und durch die Explorer Integration wird TFS für weitere Szenarien interessant. Download details: Team Foundation Power Tools
Der artiso Workitem Manager ist ein Tool mit dem sich Workitems hierarchisch organisieren lassen. Diese hierarchische Organisation bietet verschiedene Vorteile. Neben einer besseren Strukturierung und einer erhöhten Übersichtlichkeit vor allem auch eine visuelle Traceability. Damit ist gemein, dass durch die Hierarchie sichtbar wird welche Tests und Implementierungsaufgaben einem Feature zugeordnet sind. Die ist z.B. sehr hilfreich, wenn sich das Feature ändert zu erkennen, welche Workitems auf mögliche Auswirkungen überprüft werden können. Wie hierarchische Workitems in Projekten hilfreich eingesetzt werden, habe ich zusammen mit Christian Binder in diesem MSDN-Webcast erörtert. Leider bringt der TFS in der Version 2008 diese Hierarchie nicht von Haus aus mit. Deshalb hat artiso den Workitem Manager entwickelt. Diesen gibt es nun auch als Open-Version. Die Open-Version ist kostenlos und wird auch als Source-Code bereitgestellt. Wie sich der Workitem Manager Open zur Vollversion unterscheidet kann man der unten stehenden Funktionsmatrix entnehmen. Weiter unten gibt's noch eine Screenshot. Den Donload für das Setup und den Source-Code findet man unter http://www.alm-tools.de. Gerne freue ich mich über euer Feedback zu dem Tool.  
Christian Binder hat eine sehr Übersichtliche Darstellung über die verschiedenen VSTS-Sessions auf dem Technical Summit in Berlin zusammengestellt. Die Map stellt nicht nur die dort live vorgestellten Sessions zusammen, soondern auch bereits bestehende und in Kürze erscheinende Webcasts zu dem Thema. Die Map zeigt auch, dass wir versucht haben unsere Inhalte auf dem Technical Summit so aufeinander abzustimmen, dass sowohl EInsteiger als auch fortgeschrittene Anwender sich ein möglichst komplettes Bild von VSTS machen kann. Die WebCast sind thematisch entsprechend eingeordnet und können als Vorbereitung bzw. zur Vertiefung zu den Live-Sessions genutzt werden. Danke Christian, endlich mal eine übersichtliche Darstellung der verschiendenen Inhalte!
Was bedeutet was? Christian Binder's Weblog : Alle Visual Studio Teamsystem Session auf dem Technical Summit 2008 im Überblick
Die Integration des TFS mit Visual Studio ist eine richtig schöne Sache. Eine Stelle an der die Vorteile dieser Integration schön sichtbar werden ist die Erzeugung einen Workitems direkt aus einem Test-Result heraus. Wenn also z.B. ein Test fehlgeschlagen ist, kann daraus direkt ein Bug-Workitem erzeugt werden. Der Clou dabei ist, dass das Test-Result automatisch auf dem TFS veröffentlicht und als Attachment an das Workitem angehängt wird. Damit hat der Entwickler der den Bug beheben soll Zugriff auf den durchgeführten Test und die Results. Dies funktioniert mit allen Testarten sofern der Entwickler mit seiner Visual Studio Edition die entsprechenden Testarten ausführen kann. Somit kann der Entwickler z.B. bei einem Unit-Test diesen verwenden um den Testcase einfach zu debuggen. Und bei manuellen Tests stellt die Testspezifikation die Beschreibung der Repro-Steps dar. Auf jeden Fall ein Zeitgewinn. Man kann aber beispielsweise damit auch Aufgaben definieren, dass ein bestimmter Test noch mit zusätzlichen Test-Cases angereichert werden soll etc. Dazu geht man einfach mit der rechten Maustaste auf den entsprechenden Eintrag im Testresults-Fenster und wählt aus dem Kontext-Menü den entsprechenden Workitemtyp aus. Wird statt der Liste der Workitems "No Active Team Project" angezeigt, dann gibt es hier eine einfache Lösung, die aber nicht ganz intuitiv ist. 1.) Sicherstellen dass im Team-Explorer das gewünschte Projekt angezeigt wird in dem man das neue Workitem anlegen möchte. 2.) Dieses Team-Projekt aktiv markieren (das Projekt wird fett dargestellt) Nun werden die WorkitemTypen die im ProcessTemplate dieses Projektes definiert sind zur Auswahl angezeigt. Das Projekt selbst muss nicht unbedingt in der Quellcode-Verwaltung des TFS abgelegt sein.
 Seit ein paar Tagen ist ein neuer Web-Cast online in dem ich zusammen mit Christian Binder zusammen erörtere welche Vorteile die hierarchische Organisation von Workitems bietet. Ohne schon zuviel vom Inhalt verraten zu wolle, es geht um Requirementmanagement, Traceability, Impace-Analyse und einiges mehr. Im Webcast wird ein kostenloses Tool vorgestellt mit dem bereits mit TFS 2008 hierarchische Workitems realisiert werden können.
Die nächste Version der TFS Power-Tools werden ein paar richtig coole Features enthalten sein. Z.B. ein neuer Knoten "Team Members" im Team Explorer über den man mit allen Team-Mitglieder kommunizieren kann und worüber man auch z.B. schnell die Pending Changes oder die Shelfsets einzelner Mitglieder findet etc.   Zusätzlich lassen sich damit Komponenten wie z.B. Checkin-Policies oder Workitem-Controls einfach distributieren.  Und von vielen heiß ersehnt, es gibt jetzt eine Windows Explorer Integration zur Quellcode-verwaltung.   Darüber hinaus ist noch der Power-Shell Support Bestandteil der neuen Power-Tools Weitere Details unter Brian Harrys Blog bharry's WebLog : Preview of the next TFS Power Tools release
Ab dem 01.10.2008 werden Besitzer einer Visual Studio 2008 Team System Development Edition auch eine Visual Studio 2008 Team System Database Edition erhalten und umgekehrt. In Visual Studio 2010 werden diese beiden Produkte wohl zu einem verschmolzen. Weitere Informationen unter Visual Studio 2010 and .NET Framework 4.0 Overview im Kapitel "Better Together – Visual Studio Team System Development Edition and Database Edition"
Eine neue User-Group die sich speziell mit Team System beschäftigt wurde vor kurzem gegründet. Dabei handelt es sich um eine virtuelle usergroup, das heißt die Treffen finden in Second Life und über Office Live Meeting statt. Ich bin schon mal gespannt auf das nächste Treffen. Team System User Group - Virtual Edition
In inzwischen über 47 Videos werden in dieser Serie HowTos rund um das Thema Visual Studio Team System präsentiert. Kurz und verständlich bekommt man hier viele BestPractices und Tips. "How Do I?" Videos for Team System
Es ist wohl noch eine weile hin, bis wir Rosario wirklich nutzen dürfen. Brian Harry hat aber schon mal vorab veröffentlicht, welche Systemvoraussetzungen und Abhängigkeiten Rosario haben wird. So werden wohl unter anderem auch SQL 2005 und Office 2003 nicht mehr unterstützt. Dies gibt jetzt bereits die Möglichkeit, rechtzeitig zu planen und sich auf die Anforderungen ggf. entsprechend vorzubereiten. bharry's WebLog : Charting a course for TFS "Rosario"
Der Team Foundation Server bietet die flexible Möglichkeit ProcessTemplates individuell anzupassen. Diese ProcessTemplates enthalten die Definition der Workitemtypes (welche gibt es und welche Felder haben diese), die Workflows (was passiert wenn ich bei einem bestimmten Workitem eine bestimmte Aktion auslöse), und vieles mehr wie Standarddokumente etc. Dieses ProcessTemplate kann man nicht nur im Vorfeld definieren, sondern auch für laufende Projekte noch anpassen, was in der Praxis eine enorme Hilfe ist. Wie's genau geht beschreibt Christian Binder in einem zweiteiligen Blog-Beitrag. Teil 1 Teil 2
Richard Hundhausen hat eine Liste mit Tools und nützlichen Helferlein rund um Team Foundation Server veröffentlicht. Team System Widgets
Über die API mit der man selber Anwendungen für den Team Foundation Server schreiben kann, habe ich ja schon mehrfach berichtet. Nun soll das SDK verbessert werden, was offen gestanden, auch mal Zeit wird. Brian Harry hat ein erstes Sample bereits vorab veröffentlicht, das zeigt, wie man mit der API auf die Version Control zugreift. bharry's WebLog : Working on TFS SDK improvements
Um TFS-Workitems massenhaft zu bearbeiten, z.B. um mehrere Workitems einem neuem Bearbeiter zuzuweisen, gibt es verschiedene Möglichkeiten. Die bekannteste davon ist sicher die Bearbeitung in Excel. Richard Hundhausen beschreibt noch einige weitere in einem Video http://msdn.microsoft.com/en-us/vsts2008/cc563930.aspx
Jeder kenn die Situation. Wenn man einen Fehler oder eine Änderung beschreiben will, tipp man sich einen Wolf. Viel schneller geht es mit einem Screenshot. Wer allerdings, z.B. beim Testen zig Screenshots an Workitems im Team Foundation Server anhängen möchte, der ist auch schnell genervt. Immer der gleiche Prozess. Schreenshot aufnehmen - In das Bildverarbeitungsprogramm wechseln - Screenshot einfügen - Screenshot speichern - Neues Workitem anlegen udn Felder ausfüllen - Attach File aufrufen - Datei mit Screenshot suchen - Fertig! Glücklich derjenige, der den artiso Workitem Manger nutzt. Da geht das Ganze viel einfacher. 1.) Das Tray Icon Symbol mit der rechten Maustaste anklicken und auswählen ob man ein neues Workitem anlegen möchte oder an das gerade geöffnete den Screenshot anhängen möchte. 2.) Geünschten Bildbereich auswählen und Screenshot aufnehmen (Klick auf den Button im Zentrum des Fensters oder Enter drücken) 3.) Schon ist das Workitem inkl. Attachment angelegt. Wer das Ganze mal testen möchte, kann sich hier eine Demo-Version des Workitem Managers herunterladen.
Die Workitems aus dem Team Foundation Server können direkt nach Excel geladen, dort bearbeitet und wieder auf den TFS gepublished werden. Das hierzu erforderliche Add-In wird bei der Installation des Team Explorers automatisch mitinstalliert und funktioniert sehr gut. Ein wenig nervig ist allerdings, wenn man zu einem Workitem weitere Informationen sehen oder eintragen möchte und die entsprechende Spalte nicht angezeigt wird. Dann muss man die Spalte erst zur Anzeige auswählen und die Liste aktualisieren. Darüber hinaus wird die Darstellung in Excel schnell unübersichtlich, wenn man viele Felder anzeigen lässt. Wäre es nicht schön, wenn man auch in Excel den gewohnten Detail-Dialog zu einem Workitem hätte? Genau diese Funktion bietet das kostenfreie Tool Ekobit TeamCompanion for Excel. Das Workitem kann editiert und gespeichert werden. Die selbe Funktion gibt es übrigens auch für MS Project. TeamCompanion for Excel TeamCompanion for Project
In der Versionsverwaltung des Team Foundation Servers spielt Branching eine wichtige Rolle. Dabei kann man ausgehend von einem bestehenden Branch eine "Kopie" erzeugen, dort Änderungen machen und diese dann in den Ursprungsbranch zurückmergen. Leider unterstützt die UI (Sorce Control Explorer im Visual Studio) nur das mergen in den Ursprungsbrachn aus dem heraus dieser Branch abgezweigt wurde. Merging in andere Branches bezeichnet man als "Baseless Merges". Wie das geht beschreibt der TFS-Guide in einem HowTo. patterns & practices: Team Development with Visual Studio Team Foundation Server - Home
Ein Dokument auf das ich immer verweise, wenn es um die Installation des Team Foundation Servers geht ist der TFS2008 Installation Guide. Deshalb hier mal der Link für alle, die einen TFS aufsetzen wollen. Leider funktioniert das mit CD rein und Setup aufrufen nicht. Aber wenn man die Installationsanweisung befolgt, geht's meisten problemlos. Ansonsten einfach mich anmailen, ich versuche dann gerne weiterzuhelfen. Download details: Team Foundation Installation Guide
Es gibt eine ganz Reihe von Whitepapers, die verschiedene Practices aus dem Bereich ALM und deren Umsetzung mit VSTS beschreiben. - Communicate and Collaborate
- Drive Predictability
- Ensure Quality Early and Often
- Integrate Work Frequently
- Making Real-Time Decisions
- Managing Team Workflow
- Using Familiar Tools
Visual Studio Team System 2008 Capabilities White Papers
Microsoft ist ja ein Meister darin, das Thema Lizenzierung zu einer WIssenschaft zu machen und inzwischen gibt es wohl Leute, die ihr Geld damit verdienen, Firmen durch den Lizenz-Dschungel von MS zu führen. Für alle, die Fragen bezgl. der Lizenzierung von Visual Studio Team System 2008 haben, sei dieses Dokument empfohlen. Fragen dazu aber bitte nicht an mich Download details: Visual Studio Team System Licensing
Die Videos zu den Sessions vom Launch-Event in Frankfurt im Februar sind jetzt für alle frei verfügbar. Ich hatte ja die Möglichkeit, am Ende einer Session von Christian Binder kurz vorzustellen, wie wir den TFS in unserem Entwicklungsprozess nutzen. Das Video kann man hier abrufen. Mein Einsatz beginnt dann ab der Minute 54. Mein Video, das ich in dem Vortrag nutze, kann hier heruntergeladen werden. War echt ne coole Sache vor mehr als 500 Leuten zu reden. Visual Studio 2008 Team System 2008 - {Überblick}
Beim Checkin in den TFS können beim Checkin Workitems verknüpft werden. Hier können standardäßig zwei verschiedene Chck-In Actions ausgewählt werden. Associate verknüpft den Checkin nur mit dem Workitem währen Resolve das Workitem auf geschlossen setzt. Vor allem wenn man Workuiems mit größerem Umfang plant, kann es vorkommen, dass man als Default-Einstellung Associate haben möchte statt Resolve. Leider funktioniert das nicht so. Einen Workaround stellt Martin Woodward vor. Mit seiner Methode wird Resolved einfach aus den Check-In Actions entfernt und damit Associate automatisch als Default-Wert verwendet. Der Nachteil bei dieser Lösung: Man muss die Workitems außerhalb des Checkin-Prozesses auf Resolved setzen. Das ist nicht besonders schön, aber momentan leider die einzige Möglichkeit das Standard-Verhalten zu ändern. Martin Woodward: TFS Top Tip #3: Removing the Resolve Check-In Action from a Work Item
Auch wenn das unter dem Gesichtspunkt Traceability äußerst problematisch ist, gibt es im TFS 2008 die Möglichkeit Workitems zu löschen - ein Feature das oftmals gefordert wurde. Dazu benötigt man die TFS Powertools. Danach kann man mit folgendem Befehl ein Workitem löschen: tfpt destroywi /server:sartfsx01 /workitemID:8719
Mit dem Team Foundation Server Power Tools March 2008 gibt es ein cooles Features, Workitem Templates. Haben Sie sich nicht schon mal geärgert, dass Sie beim Anlegen eines Bugs immer den Namen des gleichen Entwicklers eingeben müssen oder dass sie immer die aktuelle Iteration auswählen müssen? Genau hier helfen Workitem-Templates weiter. Und das geht so: Nach der Installation der Power Tools gibt es im Team Explorer eine neuen Knoten "Work Item Templates". Hier können neue Templates angelegt werden. Für jeden Workitem-Typ können beliebig viele Templates angelegt werden. Hier können nun die gewünschten Felder vorbelegt werden. Auf Basis dieses Templates kann nun ein neues Workitem erstellt werden (Rechter Mausklick auf das Template) oder auf ein bestehendes Template angewandt werden. Weitere Informationen finden sich in der oder auf dem Blog von Brian Harry
Zusammen mit meinem Kollegen Mark werde ich am 22.04.08 bei der UG München den Vortrag zum Thema Qualitätsmanagement mit VSTS nachholen. Thema des Vortrags: Dass Qualitätsmanagement heute ein fester Bestandteil eines modernen Entwicklungsprozesses sein sollte, ist inzwischen - zumindest in der Theorie – keine Frage mehr. Die Wirklichkeit ist aber leider immer noch sehr häufig eine andere. Woran liegt das? Terminstress, sich ändernde Anforderungen im Projektverlauf und in vielen Fällen ein erheblicher bürokratischer Overhead bei der Ausführung von QM vereitelt erfolgreich, die definierten Maßnahmen auch zu leben. Die Test-Tools von Visual Studio hat wohl schon fast jeder einmal gesehen, evtl. auch genutzt. Entscheidend beim Einsatz dieser Tools ist aber die Integration in den Gesamtprozess. So besteht ein erfolgreiches QM nicht nur aus Tests, sondern auch Requirementmanagement, Releasemanagement, Testability und andere Aspekte spielen hierbei eine wichtige Rolle. Die Kunst besteht darin, diese verschiedenen Aspekte über den Gesamtprozess miteinander zu verbinden. Wie dieses Ziel mit VSTS und TFS erreicht werden kann, zeigt der Vortrag. Die ideale Zielgruppe für diesen Vortrag sind: Entwickler, Qualitätsmanager, Testexperten und IT-Entscheider mit der Bereitschaft, sich auch das ein oder andere Prozessdetail live anzusehen. Weitere Details finden sich hier
Mit der Versionsverwaltung im Team Foundation Server kann man ja bekannter maßen nicht nur Code verwalten, sondern auch andere Dateien wie z.B. SQL-Skripte, Dokumentationen etc. Hierzu ist es sinnvoll, entsprechende Ordner anzulegen. Doch das will manchmal nicht recht gelingen. Will man unterhalb dem Root eines Projektes einen neuen Ordner anlegen, kann es vorkommen, dass der Button dazu disabled ist. Der Grund dafür ist einfach (wenn man's weiß). Ein Blick in den Workspace verdeutlicht das Problem. Hier sieht man, dass im Workspace ein Mapping für den Unterordner "Benutzerverwaltung" eingerichtet ist. Da die Versionsverwaltung alle Operationen, also auch das Anlegen eines neuen Ordners aber auf dem lokalen Pfad ausführen muss, tritt hier ein Problem auf. Die Anwendung weiß nicht, wo sie den Ordner lokal anlegen soll. Abhilfe schafft hier, wenn man das Mapping auf der Projkektebene einstellt, also so: Alternativ kann man natürlich auch ein separates Mapping für den Root-Ordner des Projektes einrichten. Jetzt kann der Ordner lokal einem gültigen Pfad zugeordnet werden und der Button ist auch wieder enabled.
Wer sich nicht vom Ende der Trail-Laufzeit seines TFS überraschen lassen möchte, kann ein kleines Tool verwenden. Damit kann man sich anzeigen lassen, wie lange der TFS noch laufen wird. Außerdem kann man wenn die Laufzeit nicht mehr als 10 Tage beträgt, diese auch noch einmalig um 30 Tage verlängern kann. Für eine zweiter Verlängerung braucht man eine neue Trail ID, die man bei Microsoft anfordern muss. Das Tool gibt es auch für TFS 2005 wobei ich mir kaum vorstellen kann, das heute noch jemand den TFS 2005 evaluiert. TFSVersionDetection.zip Weitere Informationen bei Brian Harry
Nachdem wir immer mehr Anfragen bezgl. unseres artsio WorkitemManager und x64 Systemen erhalten haben, haben wir hier in den letzten Tagen mal versucht, die TFS API unter Vista x64 zum Laufen zu bekommen und ich möchte das hier auch mal posten. Das Problem stellt sich in der Entwicklungsumgebung folgendermaßen dar. Direkt nach dem Start der Anwendung bekommt man folgenden Fehler: Die Assembly ist natürlich da. Die Lösung dafür ist sehr einfach. Man muss dem Projekt lediglich sagen, dass es eine x86 Anwendung ist. Dann wird es unter x64 als x86 Anwendung ausgeführt und kann damit auch die TFS API verwenden. Dazu muss man lediglich in den Eigenschaften des Projektes als Plattform explizit x86 auswählen. Nach unseren bisherigen Tests scheint damit die API auch auf x64 Systemen problemlos zu funktionieren.
Die Tatasache, dass sich Visual Studio Team System inzwischen zu einem Produkt mit einer enormen Funktionsvielfalt entwickelt hat, wird schon alleine dadurch dokumentiert, dass es vom 22.04 bis 24.04 eine Konferenz gibt, die sich nur mit diesem Produkt beschäftigt. Die Vorträge decken dabei einen großen Bereich von Projektmanagement über Qualitätsmanagement bis hin zu Best Practices und Erfahrungsberichte ab. Ich selbst werde auch mit einem Vortrag zum Thema hierarchische Workitems vertreten sein. Wer schon mal einen Blick in die Zukunft werfen möchte, dem sei der Vortrag von Christian Binder zum Thema Rosario ans Herz gelegt. Würde mich freuen, den einen oder anderen Leser meines Blogs auf der TeamConf persönlich kennen zu lernen. Wer auch dort ist, kann mir einfach einen Kommentar hinterlassen. 
Die Frage "Wie lösche ich ein Team Projekt von meinem Team Foundation Server?" taucht immer wieder auf. Deshalb hier ein paar Infos dazu: 1.) Im Sourcecontrolexplorer kann man nur Dateien aus der Quellcodeverwaltung löschen 2.) Auch mit dem Commandozeilentool tf delete werden nur Quellcode-Dateien gelöscht. 3.) Zum Löschen eines kompletten Team-Projekts verwendet man das Commandozeilentool TfsDeleteProject /server:myteamserver “My Project“
Beim Betrieb des TFS gibt es hin und wieder Probleme mit dem lokalen Cahce. Vor allem wenn man mit mehreren Servern arbeitet, kommt es da immer wieder mal zu Problemen. Diese lassen sich durch Löschen des Caches lösen.Für mich selbst zur Erinnerung hier nochmals die Pfade: Unter XP: C:\Dokumente und Einstellungen\<User>\Lokale Einstellungen\Anwendungsdaten\Microsoft\Team Foundation\2.0\Cache Unter Vista: C:\Users\<User>\AppData\Local\Microsoft\Team Foundation\2.0\Cache
Um SQL-Projekte aus dem Management-Studio mit der Versionsverwaltung des Team Foundation Server zu verwalten gibt es einen recht einfachen Weg. Zunächst muss der MSSCCI-Provider installiert werden. Dann geht man im Management-Studio unter Tools / Options auf Source_Control und prüft, ob der richtige Provider eingestellt ist. Dann kann man seine Management-Studio Projekte einfach in die Quellcode-Verwaltung einfügen, wie man das aus Visual Studio gewohnt ist. Also einfach rechte Maustaste auf die Solution und Add Solution to Source Control. Nach der Auswahl des Servers und erfolgter Anmeldung wählt man den Ordner in der Versionsverwaltung aus. Und schon kann man seine SQL-Scripts in der Versionsverwaltung auschecken, einchecken etc. 
Ich bin gerade von der BASTA! Spring zurückgekehrt. Ich hatte dort 2 Vorträge.
Der absolute Oberknüller war mein erster Vortrag:
Beginn: 17:30 Uhr Thema: Qualitätsmanagement mit VSTS
ich hatte mich eigentlich schon darauf eingestellt, in einer kleinen überschaubaren Runde das Thema mit zwei Leuten zu diskutieren, die sich eigentlich nur verlaufen haben oder in den anderen Sessions keinen Platz mehr bekommen haben. Aber was soll ich sagen. Die Bude war voll! Den Vortrag haben sich ca. 50 Leute angehört und keiner ist vorzeitig gegangen oder eingeschlafen (glaube ich mal). Ich habe dann in dem Vortrag versucht, das Tooling aus dem VSTS, das bereits einige Speaker vor mir vorgestellt haben, in einen Prozess einzubinden, damit am Ende möglichst viel Qualität rauskommen. Danke für das große Interesse.
Hier noch meine Folien zu dem Vortrag:
Die zweite Session war zum Thema Programmierung mit dem TFS SDK.
Zu diesem Vortrag gibt es die
Folien, das
Demo  und auch noch das Video, das ich ganz am Anfang gezeigt habe.
Das TFS DataWarehouse wird standardmäßig jede Stunde aktualisiert. Das kann oft zu lange sein, gerade wenn man Reports neu anlegt. Will man nicht bis zur nächsten automatischen Aktualisierung warten, kann man das auch manuell anstarten. Hierzu ruft man die folgende URL auf dem TFS Application Tier auf: http://localhost:8080/Warehouse/v1.0/warehousecontroller.asmx?op=Run Dann einfach auf Invoke klicken uns schon startet der Aktualisierungs-Prozess
Das Veröffentlichen von Test Results auf dem TFS-Server ist eine schöne Sache, die vor allem die Kommunikation zwischen Tester und Entwickler erleichtert Aber damit gibt es immer wieder Probleme. Ich hatte gerade so einen Fall und möchte den hier kurz beschreiben, vielleicht kann jemand anderer sich damit Zeit sparen. Nach dem Publish erhielt ich immer die Meldung "The test result share \\notebook_thomas\builds\WVBuild_20080226.3\TestResults\41577b87-2935-473c-bf03-423c777cd030 is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. Failed to upload test run results to the drop location '\\notebook_thomas\builds'. Ask your server administrator to make the drop location available." Das Problem liegt, wie sich aus der Fehlermeldung vermuten lässt, in den Berechtigungen. Ich hatte als Szenario den Build-Agent auf dem selben Rechner eingerichtet, auf dem ich auch entwickle. Wichtig sind hier zwei Dinge: - Es müssen die Berechtigungen auf dem Verzeichnis und auf dem Build Share eingerichtet sein.
- Es müssen Berechtigungen für den lokalen User eingerichtet sein.
Bei mir war Punkt 2 das Problem. Ich hatte für den lokalen Benutzer, mit dem ich im Visual Studio arbeite, keine Berechtigungen auf dem Share, deshalb diese Meldung. Nachdem ich diese Berechtigung eingetragen habe, funktionierte es ohne Probleme.
In den letzten Tagen wurde ich häufiger gefragt, welche Edition von Visual Studio man benötigt, um mit dem Team Foundation Server zu arbeiten. Viele sind irrtümlicherweise der Meinung, dass der TFS nur mit dem VSTS zusammenarbeitet, aber das stimmt glücklicherweise nicht. Bereits ab der Standard-Edition wird der Team-Explorer in Visual Studio integriert und man hat Zugriff auf die Quellcode-Verwaltung und Workitems, wie man das auch aus dem VSTS zusammen mit dem TFS gewohnt ist. Da der Team-Explorer sich ja auch als Standalone installieren lässt, wäre theoretisch auch ein Arbeiten mit der Express-Edition möglich, aber das ist natürlich nicht mehr sehr komfortabel. Ich würde aber auf jeden Fall dei Professional-Edition von Visual Studio 2008 empfehlen, da diese nun auch Unit-Tests unterstützt und für einen normalen Entwickler damit eigentlich ausreichend sein sollte.
Brian Harry beschreibt in diesem Beitrag verschiedene Upgrade-Szenarien, so z.B. auch wie eine Workgroup-Edition auf eine Full Version upgegraded (furchtbar diese Entwickler, können einfach kein Deutsch, hat jemand dafür eine Übersetzung?) werden kann. Danke an Lars für den Link bharry's WebLog : How do I upgrade to TFS 2008?
Wir nutzen in unserem Entwicklungsprozess seit einiger Zeit den Team Foundation Server. Für das Requirement Management setzen wir Workitems ein. In der aktuellen Version des Team Foundation Servers fehlte uns dabei bisher allerdings die Möglichkeit, Workitems hierarchisch zu organisieren. Glücklicherweise verfügt der Team Foundation Server über ein leistungsfähiges API (siehe auch meinen MSDN-Webcast zu diesem Thema). Auf Basis dieser API haben wir ein Tool, den artiso Workitem Manager, entwickelt, mit dem wir nun Workitems so strukturieren können, wie wir das in unseren Projekten brauchen. Neben der hierarchischen Struktur können auch Iterationen in Baumstrukturen abgebildet werden.  Ebenfalls Bestandteil des artiso Workitem Manger ist ein Word-AddIn mit der Spezifikationsdokumente auf Funktionsebene verwaltet werden können. Damit lassen sich verschiedene Probleme mit Spezifikationsdokumente als monolithische Worddokumente lösen.  Den artiso Workitem Manager kann als Beta-Version kostenlos heruntergeladen werden. Die frei verfügbare Version ist auf 50 Workitems begrenzt. Weitere Informationen finden sich hier.
Des TFS SDK enthält ein Control um Workitems in Winforms zu bearbeiten. Dieses Control löst damit das Problem, wie die hochflexible Struktur von Workitems in einer eigenen Anwendung dargestellt und bearbeitet werden kann. Mit dem neuen TFS SDK 2008 gibt es allerdings ein kleines Problem beim Einsatz des Controls. Wird das Control in eine Winform eingebaut, kommt es zu einer NullReferenceException. Object reference not set to an instance of an object. Dieses Problem konnte ich bei mir umgehen, indem ich nicht die DLL aus dem SDK sondern aus dem TeamExplorer. Ich habe die beiden DLLS, die ich hier ausgetauscht habe hier zum Download bereitgestellt.
Über die TFS-API kann der Namen eines TFS-Servers einfach abgefragt werden. Dazu kann folgender Code verwendet werden: private TeamFoundationServer tfs; NetworkCredential account = new NetworkCredential(user, password); tfs = new TeamFoundationServer(server, account); string ServerName = tfs.Name; Dabei habe ich allerdings folgendes Problem festgestellt: Der Servername ist nicht konsistent. Ist der Server im Team-Explorer noch nicht geristriert, enthält der Servername auch den Port. Nachdem der Server im Team-Explorer dann registriert wurde, wird nur noch der Server-Name zurückgegeben. Das sollte man auf jeden Fall berücksichtigen, wenn man mit dem Name-Property vom tfs arbeitet.
Aus dem Fenster mit Fehlermeldungen und Wahrnungen im Visual Studio heraus kann man direkt Workitems auf dem Team Foundation Server anlegen. Dazu einfach die entsprechende Zeile mit der rechten Maustaste anklicken und im Kontextmenü "Create Work Item" wählen. Es werden automatisch Informationen in den Titel und den Verlauf übernommen, wobei meiner Meinung nach die Details eher in das Beschreibungs-Feld gehören als in den Verlauf. 
Im TFS 2008 hat Microsoft endlich die Lizenzbedingungen angepasst. Für folgende Aktionen wird nun keine CAL mehr benötigt: - Anlegen eines Workitems
- Anzeigen der Workitems, die ein Benutzer selbst angelegt hat
- Bearbeiten der Workitems außer Änderung des Status des Workitems
Damit ist es nun endlich möglich, Kunden etc. in das Projekt besser einzubinden, ohne dafür Unsummen für CALs auszugeben. adamga's WebLog : TFS for Defect Tracking! Licensing Change!!!
Der Team Foundation Server ist ein sehr flexibles Werkzeug. Es lässt sich an verschiedene Prozessmodelle anpassen. Die die beiden folgenden Links verweisen zu entsprechenden Kapiteln in der MSDN-Hilfe die beschreiben wie Workitem Typen und Prozessvorlagen angepasst werden können. Customizing Work Item Types Customizing Process Templates
Wenn man eine Datei löscht, die in der Quellcode-Verwaltung eingecheckt war, kann man diese leicht aus der Quellcode-Verwaltung wiederherstellen. Dazu muss man aber zuerst eine kleine Einstellung vornehmen. Unter Tools / Options / Source Control / Visual Studio Team Foundation Server kann man die Option "Show deleted items in the Source Control Explorer" aktivieren. Dann werden im Source Control Explorer gelöschte Elemente angezeugt, die man einfach "undeleten" kann. 
Die Arbeitsbereiche des Team Foundation Server stellen eine Verknüpfung eines lokalen Verzeichnisses mit einem Pfad in der Quellcode-Verwaltung her. Aus verständlichen Gründen kann ein und das selbe Verzeichnis nicht mehrfach zugeordnet werden. Dies gilt insbesondere für den Fall, dass zwei verschiedene Benutzer auf dem gleichen Rechner das selbe Verzeichnis zuordnen wollen, auch wenn es sich auf den gleichen Pfad in der Quellcode-Verwaltung bezieht. Das ganze macht Sinn. Aber was tun, wenn z.B. der Benutzer A nicht mehr existiert und nun Benutzer B seine Projekte übernehmen soll? Der Rat lautet hier, von Benutzer A alle Arbeitsbereiche löschen, bevor der Benutzer gelöscht wird. Der Rat hilft aber wenig, wenn der Benutzer bereits gelöscht wurde und man dann erst die Probleme feststellt. Oder wenn, wie in meinem Fall, durch einen Umzug auf einen anderen Server der Benutzer neu angelegt wurde und zwar den gleichen Namen hat, aber eine andere SID. Die Anpassung der SIDs in der TFS-Datenbank scheint hier nicht richtig funktioniert zu haben.
Den lokalen Workspace zu löschen ist kein Problem, aber das hilft leider in diesem Fall nicht. Die Arbeitsbereiche sind auch zusätzlich noch auf dem Server gespeichert und dort muss man diesen nun löschen, damit man den mit dem neuen Benutzer neu einrichten kann.
Zunächst der Befehl, mit dem man die Workspaces vom Server anzeigen kann:
tf workspaces /owner:* /server:<TFS-Servername> /format:detailed
Um einen Workspace zu löschen kann nun folgender Befehl verwendet werden:
tf workspace /delete <Workspace-Name>;<Benutzername> /server:<TFS-Servername>
Es gibt auch noch den Befehl /updateUserName, der hat in meinem Fall aber leider nicht funktioniert.
Wenn der Team-Explorer behauptet, einen nicht mehr zu kennen und mit folgender Meldung behauptet, man stellt keine bekannte Identität dar,

dann kann dieses Problem behoben werden, indem man den Cache des Team-Explorers löscht. Dieser liegt unter Vista im Ordner C:\Users\Thomas\AppData\Local\Microsoft\Team Foundation\1.0\Cache. Hier einfach alle Unterordner löschen und schon klappts wieder mit dem TFS.
Die Workitems von Team System lassen sich ja einfach in Excel abfragen und bearbeiten. Jedoch war ich mit den angeboteten Spalten nicht zufrieden. Man kann zwar über einen entsprechenden Button noch beliebige weitere Spalten abrufen, das aber jedesmal zu tun war dann doch ein wenig nervig. Nach einigem Suchen habe ich dann die Lösung gefunden. Man muss sich einfach eine eigene Query anlegen und dort die gewünschten Spalten definieren. Wenn man nun über diese Query die Workitems in Excel abfragt, kommen genau die Spalten, die in der Query definiert sind.
Team Foundation Sidekicks ist eine Sammlung von Tools, die verschiedene Aufgaben bei Nutzung und Verwaltung von Team Foundation Server erleichtern. Unter anderem wird eine vereinfachte Verwaltung von Labels angeboten:

Link to Team Foundation Sidekicks
Lars Keller berichtet über das Tool IEeee, das es ermöglicht, direkt aus dem IE einen Fehlerbericht mit detailierten Informationen als WorkItem im Team System Server anzulegen. Das Tool dürfte vor allem für Tester sehr interesant sein. Link to IEeee: Home
Crum for Team System ist ein kostenloses add-in für Visual Studio Team System, das agile Entwicklungsmethoden nach Scrum unterstützt.
Link to Scrum for Team System
WorkItems für den Team Foundation Server lassen sich einfach per Code erstellen.
TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer("tfs-test");
WorkItemStore store = (WorkItemStore)tfs.GetService(typeof(WorkItemStore));
WorkItemType wiType = store.Projects[0].WorkItemTypes[1];
WorkItem newWI = new WorkItem(wiType);
newWI.Title = "Title";
newWI.Save();
Für den Code müssen noch folgende Namespaces referenziert und eingebunden werden:
using Microsoft.TeamFoundation;
using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.WorkItemTracking.Client;
Dazu muss das Visual Studio SDK installiert sein.
Zu beachten ist, dass die Angaben für die Eigenschaften des WorkItems sprachspezifisch sind. Auf einem deutschen Server wird folgender Code nicht laufen:
newWI.State = "Active";
Auf dem deutschen Server muss das dann heissen:
newWI.State = "Aktiv";
Unschöner zu lesen, aber dafür sprachunabhängig ist die Verwendung von IDs.
Um übrigens ein Workitem zu lesen, kann folgender Code verwendet werden:
WorkItem newWI2 = store.GetWorkItem(92);
Wird eine Datei aus der TeamSystem SourceControl ausgecheckt, wird von dieser datei nicht automatisch die letzte Version gehohlt wie man das von VSS gewohnt ist. Der Grund dafür ist, dass dadurch evtl. ein inkonsistenter Zustand der Anwendung entstehen könnte, da die ausgecheckte Datei in einer neueren Version vorliegt, die nicht mit den restlichen dateien des Projekts kompatibel ist.
Weitere Ausführungen unter: http://blogs.vertigosoftware.com/teamsystem/archive/2006/05/15/2755.aspx
Um die Work Items aller Team-Projekte eines Team-Servers anzeigen zu können, kann man einfach eine entsprechende Query anlegen. Hierzu einfach im Team-Explorer auf Work Items mit der rechten Maustaste klicken und dann "Add Query" auswählen. Die Query is dann schon mit einem Filter nach einem Projekt vorbelegt. Diesen einfach löschen, dann erscheinen alle Work Items.
Projekte aus Visual Source Safe 2005 können mit Hilfe eines Konverters nach Team Foundation Server migriert werden. Dabei bleibt die Historie komplett erhalten. Eine Migration von Visual Source Safe 6.0 nach VSS 2005 kann über Backup / Restore erfolgen.
http://msdn2.microsoft.com/en-us/library/ms253060.aspx
|
Copyright © 2010 Thomas. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|