Neues rund um's Thema .Net, Team Foundation Server und SCRUM RSS 2.0
# Tuesday, January 31, 2012

Der TFS bzw. der MTM unterstützen leider keine Versionierung von Test Cases. Wenn man nun für unterschiedliche Versionen einer Software Test Cases verwalten möchte, muss man die Test Cases kopieren. Wie damit die Versionierung von Test Cases abgebildet werden kann, habe ich hier beschrieben.

Um das Kopieren größerer Mengen von Test Cases zu vereinfachen, gibt es nun das Test Case Copy Tool von Anna Russo.

http://www.improvingsoftwarequality.com/2012/01/new-version-of-bulk-copy-test-cases.html

Tuesday, January 31, 2012 10:17:17 AM (Mitteleuropäische Zeit, UTC+01:00)  #    Comments [0] -
Testing | TFS 2010 | Tools | VS 2010
# Wednesday, November 09, 2011

Eine häufige Frage ist, wie ich mit dem TFS und Microsoft Test Manager (MTM) die Versionierung von Test Cases bewerkstellige. Ziel dabei ist, dass ich verschiedene Releases meiner Software mit den dazu passenden Test Cases testen möchte, also z.B. für die aktuelle Entwicklung nutze ich einen neueren Test Cases da sich die Funktion inzwischen verändert hat aber wenn ich einen Hotfix für eine frühere Version testen möchte, benötige ich dafür natürlich den passenden Test Cases zu diesem Release.

Die aktuelle Lösung sieht im MTM so aus, dass man einen Test-Plan je Version einrichtet. In diesem Test-Plan habe ich dann die Test-Cases für die aktuelle Version referenziert. Für die nächste Version legt man einen neuen Test-Plan an und kopiert die Test-Suites.

image

Durch dieses Kopieren wird ein neuer Test-Plan angelegt der dann allerdings auf die selben Test Cases verweist wie die der Plan für die erste Version. Das ist ja genau die Ausgangssituation die man in den meisten Fällen haben möchte denn die meisten Test Cases sind ja in der neuen Version gleich wie in der Vorgänger-Version und diese werden ggf. durch neue Test Cases (z.B. 4a) ergänzt. Wenn sich ein Test Case nun ändert, dann darf dieser im neuen Test-Plan nicht angepasst werden, sonst würde ja damit auch der Test-Plan der Vorgängerversion geändert werden. Statt dessen muss der Test Case kopiert und die Kopie (2b) dem neuen Test Plan zugeordnet werden. Die Kopie kann nun geändert werden.

image

Wer eine größere Menge von Test Cases kopieren muss kann dafür übrigens auch ein Tool verwenden das Anna Russo veröffentlicht hat:

http://improvingsoftwarequality.blogspot.com/2011/11/bulk-copy-test-cases-tool-for-microsoft.html

Wednesday, November 09, 2011 2:23:52 PM (Mitteleuropäische Zeit, UTC+01:00)  #    Comments [0] -
Team System Server | Testing | TFS 2010 | VS 2010
# Tuesday, November 01, 2011

Will man auf einen TFS über eine Internet-Verbindung zugreifen, dann bieten sich zwei Wege an: Entweder per VPN oder per SSL. Der Weg über SSL ist eigentlich der einfachere, Nachteil dabei ist allerdings, dass man ein Zertifikat von einer offiziellen Registrierungsstelle kaufen muss. Aber es geht auch ohne.

Dazu muss man zunächst ein Tool aus dem IIS 6 Ressource-Kit herunterladen. Das Tool gibt es auch einzeln hier zum Download.

Damit können wir nun ein SSL-Zertifikat generieren.

selfssl /N:CN=my.domain.com /K:2048 /V:730 /P:443 /S:3 /t

Der Parameter /V gibt die Gültigkeitsdauer in Tagen an, der Parameter /P den Port auf dem SSL laufen soll und /S die ID der Web Site des TFS. Letztere bekommt man einfach heraus indem man die Advanced Settings der Web Site aufruft.

image

Da der TFS im Normalfall ja nicht direkt mit dem Internet verbunden ist, muss der Port noch entsprechend auf der Firewall auf den jeweiligen Server auf dem der TFS läuft weitergeleitet werden. Diese Einstellung hängt natürlich von der jewweils eingesetzten Firewall ab.

Nun können wir eigentlich den Server bereits über den Web Access erreichen, z.B. https://my.domain.com/tfs/web . Achtung hier wird beim Einsatz von SSL kein Port mit angegeben sofern der Standard-Port verwendet wird. Im Browser bekommt man zwar eine Meldung, dass das Zertifikat nicht gültig ist, aber diese kann man entsprechend übergehen.

image

Das Problem ist, dass Visual Studio sich so nicht verbinden mag. Gibt man im Registrierungsdialog für neue Server die URL ein und stellt das Protokoll auf https dann erhält man folgenden Fehler:

---------------------------
Microsoft Visual Studio
---------------------------
Microsoft Visual Studio

TF31002: Unable to connect to this Team Foundation Server: my.domain.com.

Team Foundation Server Url: https://my.domain.com/tfs

Possible reasons for failure include:

- The name, port number, or protocol for the Team Foundation Server is incorrect.

- The Team Foundation Server is offline.

- The password has expired or is incorrect.

Technical information (for administrator):

The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
---------------------------
OK   Help  
---------------------------

 

Als Lösung müssen wir auf den Clients das Zertifikat installieren. Dazu muss man das Zertifikat auf dem Server zunächst exportieren. Im IIS Manager dazu einfach auf dem Server die Option Server Certificates doppelt klicken.

image

Dann kann das Zertifikat über die Option Export in eine Datei exportiert werden indem das Ziel und ein Passwort angegeben werden. Diese Datei kopieren wir nun auf den Client und klicken diese dort doppelt an. Es öffnet sich der Certificate Import Wizard. Hier können wir für die ersten beiden Seiten zunächst Weiter klicken. Dann geben wir das Kennwort ein dass wir beim Export angegeben haben. Auf der nächsten Seite geben wir an, dass wir das Zertifikat in einen spezifischen Store importieren wollen, nämlich in den “Trusted Root Certification Authorities”

image

Nun können wir uns auch mit Visual Studio ohne Probleme auf unseren Server verbinden.

Tuesday, November 01, 2011 1:56:11 AM (Mitteleuropäische Zeit, UTC+01:00)  #    Comments [0] -
TFS 2010 | VS 2010
# Wednesday, October 19, 2011

Im Team Build lässt sich die Statische Code-Analyse (FxCop) recht einfach aktivieren. 

image

