Share via


Team Foundation Server-Plug-In für Eclipse

Mit Team Explorer Everywhere 2010 können Sie die Vorhersagbarkeit der Entwicklungsprozesse verbessern. Team Explorer Everywhere 2010 umfasst das Team Foundation Server-Plug-In für Eclipse und den Plattformübergreifender Befehlszeilenclient für Team Foundation Server. Mit den Verfolgungsfunktionen für Arbeitsaufgaben können Sie ermitteln, was Ihren Kunden wichtig ist, sowie den Status des Projekts verfolgen. Damit können Sie Prozesse definieren und deren Qualität überwachen, sodass Ihr Team Kundenanforderungen in funktionsfähige Software umsetzen kann. Sie können den Quellcode verwalten und Projektartefakte mit Team Foundation-Versionskontrolle projizieren. Mit der Versionskontrolle mindern Sie Risiken und tragen zur Qualitätsverbesserung der Anwendung bei. Sie können die Anwendung mithilfe des integrierten Buildsystems erstellen, sodass das Team die Einhaltung der Qualitätsziele gewährleisten und erkennen kann, welche Anforderungen in jedem Build erfüllt wurden.

Verwenden von Team Explorer Everywhere zur iterativen Entwicklung

Aufgabe

Unterstützender Inhalt

Erste Schritte: Sie können die Funktionen des Team Foundation Server-Plug-In für Eclipse erst verwenden, wenn Sie eine Verbindung mit einer Instanz von Visual Studio Team Foundation Server hergestellt haben.

Richten Sie die lokale Entwicklungsumgebung ein: In den meisten Teamentwicklungsumgebungen müssen Sie Zugriff auf die richtige Version der Quellcodedateien erhalten. Sie aktualisieren dann den lokalen Computer mit den Quelldateien für die Teile der Anwendung, die Sie aktualisieren müssen.

Nehmen Sie Codeänderungen vor, um eine Aufgabe zu erledigen oder einen Fehler zu beheben: Während eines Entwicklungszyklus verwenden Sie die meiste Zeit auf Codeänderungen. Dieser Prozess umfasst das Auswählen einer Aufgabe oder eines Fehlers, das Auschecken der erforderlichen Dateien und Änderungen am Code. Anschließend wird überprüft, ob die Änderungen korrekt sind, bevor Sie sie einchecken. Im Rahmen dieser Aufgabe werden Änderungen am Anwendungscode und am Datenbankcode vorgenommen.

Erstellen und Anfordern von Builds: Mit dem integrierten Buildsystem können Sie nach einem Zeitplan oder nach Bedarf automatisierte Builds ausführen.

Definieren von Qualitätsmaßstäben: Sie können Eincheckrichtlinien festlegen, um die Qualität der Quelldateien zu schützen, die in die Versionskontrolle eingecheckt werden.

Problembehandlung: Bei Problemen mit Team Explorer Everywhere 2010 sind Informationen zu häufig auftretenden Problemen sowie Lösungen verfügbar.

Ausführen von iterativen Entwicklungsaufgaben

Sie führen für jede Entwicklungsaufgabe verschiedene allgemeine Schritte aus. Abhängig vom verwendeten Prozess in Ihrem Team können Sie diese Aufgaben in einer anderen Reihenfolge ausführen. Sie können z. B. die Tests definieren, bevor Sie Codeänderungen vornehmen.

Nachdem Sie eine Codierungsaufgabe identifiziert und den lokalen Entwicklungscomputer auf die richtige Version des Quellcodes aktualisiert haben, können Sie die notwendigen Änderungen am Code vornehmen. Die Änderung des Codes ist jedoch nur der erste Schritt, da Sie die Änderungen in der Regel auch testen müssen. Wenn Sie das Verhalten der Anwendung überprüft haben, können Sie die Entwicklungsaufgabe abschließen und zur nächsten wechseln.

Aufgabe

Unterstützender Inhalt

