h1

Anpassungsmöglichkeiten des TFS 2013

Juni 11, 2014

Beim Thema Anpassung und Erweiterung des TFS muss man sich immer mit verschiedenen Aspekten auseinandersetzen. So zum Beispiel:

  • “Welche Prozesstemplates gibt es und wo finde ich eine Dokumentation?”
  • “Welche Felder, Stati, Workflows gibt es?”
  • “Was kann ich wann ändern?”
  • “Wie kann ich ein bestehendes Projekt am Prozesstemplate updaten?”
  • “Welche Erweiterungsmöglichkeiten habe ich neben dem Prozesstemplate?”

Dazu habe ich ein paar passende Links gesammelt:

  • MSF for CMMI, MSF for Agile software development und Visual Studio Scrum process template liegen im Moment in Version 2013.2 vor. Eine Field-Reference findet sich hier.
  • Zum Thema Anpassungsmöglichkeiten des TFS im allgemeinen empfehle ich die folgenden Seiten: hier und hier
  • Zum Thema Möglichkeiten die Änderungen nachdem man ein Projekt mit einem bestimmten Template angelegt hat für bestehende Projekte zu übernehmen gibt es hier – eine schöne Gegenüberstellung von Pro und Contra der Varianten.
  • Zum Thema TFS 3rd Party Erweiterung war es eigentlich angedacht dieses Tool zu evaluieren.
  • Ein Videotraining in der Microsoft Virtual Academy zum Thema Anpassung und Erweiterung von TFS 2013 findet man hier.

Viel Spaß beim Anpassen und gerne nehme ich weitere gute Informationen als Kommentar entgegen.

h1

Lange ein Ziel und Traum – MCSD: Application Lifecycle Management

Mai 13, 2014

Lange ein Ziel und Traum und jetzt endlich habe ich den MCSD Application Lifecycle Management erfolgreich abgeschlossen.

MCSD_2013(rgb)_1509

Ich habe ja schon lange den TFS als ein Nebenschauplatz-Hobby für mich entdeckt und nun endlich auch die passende Zertifizierung (mit 3 Prüfungen) abgeschlossen. Schon letztes Jahr konnte ich zum Glück ohne Vorbereitung die 2 Prüfungen zur Administration und Delivering Continuous Value in kurzem Abstand erfolgreich abschließen. Die dritte zum Thema Software Testing hatte ich immer vor mir her geschoben, da die Vorbereitungszeit nie da war und das Thema Testen nicht mein “tägliches Brot” im TFS darstellt. Jetzt konnte ich mich mit dem Thema etwas intensiver vertraut machen und habe noch kräftig hinzugelernt.

Überraschung für mich war die Gültigkeit, denn die Zertifizierung ist nur 2 Jahre aktiv/gültig.

Vorbereitet habe ich mich unter anderem mit folgenden Informationen:

  • 70-496:  Administering Microsoft Visual Studio Team Foundation Server 2012
  • 70-497:   Software Testing with Visual Studio 2012
  • 70-498: Delivering Continuous Value with Visual Studio 2012 Application Lifecycle Management
h1

TFS 2013 WebAccess Funktionen je nach Zugriffs-Berechtigung (Lizenz)

April 17, 2014

Immer wieder kommen Kollegen und fragen, warum sie eine bestimmte Funktion im TFS WebAccess nicht sehen?! Dazu muss man sich ein bisschen mit dem Berechtigungsschema beschäftigen was hinter dem TFS steckt. Im WebAccess ist die einizige Stelle wo es abhängig von der zugeordneten Lizenz auch unterschiedliche Zugriffslevel gibt. Hier gibt es zur Zeit drei verschiedene Level:

  1. Limited – Man kann nur seine eigenen WorkItems sehen (keine TFS CAL notwendig)
  2. Standard (default) – Standardfunktionen, Agile boards, Backlog&sprint planing, Chart viewing (Nutzer mit TFS CAL)
    image
  3. Full – Alle verfügbaren Funktionen (Nutzer mit MSDN Subscription)
    image

Wer in welchem Access Level einsortiert ist findet man auf seinem TFS unter http://<tfsurl&gt;:8080/_admin/_licenses.  Über den “Export audit log” Link wird ein entsprechendes CSV zur Verfügung gestellt was je Account den letzten Zugriff und die eingerichtete Zugriffsberechtigung enthält.