Leider geht es mit StyleCop nicht ganz so einfach. Eine Möglichkeit ist, in den Projektdateien die StyleCop-Analyse einzutragen und dann auf dem Build-Rechner MSBuild die StyleCop-Analyse auszuführen (siehe http://stylecop.codeplex.com/wikipage?title=Setting%20Up%20StyleCop%20MSBuild%20Integration&referringTitle=Documentation)

Alternativ kann man sich auch einfach eine Build Activity bauen die die StyleCop Analyse ausführt. Eine solche Activity habe ich am Ende dieses Posts zum Download bereitgestellt. Um diese zu nutzen entpackt man einfach die DLLs. Diese werden dann in der Versionsverwaltung abgelegt. Diesen Pfad muss man anschließend auf dem Build-Controller registrieren.

image

SNAGHTML161d9502

SNAGHTML161e4efd

Nun können wir im Visual Studio ein Projekt anlegen. Hier referenzieren wir die DLLs aus der ZIP-Datei und kopieren unseren Build-Workflow hinein. Nun können wir im Workflow ein neues Argument vom Typ StyleCopSettings anlegen.

image

Dann brauchen wir noch eine Variable

image

Nun können wir den Workflow erweitern.

image

  <If Condition="[Not String.IsNullOrEmpty(StyleCopSettings.StyleCopSettingsFile) And StyleCopSettings.PerformStyleCopAnalysis]" DisplayName="If StyleCop Settings not empty run StyleCop">
    <If.Then>
      <Sequence>
        <sap:WorkflowViewStateService.ViewState>
          <scg:Dictionary x:TypeArguments="x:String, x:Object">
            <x:Boolean x:Key="IsExpanded">True</x:Boolean>
          </scg:Dictionary>
        </sap:WorkflowViewStateService.ViewState>
        <mtbwa:ConvertWorkspaceItem DisplayName="Convert Server Path to Local Path" mtbwt:BuildTrackingParticipant.Importance="Low" 
Input="[StyleCopSettings.StyleCopSettingsFile]" Result="[StyleCopLocalSettingsFile]" Workspace="[Workspace]" />         <absa:StyleCopVerifier AnalysisResults="{x:Null}" ViolationCount="{x:Null}" SettingsFile="[StyleCopLocalSettingsFile]" SourcesDir="[SourcesDirectory]" />       </Sequence>     </If.Then>   </If>

Wenn wir nun auf Basis dieses Workflows eine Build Definition anlegen, können wir die StyleCop Settings dort einstellen und unser Build ob unsere StyleCop Rules auch alle eingehalten werden.

image

Wednesday, October 19, 2011 1:39:28 AM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
Team System Server | TFS 2010 | VS 2010
# Tuesday, October 04, 2011

Ich verwende gerne Excel um mein Product Backlog im TFS zu sortieren. Dazu rufe ich die Work Items des PBL einfach aus Excel ab, sortiere diese und verwende dann die Excel Autonummerierungs-Funktion um den Stack Rank neu zu nummerieren. Das funktioniert sehr gut. Einziger Punkt der immer etwas nervt ist das Ausschneiden und Einfügen der Zeilen im Excel um diese zu verschieben. Hier gibt es allerdings eine elegante Lösung die allerdings ein wenig Fingerspitzengefühl erfordert und die nicht gerade intuitiv ist.

Zuerst markiert man die Zeile(n) die man verschieben möchte

SNAGHTML1498cb94

Dann fährt man mit der Maus auf die obere Kante der Markierung

SNAGHTML149808f1

Nun kann man mit gedrückter rechter Maustaste die Zeile an eine andere Position schieben. Danach öffnet sich ein Kontext-Menü in dem man dann verschiedene Optionen zur Auswahl hat. “Move here” bedeutet das das Ziel überschrieben wird. Für den oben beschriebenen Fall brauchen wir also “Schift Down and Move” damit die verschobene Zeile eingefügt wird.

SNAGHTML149c0e4e

Alternativ kann man auch mit der linken Maustaste verschieben und dann im Verschieben die Shift-Taste drücken. Die Einfügezeile passt sich dann entsprechend an um anzuzeigen das die Zeile eingefügt wird und nicht der Inhalt überschrieben wird (ohne gedrückter Shift-Taste)

SNAGHTML149e8448

Tuesday, October 04, 2011 7:32:32 PM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [2] -
Excel | Team System Server | TFS 2010 | Tipps und Tricks
# Friday, September 16, 2011

Wir hatten heute die Anforderung dass wir im Lab eine Software installieren mussten die über eine Lizenz freigeschaltet wird. Diese Lizenz is an die MAC-Adresse der Netzwerkkarte gebunden. Ziel war es nun, dass wir mit der selben Lizenz die Software auf mehreren Lab Environments betreiben können. Dabei ging es nicht darum die Lizenzprüfung auszuhebeln sondern mit der selben Konfiguration auf mehreren Labs zu testen. Was nicht funktioniert, ist dass man im Netz mehrere Netzwerkkarten mit der selben MAC Adresse hat. Aber für die virtuellen Maschinen gibt es da eine einfache Lösung. Man fügt einfach eine virtuelle Netzwerkkarte hinzu die nicht mit dem Netz verbunden ist.

Dazu müssen wir in der VM einen weiteren Netwerkadapter hinzufügen den wir einfach auf “Not connected” stellen und für den wir dann eine MAC-Adresse angeben können.

image

Friday, September 16, 2011 5:31:43 PM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
Lab Management | Team System Server | TFS 2010

Heute hatte ich das Problem bei einem Kunden dass neu angelegte Areas nicht sofort auf den Work Items sichtbar waren. Was zuverlässig geholfen hat, war eine Recycle des Application Pools. Das ist aber natürlich auch keine Lösung. Im Web habe ich einige Threads zu diesem Problem gefunden, aber keine wirkliche Lösung. Deshalb möchte ich hier kurz beschreiben, welche Analysemöglichkeiten es hier gibt.

Zunächsteinmal habe ich folgende Zusammenhänge herausgefunden:

Wenn man in einem Client (Visual Studio, Excel, Project, Web Access etc.) eine Iteration anlegt, wird diese in der DB der Project Collection unter der Tabelle tbl_Nodes eingetragen. Dann wird eine Stored Procedure aufgerufen die eine Verarbeitung antriggert. Diese Verarbeitung wird vom Visual Studio Team Foundation Background Job Agent ausgeführt. Dieser schreibt dann einen neuen Eintrag in die Tabelle TreeNodes. Von dort werden die Items für die Work Items gelesen.

Damit ergeben sich folgende Schritte die ich empfehlen kann um das Problem zu untersuchen:

  1. Prüfen ob der Visual Studio Team Foundation Background Job Agent Dienst läuft und ob dieser mit dem Account ausgeführt wird mit dem auch der TFS installiert wurde.
  2. Prüfen ob die neuen Areas sowohl in tbl_Nodes als auch in TreeNodes eingetragen werden
  3. Für den Visual Studio Team Foundation Background Job Agent kann ein Tracing aktiviert werden. In diesem sollte ein entsprechender Eintrag für die Verarbeitung der Area stehen. Man kann einfach nach dem Namen der neuen Area suchen. Das Tracing aktiviert man in der Datei "C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\TFSJobAgent\TfsJobAgent.exe.config"
   1:  ...
   2:    <system.diagnostics>
   3:      <trace autoflush="false" indentsize="4">
   4:        <!--To enable tracing to file, simply uncomment listeners section and set trace switch(es) below.
   5:            Directory specified for TextWriterTraceListener output must exist, and job agent service account must have write permissions. -->
   6:        <!--<listeners>
   7:          <add name="myListener" 
   8:            type="System.Diagnostics.TextWriterTraceListener" 
   9:            initializeData="C:\Replace_Me_With_A_Directory_The_Service_Account_Can_Write_To\jobagent.log" />
  10:          <remove name="Default" />
  11:        </listeners>-->
  12:      </trace>
  13:      <switches>
  14:        <!--  Trace Switches
  15:              Each of the trace switches should be set to a value between 0 and 4, inclusive.
  16:                0: No trace output
  17:                1-4: Increasing levels of trace output; see Systems.Diagnostics.TraceLevel-->
  18:        <add name="API" value="0" />
  19:        <add name="Authentication" value="0" />
  20:        <add name="Authorization" value="0" />
  21:        <add name="Database" value="0" />
  22:        <add name="General" value="0" />
  23:        <add name="traceLevel" value="0" />
  24:      </switches> 
  25:     </system.diagnostics>
  26:  ...

Die Zeilen 6-11 müssen einkommentiert und für das Log-File ein gültiger Pfad angegeben werden. Dann kann man die Trace-Levels auf einen Wert zwischen 1 und 4 für die einzelnen bereiche setzen. Ich hatte einfach mall alles auf 4 gesetzt. Natürlich nicht vergessen das nach der Fehleranalyse wieder zurückzusetzen.

Damit sollte sich der Fehler identifizieren und beheben lassen. Viel Erfolg!

Friday, September 16, 2011 4:12:45 PM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
Team System Server | TFS 2010 | VS 2010
# Tuesday, September 13, 2011

Erstellen einer simplen Custom Checkin Policy

In diesem Beispiel wollen wir eine Custom Checkin Policy erstellen die prüft, ob beim Checkin ein Kommentar min einer bestimmten Mindestlänge angegeben wurde. Es gibt ja bereits mit den Powertools eine Policy die prüft, ob überhaupt ein Kommentar angegeben wurde, aber wir wollen auch zu einem gewissen Maße prüfen, ob der Kommentar auch sinnvoll ist indem wir eine Mindestlänge erwarten. Zur Erstellung dieser Policy gehen wir als folgendermaßen vor:

 

1.)      Wir erstellen ein neues ClassLibrary Projekt in Visual Studio