Identifizieren des erforderlichen Arbeitsumfangs: Die Arbeit besteht in der Regel aus einer oder mehreren Codierungsaufgaben, die ausgeführt werden müssen, oder ein oder mehreren Fehler, die behoben werden müssen. Sie rufen die Elemente mit der höchsten Priorität ab, die Ihnen von der Arbeitsaufgaben-Verfolgungsdatenbank zugewiesen wurden. Sie können auch den Gesamtzeitplan der aktuellen Iteration überprüfen, um sicherzustellen, dass Sie die Aufgaben im angenommenen Zeitrahmen ausführen können. Außerdem sollten Sie die Abhängigkeiten anderer Teammitglieder von Ihren Aufgaben überprüfen, um Blockierungsvorgänge zu vermeiden. Wenn das Team über Tester in Vollzeit verfügt, sollten Sie die Arbeit mit dem Tester absprechen, der für die betroffenen Funktionsbereiche zuständig ist. Der Tester kann dann mit der Planung der entsprechenden Tests beginnen.

Vorbereiten der Entwicklungsumgebung: Nachdem Sie die Arbeit identifiziert haben, die ausgeführt werden muss, müssen Sie möglicherweise die Entwicklungsumgebung aktualisieren, damit Sie den erforderlichen Quellcode erhalten. Wenn Sie einen Fehler in einer freigegebenen oder bereitgestellten Version der Anwendung beheben, sollten Sie die Umgebung ggf. aktualisieren, um eine bestimmte Version der Quellen statt der neuesten Version zu erhalten. Bei der Arbeit mit Datenbanken empfiehlt sich außerdem die Konfiguration eines lokalen Entwicklungsservers.

Identifizieren der Ursache von Codefehlern: Oft besteht der erste Schritt bei der Behebung eines Fehlers darin, die Ursache des Problems mithilfe eines Debuggers zu identifizieren. Wenn das Problem erst vor kurzem hinzugekommen ist, können Sie in den Verlaufsdaten nach den Quelldateien suchen, die den Fehler enthalten, und so bestimmen, wann und durch wen das Problem verursacht wurde. In einigen Situationen empfiehlt es sich unter Umständen, ein Rollback der ursprünglichen Änderung vorzunehmen und nach einer alternativen Codeänderung zu suchen.

Vornehmen von Änderungen am Code: Sie stellen fest, welche Änderungen vorgenommen werden müssen, nehmen eine oder mehrere Änderungen am Code vor, testen diese Änderungen und überprüfen, ob die Änderungen den Codierungsstandards des Teams entsprechen.

Abschließen der Arbeit: Wenn Sie der Meinung sind, dass die Codeänderungen abgeschlossen sind, überprüfen Sie diese oft mit einem oder mehreren Experten, führen eine abschließende vollständige Erstellung aus und führen Tests zum Einchecken durch. Nachdem Sie die Änderungen eingecheckt und alle Zusammenführungskonflikte gelöst haben, lösen Sie alle damit zusammenhängenden Aufgaben, Fehler und andere Arbeitsaufgaben.

Abschließen von Entwicklungsaufgaben

Wenn Sie die Implementierung und die Tests einer Codeänderung abgeschlossen haben, um eine Aufgabe, einen Fehler oder eine andere Arbeitsaufgabe zu behandeln, führen Sie in der Regel mehrere zusätzliche Aufgaben aus. In einer Teamumgebung bitten Sie häufig einen oder mehrere Mitglieder des Entwicklungsteams, Ihren Code zu überprüfen. Sie sollten auch einen abschließenden vollständigen Build der Anwendung ausführen.

Möglicherweise gibt es eine Reihe von Einchecktests, die bestanden werden müssen, bevor Sie den Code einchecken können. Nachdem alle Kriterien erfüllt wurden, können Sie die ausstehenden Codeänderungen einchecken und mögliche Zusammenführungskonflikte auflösen.

Nur wenn alle erforderlichen Schritte ausgeführt wurden, werden die entsprechenden Aufgaben, Fehler oder andere Arbeitsaufgaben aufgelöst.

Aufgabe

Unterstützender Inhalt