Weitere Informationen findest du hier.

Fazit: Der “Limited” Zugriff kann zum Beispiel für Kunden ohne Lizenz genutzt werden, die über den TFS Webzugriff nur Bugs, Issues o.a einstellen wollen. Der “normale” Softwareentwickler hat in den meisten Fällen eine MSDN Subscription (Visual Studio Ultimate mit MSDN, Visual Studio Premium mit MSDN oder Visual Studio Test Professional mit MSDN) und damit den vollen Zugriff mit allen Funktionen, die er gar nicht unbedingt alle braucht. Der Projektleiter, Anforderungsmanager, … hat in den wenigsten Fällen eine MSDN Subscription und damit nur den Standard-Zugriff. Es fehlen ihm also genau die Funktionen die er am meisten benötigt, wie Feedback Management, Agile Portfolio Management oder Diagrammerstellung… Nutzt der Mitarbeiter ohne Vollzugriff die anderen Möglichkeiten wie Excel, Project, Reporting Services oder Team Explorer für den Zugriff auf den TFS, reicht ihm nach wie vor die TFS CAL um alle von dem jeweiligen Tool angebotenen Funktionen des TFS zu nutzen. Zum Thema Lizenzen und TFS gibt es ein White Paper und auch einige Blogbeiträge….

h1

CodedUI mit TFS Teambuild

April 11, 2014

Es geht darum CodedUI Tests während eines TFS Teambuilds ohne Labmanagement auszuführen. Dazu gibt es eine ganze Reihe Informationen im Netz, trotzdem gibt es ein paar Fallstricke die es nicht einfacher machen. Gerade wenn man nach einer Lösung zum Fehler “Failed to initialize the unit test extension ‚urn:CodedUITest‘: A unit test extension is not registered for the following attribute: Microsoft.VisualStudio.TestTools.UITesting.CodedUITestAttribute” sucht, kommt man nicht so richtig zu einem eindeutigen Ergebnis.

Mit einer vorhandenen VS 2013 Solution mit CodedUI Tests (Class Library mit .Net Framework 4.5 konfiguriert) wurden folgende Konstellationen getestet:

  1. TFS 2012 Update 3/4, TFS Build Controller 2012, Visual Studio 2013.1 Premium, Build Agent als Interaktiver Prozess > Ergebnis: “Failed to initialize the unit test extension ‚urn:CodedUITest‘: A unit test extension is not registered for the following attribute: Microsoft.VisualStudio.TestTools.UITesting.CodedUITestAttribute.”
  2. TFS 2013, TFS Build Controller 2012, Visual Studio 2013.1 Premium/Ultimate Testmanager, Build Agent als Interaktiver Prozess > Ergebnis: “Failed to initialize the unit test extension ‚urn:CodedUITest‘: A unit test extension is not registered for the following attribute: Microsoft.VisualStudio.TestTools.UITesting.CodedUITestAttribute.”
  3. TFS 2013, TFS Build Controller 2013, VS 2013 Ultimate, Testmanager 2013,  Build Agent als Interaktiver Prozess > Ergebnis: Tests laufen
  4. TFS 2013, TFS Build Controller 2013, VS 2013 Premium, Build Agent als Interaktiver Prozess > Ergebnis: Tests laufen

Fazit: CodedUI Tests sollten immer mit der zur TFS-Version passenden Visual Studio Version entwickelt werden. Bei TFS 2012 also Visual Studio 2012 + TFS Build Controller 2012 + Build Agent 2012 mit VS 2012 Premium verwenden. Unsere zur Zeit passende Konstellation ist TFS 2013, TFS Build Controller 2013, Build Agent 2013 (interaktiver Prozess), VS 2013 Premium

h1

Microsoft Visual Studio ALM Days 2011 (ehemals TeamConf)

November 1, 2011

Vom 23.-25. November findet die TeamConf 2011 unter neuem Namen ALM Days in München statt. Wie in den vergangenen Jahren werden hochkarätige Vorträge und Speaker u. a. Sam Guckenheimer (Microsoft) und Brian Harry (Microsoft) vor Ort sein.

