it-swarm.com.de

Wie verknüpfe ich eine Überprüfungsanforderung mit mehreren Änderungssätzen in TFS 2012

Unser Entwicklungsprozess funktioniert folgendermaßen: Alle 2 Wochen geht der Teamleiter (ich) hinein und überprüft alle Änderungssätze, um sicherzustellen, dass sie den Kodierungsstandards entsprechen. Ich möchte TFS 2012 verwenden, um diesen Prozess zu automatisieren.

Es gibt 2 Probleme damit:

  1. Es gibt keine Möglichkeit, eine unerwünschte Codeüberprüfung einzureichen. Ich kann, wenn nötig, auch ohne leben

  2. Es gibt keine Möglichkeit, eine Codeüberprüfung mit mehr als einem Änderungssatz zu verknüpfen. Dies ist ein Deal-Breaker

Ich habe einen Artikel gelesen, in dem es möglich ist, Änderungssätze nachträglich mit einem Arbeitselement zu verknüpfen. Wenn ich das Arbeitselement für die Anforderungsüberprüfung öffne, wird die Registerkarte Links angezeigt. Wenn ich jedoch auf "Neu" oder "Verknüpfen mit ..." klicke, gibt es keine Option zum Verknüpfen mit einem Änderungssatz. Es gibt nur eine Option zum Verknüpfen mit jedem Arbeitsaufgabentyp im Prozess.

Weiß jemand, wie man das macht? Gibt es Pläne, diese Funktionen zu TFS hinzuzufügen?

Hier ist ein Screenshot:

No changeset option to be found... :(

28
Doug
  1. Unaufgefordert, nein.
  2. Sie können im Verlaufsbildschirm mit der rechten Maustaste auf ein Änderungsset klicken, um eine Überprüfung nach dem Einchecken anzufordern.

Und es gibt eine üble Umgehung, um das zu erreichen, was Sie erreichen möchten. Überprüfen Sie alle Dateien, die Sie überprüfen möchten, und fordern Sie eine Überprüfung an. Sie können dann Ihre Kaufabwicklung rückgängig machen, das Regal und die Überprüfungsanforderung bleiben erhalten.

Alternativ können Sie einfach auf die Registerkarte Quellcodeverwaltung gehen und im Stammordner Ihrer Lösung eine Überprüfung durchführen, die Überprüfung anfordern, die Überprüfung rückgängig machen und die Überprüfung durchführen.

Das Verknüpfen von Changesets mit einem Workitem kann nach dem Einchecken erfolgen. Öffnen Sie das Arbeitselement, wechseln Sie zur Registerkarte "Links" und klicken Sie auf "Link to ...". In der Dropdown-Liste wird die Option "Changeset" angezeigt. Ich glaube jedoch nicht, dass dieser Linktyp für Codeüberprüfungsanforderungen aktiviert ist, da diese ein Shelveset und keine Änderungssätze als Quelle für die Überprüfung des Codes verwenden.

enter image description here

Ich gehe davon aus, dass Sie die TFS-API verwenden können, um ein Shelveset mit allen Änderungen eines bestimmten Entwicklers in einem bestimmten Zeitbereich zu generieren, diese in ein Shelveset zu stellen und eine Überprüfung dazu anzufordern. Dafür gibt es aber kein vorhandenes Feature.

Möglicherweise können Sie auch das mit der Überprüfung verknüpfte Regal bearbeiten, indem Sie ein neues Regal mit demselben Namen erstellen.

10
jessehouwing

Ein alternativer Ansatz:

1) zu Beginn des zweiwöchigen Zyklus den Codeüberprüfungsprozess einleiten und die erstellte Workitem-Nummer notieren. Fordern Sie einfach eine Bewertung von sich selbst an, ohne dass sich der Code zunächst ändert.

2) Bitten Sie alle Entwickler, ihre Check-Ins für die nächsten 2 Wochen mit diesem Arbeitselement zu verknüpfen #