2.)      Wir fügen eine Referenz zur Microsoft.Teafoundation.VersionControl.Client.dll hinzu. Diese findet man unter ReferenceAssemblies im VS DIE Ordner, also z.B. C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.VersionControl.Client.dll

3.)      Wir leiten unsere Klasse von PolicyBase ab und lassen Stubs generieren. Der Zwischenstand sieht dann so aus:
clip_image002[4]

4.)      Wir setzen nun die Properties mit entsprechenden Werten, z.B.

public override string Description

        {

            get

            {

                return "Will check if the checkin comment is at least 10 letters long.";   

            }

        }

 

        public override bool Edit(IPolicyEditArgs policyEditArgs)

        {

            return true;

        }

 

        public override PolicyFailure[] Evaluate()

        {

            throw new NotImplementedException();

        }

 

        public override string Type

        {

            get

            {

                return "Changeset Comments Length Policy";

            }

        }

 

        public override string TypeDescription

        {

            get

            {

                return "This policy will require users to provide checkin comments of a minimum length.";

            }

        }

Wichtig sind hier vor allem Type und Type Description da diese bei der Auswahl der Policy angezeigt werden.

5.)      Nun wollen wir die Evaluate-Methode implementieren. Diese wird vor dem Checkin ausgeführt und liefert mögliche Verletzungen der Policy zurück. Nur wenn keine Verletzungen gemeldet werden, wird der Checkin ausgeführt. Da wir hier den Checkin Comment prüfen wollen, brauchen wir Zugriff auf das Changeset. Dazu brauchen wir zuerst ein Feld das den Checkin enthält:

 

private IPendingCheckin currentPendingCheckin;

 

6.)      Nun überschreiben wir die Initialize-Methode und setzen hier unser currentPendingCheckin:

 

public override void Initialize(IPendingCheckin pendingCheckin)

{

    base.Initialize(pendingCheckin);

 

    currentPendingCheckin = pendingCheckin;

}

                                                                                                                        

7.)      Anschließend implementieren wir unsere Validierungslogik in der Evaluate-Methode:

public override PolicyFailure[] Evaluate()

{

    var failures = new List<PolicyFailure>();

    if (currentPendingCheckin.PendingChanges.Comment.Length < 10)

    {

        failures.Add(new PolicyFailure("Checkin Comment is too short, at least 10 letters are required", this));

    }

    return failures.ToArray();

}

 

8.)      Dann folgt noch ein wichtiger Schritt, wir müssen die Klasse serialisierbar machen

[Serializable]

public class CheckinCommentLengthPolicy : PolicyBase

 

9.)      Nun kompilieren wir die Solution und kopieren die DLL in einen lokalen Ordner. Anschließend tragen wir in der Registry unter „HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Checkin Policies“ einen neuen String Value ein dem wir den Pfad zu unserer Assembly übergeben. Der angegebene Pfad in der Registry ist dabei für x64 Systeme angegeben. Bei c86 Systemen lautet der passende Pfad „HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Checkin Policies“.

clip_image004[4]

 

10.)   Nun starten wir Visual Studio neu und aktivieren die neue Checkin Policy. Dazu klicken wir im Team-Explorer mit der rechten Maustaste auf das Team-Projekt dann unter Team Project Settings / Source Control und dort wechseln wir dann auf den Reiter „Check-in Policy“. Über den Button Add können wir unsere Policy auswählen und hinzufügen.

clip_image006[4]

 

11.)   Nun können wir einen Eincheckvorgang vornehmen und wir werden sehen, wenn wir einen leere checkin Comment angeben oder einen zu kurzen, erhalten wir eine Meldung.


 

clip_image008[4]

 

Konfigurierbarkeit der Policy hinzufügen

Nun wollen wir die Anzahl der Mindestzeichen noch konfigurierbar machen. Dazu erweitern wir unsere Policy.

 

1.)   Zunächst fügen wir einen Winforms-Dialog hinzu der für die Eingabe des Wertes dient.
clip_image010[4]

2.)   Im Code definieren wir ein public field über das wir die Anzahl übergeben bzw. auslesen können.

public partial class CheckinCommentLengthConfigDialog : Form

{

    public int MinimumCommentLength;

 

    public CheckinCommentLengthConfigDialog()

    {

        InitializeComponent();

    }

 

    private void btnOK_Click(object sender, EventArgs e)

    {

        MinimumCommentLength = (int)this.numericUpDown1.Value;

    }

 

    private void CheckinCommentLengthConfigDialog_Load(object sender, EventArgs e)

    {

        this.numericUpDown1.Value = MinimumCommentLength;

    }

}

3.)   Im Code unserer Policy fügen wir ein private field hinzu in dem wir den Wert speichern können und verwenden diesen in unserer Evaluate Methode. Zusätzlich geben wir im Property CanEdit den Wert true zurück. Und wir implementieren die Edit-Methode so, dass hier unser Formular aufgerufen wird:

public override bool Edit(IPolicyEditArgs policyEditArgs)

{

    using (CheckinCommentLengthConfigDialog dialog = new CheckinCommentLengthConfigDialog())

    {

        dialog.MinimumCommentLength = minimumCommentLength;

        if (dialog.ShowDialog() == DialogResult.OK)

        {

            minimumCommentLength = dialog.MinimumCommentLength;

            return true;

        }

        return false;

    }

}

 

public override bool CanEdit

{

    get

    {

        return true;

    }

}

4.)   Nach dem Kompilieren können wir dann die DLL an den Ort kopieren den wir in der Registry eingetragen haben (bei mir c:\temp). Damit diese Date überschrieben werden kann, müssen wir Visual Studio beenden. Nun können wir für unsere Policy den Edit-Dialog aufrufen:

clip_image012[4]

 

Verbessertes Deployment der Policy

Nun wollen wir das Deployment unserer Policy nov vereinfachen. Aktuell wäre es so, dass auf jedem Rechner auf dem die Policy geprüft werden soll die DLL kopiert und der entsprechende Registry-Eintrag vorgenommen werden muss. Das ist natürlich nicht besonders elegant. Wir müssen die Policy zwar auf jedem Rechner installieren, da sonst die Policy immer als verletzt gilt, aber die Installation können wir durch den Einsatz von VSIX deutlich einfacher machen.

 

1.)   Zunächst müssen wir das Visual Studio SDK herunterladen und installieren. Der Download für die SP1-Version befindet sich unter http://www.microsoft.com/downloads/en/details.aspx?FamilyID=21307C23-F0FF-4EF2-A0A4-DCA54DDB1E21

2.)   Dann fügen wir ein neues Projekt zu unserer Solution hinzu und wählen die Vorlage VSIX Project

clip_image014[4]

 

3.)   Im Manifest des VSIX Projektes tragen wir nun die entsprechenden Werte ein und fügen unser Policy-Projekt als MEF Component im Bereich Content hinzu.

clip_image016[4]

 

4.)   Damit unser Eintrag in der Registry noch hinzugefügt wird, fügen wir noch eine Text-Datei mit dem Namen „Policies.pkgdef“ hinzu und schreiben dort folgenden Inhalt rein:

[$RootKey$\TeamFoundation\SourceControl\Checkin Policies]

"artisoCheckinPolicies"="$PackageFolder$\artisoCheckinPolicies.dll"

 

5.)   Wichtig ist noch, dass wir bei der pkgdef-Datei in den Eigenschaften „Include in VSIX“ auf True stellen.

clip_image018[4]

 

6.)   Nun kompilieren wir unsere Solution. Wenn alles fehlerfrei erstellt wird, bereinigen wir zunächst unsere manuellen Einstellungen, d.h. wir entfernen zunächst die Policy auf unserem Team-Projekt. Anschließen löschen wir die DLL und die Registry-Einträge die wir im ersten Teil angelegt haben. Dazu müssen wir zuvor Visual Studio wieder beenden. Nach dem Entfernen sollte die Policy in der Liste der verfügbaren Checkin Policies nicht mehr erscheinen. Aus dem Output unseres Setup-Projektes können wir nun die vsix-Datei starten und die Policy installieren.