Auch wir von der T-Systems Multimedia Solutions GmbH sind mit Vorträgen rund um das Thema ALM vertreten. Sebastian Wagner, Projektleiter und Daniel Kubis, Software Architekt bei der MMS, berichten über Erfahrungen bei der Einführung des TFS 2010 und die Einbindung in die Unternehmensprozesse bei der T-Systems MMS. Daniel Kubis stellt am Technical Day Erfahrungen und Best Practices mit TFS Teambuild und Sebastian Wagner best practices bei der SharePoint Entwicklung mit TFS 2010 vor.

Hier finden Sie die Agenda, das begleitende Workshop-Angebot und das Anmeldungsformular:
www.teamconf.de

h1

TFS 2010 Teambuild | Mythen zum Gated Check-In

September 30, 2011

Ich hatte ja schon vor Tagen einen Artikel über Gated Check-In aus Entwicklersicht geschrieben und versucht ein paar Mythen auszuräumen. Trotzdem kommen immer wieder neue Fragen und Fragezeichen auf.

Ein Kollege wollte gerne eine Check-In Policy, die ein “Get Latest” vor dem Check-In simuliert, weil sie das Gefühl hatten, dass dank des Gated Check-In Code verloren geht. Das konnte ich nicht glauben und war auch der Meinung, das so eine Check-In Policy völliger Quatsch ist. Beim Check-In wird der Entwickler sowieso gezwungen bei Konflikten einen Merge am Client zu machen. Wenn die Konflikte behoben sind kann er den Check-In vornehmen und der Gated Build würde den Code bei erfolgreichem Build auch in den TFS Server einchecken.

Was ist also der Grund für den Policy Wunsch bzw. der Grund für den “verlorenen” Code? Nehmen wir mal an zwei oder mehr Entwickler ändern genau an den gleichen Codezeilen und versuchen nahezu zeitgleich einzuschecken. Bei jedem Entwickler wird auf seinem Client mit dem Stand der im TFS eingecheckt ist ein Merge vollzogen und kein Konflikt festgestellt. Der Code geht also an den Team-Build und reiht sich in die Schlange der Gated Builds ein. Siehe Abbildung 1.

clip_image002
Abb. 1: Gleichzeitige “Gated Builds” werden in Build-Queue eingereiht.

Wenn der Code erfolgreich gebaut hat, wird der Code des “schnellsten” Entwicklers an den TFS Server übergeben. Der nächste Gated Build kann aus der Queue durch der Build-Controller gestartet werden. Jetzt kann es passieren, dass der Gated Build schon am Anfang fehl schlägt, wenn kein “Auto-Merge” durchgeführt werden kann (weil ja die Entwickler auf der gleichen Codezeile Änderungen vorgenommen hatten). Das erwartete Verhalten ist also, dass folgende Builds aus der Queue immer nur nacheinander und nie zeitgleich ablaufen und dass bei Merge-Konflikten der Build fehlschlägt und der Entwickler erneut Clientseitig Mergen muss um einen weiteren Gated Build anzustoßen.

Jetzt haben wir aber das Phänomen, dass wie in Abbildung 2 zu sehen, die weiteren Gated Builds aus der Queue NICHT wie erwartet nacheinander Loslaufen sondern auf einmal gleichzeitig auf verschiedenen Agents?!

clip_image002[4]
Abb. 2: Fehler? “Gated Builds” werden aus der Build-Queue gleichzeitig gestartet.

Hier liegt vermutlich das Problem. Jeder Build für sich ist auf dem Agent valide und geht erfolgreich durch und wird in den TFS eingecheckt. Wenn aber Änderungen an gleichen Codepassagen vorhanden sind, kann es passieren, dass Code verloren geht?! Wer hat ähnliche Phänomene und kann Tipps geben.

In verschiedenen Foren haben wir ähnliche Probleme entdeckt, aber noch keine Lösung. Wir nutzen nur einen Build-Controller, der wiederum sehr viele Agents verwaltet. Es ist auch schon häufiger aufgetreten dieses Problem.

Fazit: Es würde definitiv keine Check-In Policy helfen, die “Get Latest” vor dem Check-In erzwingt, denn Merge Konflikte muss der Entwickler sowieso manuell lösen und das geht nur gegen den Code der im TFS eingecheckt ist. Würde die Queue im Falle eines Gated Check-In auch wie erwartet arbeiten (also alle Builds sequentiell) würde aus meiner Sicht auch nie Code überschrieben/verloren gehen.