Lassen Sie den Code von den Kollegen überprüfen: In vielen Teamentwicklungsumgebungen müssen Sie Codeänderungen von einem oder mehreren Kollegen überprüfen lassen, bevor Sie die Änderungen einchecken können. Sie sollten in Erwägung ziehen, komplexen Code immer von einem Ihrer Mitarbeiter überprüfen zu lassen, auch wenn dieser Schritt nicht vom Team benötigt wird.

Um die Codeüberprüfung zu erleichtern, können Sie ein Shelveset vorbereiten, das die Änderungen enthält. Andere Teammitglieder können den Inhalt des Shelvesets überprüfen. Darüber hinaus werden die Änderungen in der Versionskontrolle gespeichert, sodass Sie an anderen Aufgaben arbeiten können und keine Gefahr für Ihre Änderungen besteht, wenn etwas Unerwartetes in der Entwicklungsumgebung passiert.

Ausführen eines abschließenden vollständigen Builds und zugehöriger Tests: Wenn Sie Codeänderungen vornehmen, erstellen Sie häufig nur die geänderten Teile der Anwendung. In einer Teamumgebung sollten Sie in Erwägung ziehen, die gesamte Anwendung zu erstellen, bevor Sie die Änderungen einchecken. In einigen Teams können Sie eingecheckten Code an einen Computer senden, der fortlaufende Builds ausführt.

In vielen Teams müssen Sie zudem einen Teil der Anwendungstests ausführen. Diese werden als Einchecktests bezeichnet. Durch diese Tests wird überprüft, ob das Verhalten der Anwendung in anderen Bereichen als denjenigen, die Sie direkt geändert haben, beeinträchtigt wurde.

Checken Sie alle Änderungen ein: Nachdem Sie die Änderungen überprüft haben, müssen Sie sie in die Versionskontrolle einchecken, um sie für das Team verfügbar zu machen. Wenn Sie die Änderungen einchecken, werden diese auch im nächsten vollständigen Produktbuild angezeigt. Sie können ausstehende Änderungen auch zurücksetzen, wenn sie z. B. ein zu hohes Risiko in der aktuellen Phase eines Produktzyklus bedeuten.

Wenn Sie Code ändern, der von einem abgegrenzten Eincheckbuild geschützt ist, wird ein Shelveset erstellt, und die ausstehenden Änderungen müssen erfolgreich erstellt werden, bevor sie eingecheckt werden können.

Lösen Sie Aufgaben, Fehler und andere Arbeitsaufgaben auf: Nachdem Sie die Änderungen eingecheckt haben, können Sie die damit im Zusammenhang stehenden Aufgaben, Fehler oder anderen Arbeitsaufgaben auflösen, die den Änderungen zugewiesen sind. In der Regel weisen Sie das Changeset, das die Änderungen enthielt, der Arbeitsaufgabe zu. Dadurch können Sie die damit in Zusammenhang stehenden Änderungen leichter finden, wenn der Fehler später erneut auftritt. Geben Sie im Kommentar für die Arbeitsaufgabe genügend Informationen an, um andere Leser über Art und Grund der Änderung zu informieren. Zudem empfiehlt sich unter Umständen die Anwendung einer Bezeichnung, um später ggf. auf diese Quellcodeversion verweisen zu können.

Nach Abschluss einer Arbeitsaufgabe muss unter Umständen der Entwicklungszeitplan angepasst werden, falls für die Aufgabe deutlich mehr oder deutlich weniger Zeit aufgewendet werden musste.

Geben Sie Entwurfsfeedback: Wenn Sie eine Codeänderung vornehmen, müssen Sie möglicherweise Elemente des Anwendungsentwurfs oder der Anwendungsarchitektur ändern. Wenn Sie den Entwurf ändern, sollten Sie alle Dokumente bezüglich Architektur und Entwurf (einschließlich Modellen) so aktualisieren, dass sie die Änderungen enthalten. Wenn Sie einen Fehler korrigiert haben, sollten Sie den anderen Teammitgliedern außerdem Informationen zur Art des Fehlers bereitstellen und ihnen mitteilen, wie der Fehler in Zukunft verhindert werden kann.

Siehe auch

Weitere Ressourcen

Befehlszeilenreferenz (Team Explorer Everywhere)