clip_image020[4]

 

7.)   Danach sollte sich die Policy genauso aktivieren lassen wie zuvor.

Tuesday, September 13, 2011 12:30:13 AM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [2] -
Team System Server | TFS 2010 | TFS API | VS 2010
# Friday, August 26, 2011

Das Lab Management des Team Foundation Servers eignet sich besonders gut um darin Coded UI Tests automatisiert im Rahmen eines Builds auszuführen. Der Build setzt die VM dabei auf einen Snapshot zurück, deployed die Applikation dann in die VM und führt dann die CUIT aus. Wie das Ganze funktioniert habe ich in einem Webcast beschrieben (http://www.microsoft.com/germany/msdn/webcasts/library.aspx?id=1032476976).

Dabei kann allerdings nun ein Problem auftreten. Der Test meldet bei der Ausführung:

“Automation engine is unable to playback the test because it is not able to interact with the desktop.  This could happen if the computer running the test is locked or it’s remote session window is minimized.”

Das Problem besteht darin, dass der CUIT eine interaktive Desktop Session benötigt um darin ausgeführt werden zu können. Als ich mich mit dem Environment Viewer auf die Environment verbunden habe, konnte ich feststellen, dass die VM beim Anmeldebildschirm stand. Das hatte ich nicht erwartet das die VM mit einem Autologon versehen war und ich den Snapshot auch im angemeldeten Zustand erstellt habe. ich hätte also erwartet, dass die VM nach einem Restore des Snapshots auch wieder angemeldet ist und der Test problemlos laufen kann.

Um die Ursache des Problems zu erläutern müssen wir etwas tiefer einsteigen. Der Environmen Viewer hat 2 Betriebs-Modi. Einmal Host-based und einmal Guest-based. Der aktuelle Modus wird rechts unten im Environment Viewr angezeigt

image

Host-based ist dabei die Verbindungsart bei der der Environment Viewer über den Hyper-V Host auf die VM zugreift. Dieser Modus erlaubt es auch mit der VM zu interagieren wenn diese noch gar nicht komplett hochgefahren ist, z.B. um aus dem Boot-Menü einen Eintrag zu wählen.

Guest-based ist eine normale RDP (Remote Desktop Protocol) Verbindung. Dafür muss die VM bereits hochgefahren sein. Guest-based Verbindungen sind etwas performanter und erlauben auch zusätzliche Features wie z.B. den Austausch von daten über die Zwischenablage.

Host-based wird dann verwendet wenn:

1.) Der client der den Environment Viewer ausführt als Betriebssystem mindestens Windows XP SP3, Windows Visua SP1, Windows 7 oder Windows Server 2008 ausführt und
2.) Der Benutzer der den Environment Viewer ausführt auch der Ownder der Environment ist

image

Weitere Informationen zu den verschiedenen Connection Types finden sich unter http://msdn.microsoft.com/en-us/library/ee518907.aspx.

Zurück zu dem obenen beschriebenen Problem. Der Build funktioniert nur dann, wenn der Snapshot auf den der Build zurücksetzt im Host-based Modus erstellt wurde. Andernfalls bekommt man auch in der Build Definition bei der Auswahl des Snapshots einen entsprechenden Hinweis.

image

Zu beachten ist allerdings, dass dieser Hinweis nur an dieser Stelle kommt, d.h. wenn man den Wizard des Lab BuildProcessTemplates anzeigt oder bei der Ausführung bekommt man keinen Hinweis mehr. Problem bei mir war, dass ich den Snapshot initial im Host-based Modus erstellt hatte und damit den Build angelegt habe. Anschließend habe ich den Snapshot aber gelöscht und neu angelegt und nun war ich im Guest-based Modus.

Problem-Lösung:

Wie lösen wir nun also dieses Problem? Es gibt zwei Möglichkeiten:

1.) Wir erstellen die Snapshots immer im Host-based Modus. Dazu müssen wir im Environment Viewer mit dem Benutzer angemeldet sein der auch der Owner der Environment ist. Wie man den Owner einer Environment ändert ist hier beschrieben: http://blogs.msdn.com/b/lab_management/archive/2010/11/08/enabling-host-based-connection-for-virtual-environments.aspx

2.) Wir verwenden einen Snapshot der im nicht gebooteten Zustand der VM erstellt wird. Der Build startet die VM dann automatisch und die VM nutzt einen Autologon um sich anzumelden. Damit kann der CUIT nun auch ausgeführt werden.

Friday, August 26, 2011 12:28:13 PM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
Lab Management | Team System Server | Testing | TFS 2010 | VS 2010
# Wednesday, June 22, 2011

Es gibt häufiger die Situation, dass man die Url des Team Project Portals eines TeamProjects per API ermitteln möchte um beispielsweise im zugehörigen Portal Dokumente zu generieren oder abzulegen etc. Hier kann man natürlich versuchen sich die Url aus Server-URL, Project Collection Name und Project Name zusammenzubauen, also http://<servername>/sites/<ProjectCollection>/<TeamProject>. Problem ist, dass die Url frei konfiguriert werden kann und von diesem Default-Wert abweichen kann.

Mein Szenario ist, dass ich ausgehend von einem Work Item die Url des Projekt Portals ermitteln möchte um für das Work Item ein entsprechendes Dokument anzulegen. Das Projekt zum Work Item lässt sich einfach ermitteln mit myWorkItem.Project aber auf dem Projekt sucht man vergeblich nach einer Eigenschaft für das Portal. Der Zugriff darauf istt leider ein wenig komplizierter. Die einzige Möglichkeit die Prortal Url zu ermitteln geht über den TFS Catalog. Der Code sieht dann so aus:

  1. private static string GetProjectPortalUrl(WorkItem wi)
  2. {
  3.     // Get the CatalogeNode representing the ProjectCollection the work item is assigned to
  4.     CatalogNode projectCollectionNode = wi.Store.TeamProjectCollection.CatalogNode;
  5.  
  6.     // Getting the CatalogNode represeting the TeamProject by querying for the project name
  7.     CatalogNode projectNode = projectCollectionNode.QueryChildren(
  8.            new Guid[] { CatalogResourceTypes.TeamProject },
  9.            new List<KeyValuePair<string, string>> { new KeyValuePair<string, string>("ProjectName", wi.Project.Name) },
  10.            true,
  11.            CatalogQueryOptions.None)[0];
  12.  
  13.     // Querying for the ProjectPortal
  14.     ReadOnlyCollection<CatalogNode> PortalNodes = projectNode.QueryChildren(
  15.            new Guid[] { CatalogResourceTypes.ProjectPortal },
  16.            true,
  17.            CatalogQueryOptions.None);
  18.  
  19.     // If the ProjectPortal is set, return the Url, otherwise return an empty string
  20.     if (PortalNodes.Count > 0)
  21.     {
  22.         return PortalNodes[0].Resource.Properties["FullyQualifiedUrl"];
  23.     }
  24.     return "";
  25. }

Wir ermitteln zunächst den CatalogNode für die Project Collection unseres Work Items. Davon ausgehend ermitteln wir dann den Knoten für das Projekt mit Hilfe des Projektnamens den wir von dem Work Item lesen. Vom Projekt aus können wir nun den Project Portal Knoten ermitteln der die Url beinhaltet.

Wednesday, June 22, 2011 10:52:04 PM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
Team System Server | TFS 2010 | TFS API
# Monday, May 09, 2011

image

Auf der dotnet Cologne war ich dieses Jahr mit 2 Vorträgen vertreten, einmal mit dem TFS 2010 Quickstart wo ich innerhalb des Vortrags in einer Stunde live einen TFS installiert, die Versionsverwaltung und den Build eingerichtet, Requirements und Test Cases angelegt, Testfälle spezifiziert und ausgeführt, Bugs angelegt und die Traceability demonstriert. Im zweiten Vortrag habe ich verschiedene Best Practices zu SCRUM vorgestellt und die Umsetzung mit TFS vorgestellt. Es war wieder eine tolle Konferenz, vielen Dank an das Orga-Team.