h1

Gated Builds / Gated Check-in mit TFS2010 / VS2010 aus Sicht eines Entwicklers

Juli 3, 2011

Seit TFS 2010 gibt es die Möglichkeit einen “Gated Check-in” zu erzwingen. Dadurch ändert sich das Handling für den normalen Entwickler ein bisschen, denn der TFS checkt den Code eines Entwicklers nur dann ein, wenn der “Gated Build” erfolgreich war.
image

Wie der normale Workflow ist habe ich hier für alle Entscheidungen und Fälle bei einem Gated Check-in zusammengefasst:

  • Unmittelbar vor dem Einchecken:
    1. "Get Latest", damit verhindert man ggf. Check-in Konflikte.
    2. Rebuild Solution, danach ggf. Warnings, Fehler entfernen
    3. UnitTests durchführen, evtl. Fehler beseitigen
  • Änderungen Einchecken:
    1. Kommentar zum Check-in abgeben
    2. Mit Work Item verknüpfen (im Idealfall mit einem Task, Bug und diesen auf Resolved stellen)
    3. Mit OK wird der verbundene “Gated Check-in” angezeigt. Hier hat der Entwickler zwei Möglichkeiten (Änderungen lokal beibehalten, oder nicht beibehalten):
    4. image
    5. Abhängig ob man die Änderungen lokal beibehalten oder nicht beibehalten hat, muss man je nach Erfolg des Builds verschiedene Schritte durchführen:
  • Nach erfolgreichem Build ("Preserve my Pending Changes"/Änderungen lokal beibehalten angewählt):
    1. "Reconcile Workspace" – gleicht lokalen Stand mit dem auf dem Server ab
    2. "Undo Pending Changes" – macht Checkout von nicht geänderten Dateien rückgängig
    3. Jetzt hat man lokal wieder den letzten Stand aller Sourcen und hat keine Dateien mehr ausgecheckt.
  • Nach erfolgreichem Build ("Preserve my Pending Changes"/Änderungen lokal nicht beibehalten abge-wählt):
    1. "Get Latest" – letzten Stand abrufen, da vorher ein Shelve + undo pending changes lokal gemacht wurde
  • Nach Fehlerhaftem Build ("Preserve my Pending Changes" angewählt):
    1. ggf. “Get Latest Version” oder “Get Specific Version”
      image
    2. Problem beheben, Fehler fixen, Tests fixen
    3. Erneut einchecken und warten
  • Nach Fehlerhaftem Build ("Preserve my Pending Changes" abgewählt):
    1. Stand "unshelven" um lokal wieder den Fehlerhaften Stand zu haben.
    2. Problem beheben, Fehler fixen, Tests fixen
    3. Erneut einchecken und warten

Man kann unabhängig ob man die Änderungen bei einem Gated Check-in lokal beibehält oder nicht prinzipiell weiterarbeiten. Vielleicht bietet es sich trotzdem an den Gated Build abzuwarten und solange keine weiteren Änderungen vorzunehmen. Wenn man sich mit den ganzen Workflows vertraut gemacht hat und die Mechanik verstanden hat, wird man feststellen, dass es durchaus möglich ist ganz normal weiterzuarbeiten und sich von der ganzen “Gated Build Problematik” nicht weiter einzuschränken. Es ist also meiner Meinung nach ein “Mythos” dass Gated Check-in eine Blockade oder Bremse bei der Entwicklung darstellt.

Dinge wie “Reconcile” oder “Unshelve” kann man an verschiedenen Stellen machen. Die beste ist eigentlich im “Build Explorer” an einem bestimmten Build mit rechter Maustaste:

image
Rechte Maustaste an einem fehlgeschlagenen “Gated Build”

image
Rechte Maustaste an einem erfolgreichen “Gated Build”

Was alles bei einem Gated Check-in Workflow passieren soll (nur Compilieren, oder auch UnitTests usw.) entscheidet letztendlich der Buildmanager. Was man dort alles machen und optimieren kann werde ich in einem weiteren gesonderten Post beschreiben.