3) Wenn Sie bereit sind, die Überprüfung durchzuführen, öffnen Sie einfach das Arbeitselement und gehen Sie die Änderungssätze durch.

Das sollte erreichen, was Sie wollen.

1
Andrew Clear

Zu Punkt 2 habe ich eine Standardarbeit, mit der Sie möglicherweise alle Änderungen aus vielen Änderungssätzen zu einem Regalsatz zur Überprüfung zusammenfassen möchten. Ich habe die oben erwähnte Auscheckmethode ausprobiert und bin auf Probleme gestoßen, zum Teil, weil meine Überprüfung etwa 25 Dateien enthielt. Nachdem ich sie ausgecheckt hatte, entfernte TFS sie aus ausstehenden Änderungen, da es nach Ansicht von TFS keine Änderungen gab.

Erstens (vorausgesetzt, Ihre Änderungen sind bereits eingecheckt und befinden sich in mehreren Änderungssätzen), verfügen Sie über einen Arbeitsbereich mit den neuesten Dateien auf einem Datenträgerpfad wie D:\Latest ...

Erstellen Sie einen neuen "lokalen" Arbeitsbereich ("Review" genannt), ordnen Sie dasselbe Projekt dem etwas anderen Pfad zu (z. B. D:\Review ... ") und rufen Sie alle Dateien ab. Gehen Sie zum Verlauf dieses Projekts und direkt davor Klicken Sie mit der rechten Maustaste auf Ihr frühestes Änderungsset und wählen Sie "Get this version".

Gehen Sie zu diesem Zeitpunkt zum Verlauf und setzen Sie alle Änderungssätze zurück, die in der Zwischenzeit möglicherweise von einer anderen Person geändert wurden und die Sie nicht überprüfen möchten, es sei denn, jemand hat eine gemeinsame Datei geändert. Lass die.

Vergleichen Sie "D:\Latest ..." mit "D:\Review ..." und kopieren Sie Ihre Änderungen von "Latest" in "Review". Gehen Sie in die allgemeinen Dateien und kopieren Sie nur die Zeilen, die Sie überprüfen möchten. Wenn Beyond Compare die Änderungen ausschreibt, erkennt TFS die Änderung und legt die von Ihnen gespeicherte Datei in der Liste der ausstehenden Änderungen für den Arbeitsbereich "Überprüfen" ab. (Dies ist eine Funktion lokaler Arbeitsbereiche.)

Zu diesem Zeitpunkt speichern Sie Ihre ausstehenden Änderungen einfach im Arbeitsbereich "Überprüfen" und fordern eine Überprüfung in diesem Regalsatz an.

0
SteveSims

Option 3

[ Ich gehe hier davon aus, dass die Änderungssätze, die Sie einer einzelnen Codeüberprüfung zuordnen möchten, aufeinanderfolgend sind, zum Beispiel 20001: 20010 ]

  1. Ich habe auf ein bestimmtes Änderungsset zurückgesetzt (in meinem Beispiel über 20001). Ich überprüfe es in den Änderungen. Der Code befindet sich jetzt in seinem ursprünglichen Zustand.

  2. Dann "rolle ich zurück zu einem bestimmten Änderungssatz" (in meinem Beispiel über 20010) und checke ihn erneut ein. Der Code befindet sich jetzt in seinem endgültigen Zustand.

  3. Zum Schluss bitte ich um eine Überprüfung der letzten Überarbeitung. In diesem Test werden die letzten beiden Commits verglichen - die, die ich aus dem Rollback erstellt habe.

Als Bonus können Sie bestimmte Änderungssätze auf der Verlaufsseite vergleichen. Sie können diesen Vergleich verwenden, um sicherzustellen, dass die obigen Commits den Code tatsächlich auf die Revisionen 20001 und 20010 zurückgesetzt haben.

0
KlingonJoe