Wer sich nochmals die Folien anschauen mag, hier sind die Links zum Download. Wenn es nachträglich noch Fragen gibt, dann könnt ihreuch gerne per Mail an mich wenden.

Monday, May 09, 2011 12:49:42 AM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
Scrum | TFS 2010 | Vorträge
# Tuesday, March 15, 2011

Es gibt verschiedene Situationen in denen man nachträglich Reports oder SharePoint Dokumente nachträglich für ein bestehendes Team Project einrichten möchte, z.B. nach einer Migration von einer älteren TFS Version oder wenn das Projekt ohne Reports oder SharePoint Portal angelegt wurde. Dafür gibt es bei den Team Foundation Server Power Tools die Befehle

  • tfpt addprojectportal   Add or move portal for an existing team project
  • tfpt addprojectreports  Add or overwrite reports for an existing team project

Mit dieser Methode hatte ich aber bereits mehrfach Probleme und die Einstellungen sind auch nicht so feingranular möglich. Deshalb möchte ich hier eine andere Methode beschreiben. Hierzu legt man zunächst eine XML-Datei an. Für die SharePoint-Dokumente sieht die XML-Datei folgendermaßen aus:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="ProjectCreationSettingsFileSchema.xsd">
<TFSName>http://vs2010:8080/tfs/sandbox</TFSName>
<LogFolder>c:\Temp\</LogFolder>
<ProjectName>VS2010_Demos</ProjectName>
<AddFeaturesToExistingProject>true</AddFeaturesToExistingProject>
<ProjectSiteEnabled>true</ProjectSiteEnabled>
<ProjectSiteWebApplication>VS2010</ProjectSiteWebApplication>
<ProjectSitePath>/sites/sandbox/vs2010_demos/</ProjectSitePath>
<ProjectSiteTitle>VS2010 Demos</ProjectSiteTitle>
<ProjectSiteDescription>Demo</ProjectSiteDescription>
<ProcessTemplateName>MSF for Agile Software Development v5.0</ProcessTemplateName>
</Project>
 
Für die Reports hat die Datei folgenden Aufbau:
 
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="ProjectCreationSettingsFileSchema.xsd">
<TFSName>http://vs2010:8080/tfs/sandbox</TFSName>
<LogFolder>c:\temp</LogFolder>
<ProjectName>VS2010_Demos</ProjectName>
<AddFeaturesToExistingProject>true</AddFeaturesToExistingProject>
<ProjectReportsEnabled>true</ProjectReportsEnabled>
<ProjectReportsForceUpload>true</ProjectReportsForceUpload>
<ProjectSiteEnabled>false</ProjectSiteEnabled>
<ProcessTemplateName>MSF for Agile Software Development v5.0</ProcessTemplateName>
</Project>


Die Parameter sollten weitgehend selbsterklärend sein, eine weitere Beschreibung finden sich hier. Diese XML-Dateien können nun ausgeführt werden indem im Command-Window innerhalb von Visual Studio der Befehl

File.BatchNewTeamProject <XML-Datei>

Der Import wird damit angestoßen. Zu beachten ist, dass der Vorgang eine Weile dauern kann. Den Erfolg des Imports kann man in der Log-Datei im angegebenen Ordner überprüfen.

Tuesday, March 15, 2011 2:47:51 AM (Mitteleuropäische Zeit, UTC+01:00)  #    Comments [0] -
Team System Server | TFS 2010 | VS 2010
# Tuesday, February 22, 2011

Bei verschiedenen Diagrammtypen, z.B. stacked Areas möchte man das Diagramm am Ende gerade abschneiden und nicht zunächst noch einen 0-Wert anzeigen.

Also statt der Schräge am Ende des Diagramms (zum 23.02 liegen keine Werte vor)

image

hätte man das lieber sauber abgeschnitten um zu signalisieren, dass die letzten gültigen Werte vom 22.02 sind.

image

Dies kann man mit Reporting Services Diagrammen relativ einfach erreichen. Zunächst ist wichtig, dass für die Werte ab 23.02 nicht 0 sondern Null bzw. Nothing (für Expressions) als Ergebnis zurückgegeben wird. Dies kann man im Query Designer kontrollieren

image

Dann muss man in den Properties der Serie noch in den EmptyPoint Einstellungen die Farbe auf “No Color” stellen, d.h. dass leere Datenpunkte nicht gezeichnet werden.

image

Und schon hat man das gewünschte Ergebnis.

Tuesday, February 22, 2011 10:21:32 PM (Mitteleuropäische Zeit, UTC+01:00)  #    Comments [0] -
Team System Server | TFS 2010
# Monday, January 17, 2011

Allen Clark hat auf der MSDN Code Gallery Schema Files für die TFS Work Item Type Definition veröffentlicht. Damit bekommt man nun IntelliSense Support und Validierung beim Bearbeiten der XML-Dateien. War kann man über den Process Template Editor der TFS Power Tools ohne direkte XML-Bearbeitung die Work Item Type Definitions über einen grafischen Editor anpassen, jedoch gibt es eine ganze Reihe von Situationen wo das Bearbeiten im XML schneller geht oder einfach nicht zu vermeiden ist. Mit den Schema-Files wird dies nun deutlich angenehmer.

Link zur Code Gallery: http://code.msdn.microsoft.com/TFSchemas

Monday, January 17, 2011 9:19:00 AM (Mitteleuropäische Zeit, UTC+01:00)  #    Comments [0] -
Team System Server | TFS 2010 | VS 2010
# Saturday, January 15, 2011

Das MSF for Agile Template kommt mit einer vorgefertigten Excel-Datei für ein Interations- bzw. Sprint-Backlog. Diese liegt im SharePoint unter Shared Documents\Iteration 1\Iteration Backlog.xlsm.

image

Beim Öffnen der Datei kam es bei mir alledings zu Fehlern:

---------------------------
Microsoft Excel
---------------------------
TF80076: The data in the work item is not valid or you do not have permissions to modify the data. Please correct the problem and retry.
---------------------------
OK  
---------------------------

und

---------------------------
Microsoft Excel
---------------------------
TF208103: The initialization of the workbook to connect to Team Foundation Server was not successful. The workbook will close. You can try to connect again by re-opening the workbook.

If repeated attempts fail to initialize the workbook and you need to work with the data in the workbook, then you should disable the Team Foundation add-in. For new or other workbooks with lists bound to Team Foundation Server, you will need to re-enable the Team Foundation add-in.
---------------------------
OK  
---------------------------


Das Problem liegt darin, dass ich bei mir die Iterationen umbennant habe und das Dokument damit nun nicht mehr zurecht kommt. Es gibt aber einen relativ einfachen Workaround dafür:

  1. Zunächst muss man dafür sorgen, dass es wieder einer Iteration “\Iteration 1” gibt. Diese kann man entweder temporär anlegen oder eine bestehende umbenennen.
  2. Jetzt lässt sich die Datei ohne Fehler öffnen
  3. Dann wechselt man auf das Sheet “Settings”
  4. Hier wählt man im Bereich Area & Iteration eine gültige Iteration aus, z.B. \ oder eine der anderen gültigen Iterationen.
    Achtung: In der Liste werden nur Iterationen erlaubt die in dem Sheet “Iteration Backlog” in der Spalte “Iteration Path” vorkommen. Evtl. muss zuvor die Query “Team Queries\Iteration 1\Iteration Backlog” angepasst und hier die entsprechende Iteration als Filter eingestellt werden. Dann kann mit dem Refresh-Button auf dem team Tab im Excel die Liste aktualisiert werden.
    image
  5. Danach speichert man die Excel-Datei
  6. Nun kann die temporär angelegte Iteration gelöscht werden oder die Iteration wieder umbenannt werden. Das Excel-Dokument lässt sich nun ohne Fehler öffnen.
Saturday, January 15, 2011 3:59:43 PM (Mitteleuropäische Zeit, UTC+01:00)  #    Comments [0] -
Team System Server | TFS 2010 | VS 2010
# Sunday, November 21, 2010

Mit dem Team Foundation Build ist es einfach, Tests im Rahmen von automatisierten Builds auszuführen. Standardmäßig werden die Tests jedoch auf dem Buildrechner selbst ausgeführt. Das ist in verschiedenen Szenarien jedoch nicht erwünscht, sondern man möchte die Tests in einer Referenzumgebung ausführen die der Zielumgebung, in der die Anwendung ausgeführt werden soll, möglichst nahe kommt. Vor allem für GUI-Tests ist dieses Szenario wichtig.

image

Mit Visual Studio 2010 gibt es dafür LabManagement um virtualisierte Testumgebungen bereitzustellen und über ein vorbereitetes Build Template Tests darin auszuführen. Jedoch lässt sich diese Funktion auch ohne LabManagement erreichen, z.B. wenn ein anderes Virtualisierungssystem als Hyper-V oder rein physikalische Testumgebungen eingesetzt werden sollen. Im Folgenden soll beschrieben werden, wie dieses Szenario einzurichten ist.

Hierzu muss zunächst ein Testcontroller eingerichtet werden. Dieser kann beispielsweise auf dem TFS Server installiert werden. Auf der Testmaschine muss anschließend ein Testagent installiert und auf den Testcontroller registriert werden. Weitere Hinweise zur Installation und Konfiguration von Testcontrollern und –agents finden sie unter http://msdn.microsoft.com/de-de/library/dd648127.aspx. Es sollte beachtet werden, dass der Test Agent als interaktiver Prozess konfiguriert sein muss, wenn UI-Tests auf der Testmaschine ausgeführt werden sollen. Und der Testagent muss auf dem Testcontroller registriert  sein.

image

image

Der Testcontroller darf nicht für ein Teamprojekt registriert sein.

image

Anschließend können wir einen Build für das gewünschte Projekt einrichten. Der Build soll in unserem Szenario auf einem separaten Buildcomputer ausgeführt werden. Um das Deployment des Buildergebnisses auf die Testmaschine zu bewerkstelligen, passen wir das Buildtemplate ein wenig an. Dazu legen wir zunächst 2 neue Arguments an. Anschließend Platzieren wir unterhalb der „If BuildSettings.HasProjectToBuild“ Activity eine If-Condition auf der wir auf das Argument DeployForTest prüfen. Im Then-Zweig fügen wir dann eine CopyDirectory-Activity ein für die wir als Source die Droplocation und als Destination das Argument DeployForTestTarget einstellen. Damit wird unser Buildergebnis in dan Verzeichnis kopiert das wir in unserer Build Definition einstellen können.

2010-11-22_2207

Das BuildTemplate können wir nun unter einem neuen Namen speichern und einchecken. Auf dieser Basis erstellen wir nun mal einen ersten Build. In den Process Einstellungen definieren wir nun, dass das Deployment auf die Testmaschine ausgeführt werden soll und wir geben den UNC-Pfad an wohin die Dateien deployed werden sollen.

image

Nach dem Ausführen des Builds können wir prüfen, ob die Dateien korrekt auf die Testmaschine deployed wurden. Die Tests die wir in unserem Projekt haben werden allerdings immer noch auf unserer Buildmaschine ausgeführt. Um das zu ändern, müssen wir die Testsettings anpassen. Unter Test / Edit Test Settings  wählen wir zunächst Local aus um diese Einstellung anzupassen.

image

Hier müssen wir Remote Execution einstelle und den entsprechenden Build Controller auswählen. Diese Einstellungen können wir dann unter einem neuen Namen abspeichern und einchecken.

Anschließend wählen wir diese Test Settings in unserem Build aus.

image
image

Damit werden unsere Tests die wir in der Solution definiert haben nun auf unserer Testmaschine ausgeführt. Dies können sowohl Unit-Tests als auch Coded UI Tests sein. Als erweitertes Szenario können z.B. im Rahmen des Build Setups erstellt werden die dann über die CopyDirectory Activity auf die Testmaschine kopiert werden. Dann kann mit Hilfe eines Coded UI Tests das Setup ausgeführt und anschließend die Funktionen der Anwendung getestet werden.

Ein wichtiger Punkt ist noch, dass wir aktuell nicht kontrollieren können, auf welchem Testcomputer die Tests ausgeführt werden, wenn wir auf dem Testcontroller mehrere Agents registriert haben. Das wollen wir nun noch ändern. Dazu wählen wir unter Test / Manage Test Controllers unseren Testcontroller und den entsprechenden Agent aus.

image

Über Properties können wir dem Agent nun Attribute zuordnen, z.B. ein MachineName.

image

Nun können wir in unseren Testsettings einstellen auf welchem Agent unsere Tests ausgeführt werden sollen. Dazu fügen wir erst eine Rolle hinzu und wählen aus, dass auf dieser Rolle Tests ausgeführt werden können. Nun Geben wir das zuvor definierte Attribut mit dem selben Wert an.

image

Nun können wir eindeutig steuern, wo die Ausführung der Tests erfolgen soll und wir können beispielsweise mehrere Testcomputer mit verschiedenen Betriebssystemen zur Ausführung der Tests nutzen.

Sunday, November 21, 2010 11:32:09 PM (Mitteleuropäische Zeit, UTC+01:00)  #    Comments [0] -
Team System Server | Testing | TFS 2010 | VS 2010
# Thursday, October 21, 2010

Sehr viele Software-Projekte nutzen Datenbanken und damit stellt sich die Frage, wie kann die Datenbank im Build so aufbereiten, dass sie für Tests deployed werden kann. Hierzu gibt es auf MSDN eine sehr gute Artiekelserie die Beschreibt wie mit den Datenbankfunktionen im Visual Studio 2010 Datenbanken verwaltet und im Build für Tests deployed werden kann.

http://msdn.microsoft.com/en-us/library/dd193413.aspx

Speziell die Schritt für Schritt Anleitung zur Anpassung des Build Workflows möchte ich empfehlen.

http://msdn.microsoft.com/en-us/library/ff805001.aspx

Thursday, October 21, 2010 12:27:32 AM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
TFS 2010 | VS 2010
# Wednesday, October 20, 2010

Der einfachste Weg, um Daten aus dem OLAP Cube im TFS Warehause auszuwerten ist über Excel. Wie dies funktioniert, soll im Folgenden kurz beschrieben werden:

Zunächst müssen dem entsprechenden Benutzer Berechtigungen für den OLAP-Cube eingerichtet werden. Dazu verbindet man sich im Management Studio zu den Analysis Services.

image

Unter dem Cube im Ordner Roles findet sich dann die Rolle TfsWarehouseDataReader

image

Hier kann man nun unter Memberschip die entsprechenden Benutzer eintragen

image

In Excel kann man nun eine Verbindung zum Cube herstellen. Dazu ruft man im Data-Tab die Verbindung zu den Analysis Services auf.

image

Im folgenden Dialog gibt man nun die Verbindungsdaten ein. Soll der Zugriff auf eine bennante Instanz erfolgen, muss diese angegeben werden, z.B. mySQLServer\MyInstance.

image

Dann wählt man entweder den Cube oder eine Perspektive aus

image

Die Verbindung kann man nun speichern. Sie steht dann unter Existing Connections für weitere Anwendungen zur Verfügung.

image

Im nächsten Schritt kann man eine Pivot Table in das bestehende Excel Workbook einfügen.

image

Im rechten Bereich kann man nun Felder in die Bereiche für Filter, Spalten, Zeilen oder Werte ziehen. Die Felder lassen sich dabei nach verschiedenen Kategorien über die oberste Dropdownlist filtern.

image

In einem späteren Post werde ich beschreiben, wie man mit Hilfe der Pivot Tables entsprechende Auswertungen auf dem Cube erstellt.

Wednesday, October 20, 2010 9:47:36 AM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
SQL | Team System Server | TFS 2010
# Tuesday, October 12, 2010

Beim starten einer Environment im Microsoft Lab Management dauert es meist geraume Zeit, bis die Workflow capabilities bereit zur Ausführung sind.

image

Will man diese Zeit reduzieren, ist ein einfaches Mittel in den VMs das IPv6 Protokoll auf den Netzwerkkarten zu reduzieren. Bei mir hat das die Wartezeit für die Workflow capabilities von 2:44 Min auf 0:40 Min reduziert.

Tuesday, October 12, 2010 9:45:40 PM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
Team System Server | Testing | TFS 2010 | VS 2010
# Tuesday, September 28, 2010

Microsoft schließt eine Sicherheitslücke im ASP.Net durch ein Out-of-Band-Ipdate. Da der TFS komplett auf ASP.Net basiert, ist au der TFS von dieser Sicherheitslücke betroffen und wer auf der sicheren Seite sein möchte sollte den nun verfügbaren Patch installieren.

Weitere Details und die Download-Links gibt es auf TechNet unter http://blogs.technet.com/b/michaelkranawetter/archive/2010/09/28/update-out-of-band-updates-f-252-r-asp-net-l-252-cke-verf-252-gbar.aspx

Tuesday, September 28, 2010 9:13:19 PM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
Team System Server | TFS 2010

Wenn das TFS Dashboard zu lange braucht um angezeigt zu werden, dann kann ein Grund dafür das “Recent Builds Webpart” sein. Dieses hat offensichtlich noch einen Bug und liest zu viele Informationen vom TFS. Wird die Anzahl der Builds zu hoch, dann hat das Webpart einen sehr deutlichen Einfluss auf die Performance des Dashboards, insbesondere beim erstmaligen Laden.

Microsoft hat das als Bug identifiziert und verspricht mit dem SP1 Abhilfe zu schaffen. Im Moment hilft leider nur, entweder das WebPart vom Dashboard zu entfernen oder die Build-Historie regelmäßig zu löschen.

Tuesday, September 28, 2010 8:29:56 AM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
Team System Server | TFS 2010
# Sunday, August 08, 2010

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.

image

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

image

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.

image

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.

image

Dazu stellen wir auf dem Feld Repro Steps eine WHEN-Regel ein

image

image

Und sagen wenn diese Bedingung erfüllt ist, dann soll das Feld ein Pflichtfeld sein

image

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.

image

image

Dazu definieren wir für das Feld Team das wir zuvor hinzugefügt haben 2 When-Regeln

image

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.

image

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.

Sunday, August 08, 2010 6:32:18 PM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
Team System Server | TFS 2010 | VS 2010

Tritt beim Konfigurieren eines Labs das in einer Workgroup betrieben wird (keine Domänenintegration der VMs) folgender Fehler auf, dann fehlt ggf. ein Shadow-Account: 

image

 

--------------------------------------------------

Environment message: Type=Warning; Message=TF267042: One or more machines are not ready to run tests. For more information, see the individual machine errors.;

Machine messages:

Machine name: Windows 7 x64 en

Machine message: Type=Error; Message=TF267055: The machine is not ready to run tests because of the following error: Unable to connect to the controller on ---. The agent can connect to the controller but the controller cannot connect to the agent because of following reason: The server has rejected the client credentials.
The logon attempt failed.;

--------------------------------------------------

Damit der Testagent mit dem Testcontroller korrekt zusammenarbeitet, müssen beide mit unterschiedlichen Accounts laufen. Der Testcontroller verwendet dabei typischerweise einen Domänen-Account, der Testagent arbeitet mit einem lokalen Account. Die jeweiligen Accounts müssen als Shadow-Accounts (gleicher Name und Kennwort) lokal bzw. in der Domäne angelegt werden, also für den lokalen Account ein Shadow-Account in der Domäne und für den Domänen-Account ein lokaler Shadow-Account.

 

Beispiel:

 

  Account Shadow-Account
Testagent labmachine\Labuser domain\Labuser
TestController domain\TestController labmachine\TestController

Die oben beschriebene Meldung erhält man, wenn auf der Labmaschine kein lokaler Shadow-Account angelegt wurde. Wenn man das nachholt und dann auf “Repaiur testing capabilities” klickt, dann sollte das Problem behoben sein.

image

Sunday, August 08, 2010 5:06:41 PM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
Lab Management | TFS 2010 | VS 2010
# Tuesday, July 20, 2010

Das Processtemplate für Scrum gab’s von Microsoft bereits als Beta, nun wurde die endgültige Version auf der Visual Studio Gallery veröffentlicht.

Folgende Elemente enthält das Template:

  • Work Item Types
    • Sprint
    • Product Backlog Item
    • Bug
    • Task
    • Impediment
    • Test Case
  • Reports
    • Release Burndown
    • Velocity
    • Sprint Burndown
    • Build Success Over Time
    • Build Summary
    • Test Case Readiness
    • Test Plan Progress
  • SharePoint Project Portal

Hier noch Screenshots zum Sprint Burndown und Release Burndown Report.

Download

http://visualstudiogallery.msdn.microsoft.com/en-us/59ac03e3-df99-4776-be39-1917cbfc5d8e

Weitere Informationen zum Template
http://blogs.msdn.com/b/aaronbjork/archive/2010/07/19/announcing-microsoft-visual-studio-scrum-1-0.aspx

Tuesday, July 20, 2010 8:17:11 PM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
Team System Server | TFS 2010 | VS 2010
# Tuesday, June 29, 2010

Endlich ist es soweit und Microsoft stellt ein VM Image für Visual Studio 2010 und TFS 2010 in der RTM Version bereit. Auf diesem Image sind nicht nur die Produkte sowie einige weitere benötigten Tools installiert, sondern es befinden sich darauf auch Demo-Daten (Tailspin Toys) und 9 Hands-On-Labs. Die VM ist für Hyper-V, Virtual PC 2007 SP1 verfügbar. Die Trial-Versionen auf der VM laufen bis zum 15. Dezember 2010.

Weitere Infos und Hinweise zum Download finden sich hier: http://blogs.msdn.com/b/briankel/archive/2010/06/25/now-available-visual-studio-2010-rtm-virtual-machine-with-sample-data-and-hands-on-labs.aspx

Tuesday, June 29, 2010 3:39:17 PM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
Team System Server | TFS 2010 | VS 2010
# Saturday, June 26, 2010

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>

Saturday, June 26, 2010 1:11:34 PM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
Team System Server | TFS 2010 | VS 2010
# Wednesday, June 09, 2010

Kurzbeschreibung: Dieser Artikel beschreibt, wie Parameter an Reports über die URL übergeben werden können um so über Links oder im SharePoint Dashboard Reports bereits mit voreingestellten Parametern aufzurufen und so z.B. den Burndown eines spezifischen Sprints zu erhalten ohne die Parameter jedesmal von Hand einstellen zu müssen.

Im Team Foundation Server werden sie SQl Server Reporting Services (SSRS) genutzt um Reports zu generieren. Diese Reports geben schnell Auskunft über den aktuellen Status eines Projektes. Ein gutes Beispiel für einen solchen Report ist ein Burndown-Chart:

image

Solche Reports können sehr einfach aus dem SharePoint Portal oder aus dem TeamExplorer aufgerufen werden.

image

Nachteil an dieser Methode ist, dass bei jedem Aufruf die entsprechenden Parameter eingestellt werden müssen oder das Report Template immer an den aktuellen Sprint angepasst werden muss. Glücklicherweise unterstützen die SSRS die Übergabe von Parametern in der URL, so dass man sich sehr einfach Links generieren kann die den Report bereits vorkonfigurieren. Hierzu ruft man folgende URL auf:

http://<Reportserver URL oder IP>/ReportServer/Pages/ReportViewer.aspx?%2fTfsReports%2f<Project Collection Name>%2f<Tem Project Name>%2f<Ordner>%2f<Report Name>&rs%3aCommand=Render

In meinem Fall sieht das so aus:

http://myReportServer/ReportServer/Pages/ReportViewer.aspx?%2fTfsReports%2fartisoProjects%2fReportingDemo%2fProject+Management%2fBurndown+and+Burn+Rate&rs%3aCommand=Render

Damit können wir zunächst mal den Report direkt aufrufen. Nun können wir noch ein paar Parameter übergeben. Dazu müssen wir wissen wie die Parameter heißen. Dies kann man am einfachsten rausfinden indem man den Report über das SSRS Frontend aufruft und zwar über

http://<Reportserver URL oder IP>/Reports

und dann zu dem entsprechenden Report navigiert.  Die Seite die man nun erhält sieht ungefähr so aus:

image

Unter Eigenschaften / Parameter werden nun alle Parameter mit ihrem Namen angezeigt:

image

Wir wollen nun z.B. das Start- und Enddatum in unserer URL setzen. Dazu ergänzen wir die URL von oben einfach:

http://myReportServer/ReportServer/Pages/ReportViewer.aspx?%2fTfsReports%2fartisoProjects%2fReportingDemo%2fProject+Management%2fBurndown+and+Burn+Rate&rs%3aCommand=Render&StartDateParam=28.05.2010&EndDateParam=10.06.2010

Damit wird bereits das Start- und Endedatum korrekt gesetzt. Nun wollen wir noch die Iteration setzen. Hier ist die Geschichte nicht ganz so trivial, da der TFS recht kryptische Angaben zum Iteration-Pfad erwartet. Das liegt daran, dass das Warehouse Daten aus mehreren Project Collections enthält und vor allem bei einem Rebuild die IDs unverändert bleiben sollen. Diesen Parameter kann man auf verschiedene Arten ermitteln, der mit dem geringsten Vorbereitungsaufwand soll hier kurz beschrieben werden.

Dazu ruft man zunächst das SQL Server Management Studio auf und verbindet sich zu den Analysis Services. Hier erstellt man nun eine neue MDX-Query.

image

Dann wählt man im Feld “Cube” den Eintrag “Work Item” aus und geht im Baum unter Work Item \ Work Item.Iteration Hierarchy \ Iteration<n> wobei n die Hierarchieebene ist auf der sich die gesuchte Iteration befindet.

image

Die gewünschte Iteration zieht man nun per Drag & Drop auf die rechte Seite des Fensters und bekommt dort die ID der Iteration.

image

Diese muss jetzt noch URL-Encodiert werden. Dazu kann man beispielsweise den URLEncoder (http://code.msdn.microsoft.com/URLEncoder/Release/ProjectReleases.aspx?ReleaseId=3629) verwenden.

Damit sieht die IterationID nun so aus:
%5BWork%20Item%5D%2E%5BIteration%20Hierarchy%5D%2E%5BIteration1%5D%2E%26%5B%2D6991474436272448184%5D%26%5B%2D8595730757606272101%5D

Diese können wir nun als Parameter in unsere URL einfügen:
http://myReportServer/ReportServer/Pages/ReportViewer.aspx?%2fTfsReports%2fartisoProjects%2fReportingDemo%2fProject+Management%2fBurndown+and+Burn+Rate&rs%3aCommand=Render&StartDateParam=28.05.2010&EndDateParam=10.06.2010&IterationParam=%5BWork%20Item%5D%2E%5BIteration%20Hierarchy%5D%2E%5BIteration1%5D%2E%26%5B%2D6991474436272448184%5D%26%5B%2D8595730757606272101%5D

Damit bekommen wir alle Parameter wie gewünscht befüllt.

image

Über zusätzliche Parameter können wir nun das Parameterfeld und den Toolbar auch noch ausblenden. Dazu fügen wir noch die Kommandos &rc:Parameters=false&rc:toolbar=false an unsere URL an. És gibt noch eine ganze Reihe weiterer Commands, über die z.B. auch das Ausgabeformat gesteuert wreden kann. Eine genauerer Beschreibung der Commands findet sich hier: http://technet.microsoft.com/en-us/library/ms152835.aspx.

Damit können wir nun den Report schon über einen einfachen Link aufrufen. Um den Report in unser SharePoint Dashboard einzubauen sind jetzt nur noch wenige Schritte erforderlich. Dazu fügen wir in unser Dashboard zunächst ein Page Viewer Web Part ein.

image

In der Tool Pane können wir nun die URL für den Report angeben.

image

Damit lassen sich nun schöne Dashboards im SharePoint aufbauen die alle Reports bereits voreingestellt enthalten. Für einen neuen Sprint nutzt man dann die Funktion “Copy Dashboard” und passt die Parameter in den URLs entsprechend an.

image

Weitere Hinweise:

Manche Parameter lassen auch eine Mehrfachselektion zu. Diese können ebenfalls in der URL übergeben werden indem einfach der selbe Parameter mit unterschiedlichen Werten angegeben wird.

Weitere Links:

URL Parameter für SSRS: http://technet.microsoft.com/en-us/library/ms153586.aspx
Viewer Commands: http://technet.microsoft.com/en-us/library/ms152835.aspx
Parameter Prefixes: http://technet.microsoft.com/en-us/library/ms153579.aspx

Wednesday, June 09, 2010 12:08:42 PM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
Team System Server | TFS 2010
# Friday, April 23, 2010

Christian Binder hat einen Deep Zoom zum Thema Testing mit Visual Studio 2010 auf seinem Blog veröffentlicht. Der Deep Zoom erlaubt es aus einer Übersichtsansicht sich tiefer in einzelne Themen hineinzuklicken, bis auf Detaileben. Der Deep Zoom enthält auch Videos die zwar nicht vertont sind aber die einzelnen Teilabläufe anschaulich darstellen. Echn ne coole Sache, also einfach mal selber reinschauen.

Visual Studio 2010 Test Manager Deepzoom

http://blogs.msdn.com/cbinder/archive/2010/04/22/einf-hrung-deepzoom-f-r-den-neuen-visual-studio-2010-test-manager-und-lab-management.aspx

Friday, April 23, 2010 5:18:41 PM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
Qualitätsmanagement | TFS 2010 | VS 2010

In der TFS Adminconsole oder im TFS Configuration Wizard können die Reporting Services für den TFS konfiguriert werden.

 image

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))

image 

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:

  1. Auf dem Reporting Server dcomcnfg.exe starten
  2. Im linken Bereich Console Root\Component Services\Computers\My Computer öffnen
  3. Aus dem Kontextmenü von “My Computer” den Eintrag “Properties” öffnen
    image
  4. Im Bereich “Launch and Activation Permissions” auf “Edit Limits” klicken
  5. Den Benutzer mit “Add hinzufügen und ihm “Remote Launch” und “Remote Activation” vergeben
    image

Anschließend kann der Remote-Zugriff per WMI auf die Reporting Services konfiguriert werden.

  1. Auf dem Reporting Server wmimgmt.msc starten
  2. Im linken Bereich auf WMI Control (Local) aus dem Kontext-Menü “Properties” auswählen
  3. Auf den Reiter Security wechseln und im Baum Root\Microsoft\SqlServer\ReportServer auswählen
    image
  4. Auf den Button “Security” klicken und den gewünschten benutzer mit “Add” einfügen
  5. Dem Benutzer “Enable Account” und “Remote Enable” als Rechte vergeben
    image
  6. Auf “Advanced” clicken, den Benutzer auswählen und dann auf “Edit” klicken
  7. Bei “Apply to” “This namespace and subnamespaces” wählen
    image

Mit diesen Einstellungen sollte nun das “Populate URLs” in der TFS Administration Console funktionieren.

Friday, April 23, 2010 5:00:05 PM (Mitteleuropäische Sommerzeit, UTC+02:00)  #    Comments [0] -
Team System Server | TFS 2010 | VS 2010
Archive
<February 2012>
SunMonTueWedThuFriSat
2930311234
567891011
12131415161718
19202122232425
26272829123
45678910
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2012
Thomas
Sign In
Statistics
Total Posts: 560
This Year: 3
This Month: 1
This Week: 3
Comments: 351
Themes
All Content © 2012, Thomas
DasBlog theme 'Business' created by Christoph De Baene (delarou)