Erstellen einer Builddefinition für Team Foundation Server 2010
Vor dem Erstellen der Anwendung müssen Sie eine Builddefinition erstellen. Diese gibt an, welche Ant- oder Maven-Projekte kompiliert werden sollen und wo Builds ausgeführt werden sollen. Nachdem Sie eine Builddefinition erstellt haben, können Sie der Warteschlange Builds hinzufügen.
Wenn Sie Builddefinitionen für Visual Studio Team Foundation Server 2010 erstellen, können Sie den Trigger angeben, der bewirkt, dass der Build automatisch in die Warteschlange gestellt wird, oder Sie können Builds manuell ausführen. Weitere Informationen finden Sie unter Einfügen eines Builds in die Warteschlange für Team Foundation Server 2010 (Team Explorer Everywhere).
Führen Sie zum Erstellen einer Builddefinition für Team Foundation Server 2010 die folgenden Aufgaben aus:
Tipp
Die einzelnen Abschnitte dieses Prozesses sollten in der angegebenen Reihenfolge ausgeführt werden. Die Aufgabe wird in kleinere Verfahren aufgeteilt, um die Übersichtlichkeit zu verbessern.
Erforderliche Berechtigungen
Zum Ausführen dieses Vorgangs muss für Sie die Berechtigung Builddefinition bearbeiten auf Zulassen festgelegt sein. Weitere Informationen finden Sie auf der folgenden Seite auf der Microsoft-Website: Team Foundation Server-Berechtigungen.
Öffnen des Dialogfelds "Builddefinition"
Erweitern Sie in Team Explorer das Teamprojekt, für das Sie eine Builddefinition erstellen möchten.
Klicken Sie mit der rechten Maustaste auf den Knoten für Builds, und klicken Sie dann auf Neue Builddefinition.
Das Dialogfeld Builddefinition wird angezeigt. Die Registerkarte Allgemein ist aktiv.
Geben Sie anschließend einen Namen und eine Beschreibung für die Builddefinition an.
Angeben eines Namens und einer Beschreibung für die Builddefinition
Klicken Sie auf die Registerkarte Allgemein.
Geben Sie im Feld Builddefinitionsname den Namen ein, den Sie für die Builddefinition verwenden möchten.
Dieser Name muss innerhalb des Teamprojekts eindeutig sein.
(Optional) Geben Sie unter Beschreibung eine Beschreibung für diese Builddefinition ein.
(Optional) Wenn Sie diese Builddefinition deaktivieren möchten, klicken Sie auf Diese Builddefinition deaktivieren.
Dies kann z. B. sinnvoll sein, wenn Sie einen automatisierten Build definieren möchten, aber noch nicht bereit sind, diesen Build automatisch auszuführen.
Danach geben Sie den Buildtrigger an, um zu definieren, wann ein Build ausgeführt werden soll.
Angeben des Buildtriggers
Sie können mit Team Foundation Server 2010 einen der fünf Typen von Buildtriggern angeben:
Erstellen bei Bedarf (manueller Trigger)
Wird kontinuierlich bei jedem Einchecken erstellt. Wenn der Build-Agent einen früheren Build noch nicht abgeschlossen hat, wird der neue Build in die Warteschlange gestellt.
Bei jedem Einchecken sollte der Warteschlange ein Build hinzugefügt werden, der ausgeführt wird, sobald ein Agent frei ist. Diese Funktion kann auch begrenzt werden, sodass eine minimale Zeit zwischen den Builds eingehalten wird. Sie können diese Option z. B. wählen, wenn der Build sehr lange dauert und Sie viele Eincheckvorgänge durchführen müssen, die zu übermäßig vielen Builds in der Warteschlange führen würden.
Abgegrenzte Eincheckbuilds. Wenn ein abgegrenzter Eincheckbuild erstellt wird, werden von Ihnen übermittelte Änderungen in ein Shelveset eingefügt und im Buildsystem automatisch erstellt. Der Eincheckvorgang wird nur abgeschlossen, wenn der Build erfolgreich ist.
Geplante (tägliche) Builds. Sie können die Tage und die Uhrzeit angeben, zu der der Build ausgeführt wird. Sie können auch erzwingen, dass der Build immer zu dieser Zeit ausgeführt wird, auch wenn keine Änderungen im dazwischenliegenden Zeitraum vorgenommen wurden.
Tipp
Wenn Sie die Builddefinition auf einem Computer erstellen, der sich in einer anderen Zeitzone als der Computer befindet, auf dem die Builds ausgeführt werden, wird der Build ggf. in einem unerwarteten Zeitraum ausgeführt, falls die Sommerzeitvorgaben der beiden Zeitzonen sich unterscheiden.
So erstellen Sie eine Builddefinition, die bei Bedarf ausgelöst wird
Klicken Sie auf die Registerkarte Trigger.
Klicken Sie auf Eincheckvorgänge lösen keinen neuen Build aus.
Klicken Sie auf OK, um die Builddefinition auf dem Server zu speichern.
Sie sollten einen Testbuild ausführen, um zu überprüfen, ob die Builddefinition wie erwartet funktioniert. Weitere Informationen finden Sie unter Einfügen eines Builds in die Warteschlange für Team Foundation Server 2010 (Team Explorer Everywhere).
So erstellen Sie eine Builddefinition, die kontinuierlich bei jedem Einchecken erstellt wird
Klicken Sie auf die Registerkarte Trigger.
Klicken Sie auf Alle Eincheckvorgänge erstellen.
Klicken Sie auf OK, um die Builddefinition auf dem Server zu speichern.
Sie sollten einen Testbuild ausführen, um zu überprüfen, ob die Builddefinition wie erwartet funktioniert. Weitere Informationen finden Sie unter Einfügen eines Builds in die Warteschlange für Team Foundation Server 2010 (Team Explorer Everywhere).
So erstellen Sie eine Builddefinition, die kontinuierlich erstellt, sobald Agents verfügbar sind
Klicken Sie auf die Registerkarte Trigger.
Klicken Sie auf Eincheckvorgänge bis zum Abschluss des vorherigen Builds ansammeln.
(Optional) Wenn Sie die Häufigkeit von Builds weiter einschränken möchten, aktivieren Sie das Kontrollkästchen Erstellung nicht öfter als alle. Geben Sie im Feld Minuten die Mindestanzahl in Minuten an, die zwischen Builds liegen soll.
Klicken Sie auf OK, um die Builddefinition auf dem Server zu speichern.
Sie sollten einen Testbuild ausführen, um zu überprüfen, ob die Builddefinition wie erwartet funktioniert. Weitere Informationen finden Sie unter Einfügen eines Builds in die Warteschlange für Team Foundation Server 2010 (Team Explorer Everywhere).
So erstellen Sie einen abgegrenzten Eincheckbuild
Klicken Sie auf die Registerkarte Trigger.
Klicken Sie auf Abgegrenzter Eincheckvorgang – Eincheckvorgänge nur akzeptieren, wenn die übermittelten Änderungen erfolgreich zusammengeführt und erstellt werden. Weitere Informationen über abgegrenzte Eincheckvorgänge finden Sie unter Einchecken ausstehender Änderungen für einen abgegrenzten Eincheckbuild (Team Explorer Everywhere).
Klicken Sie auf OK, um die Builddefinition auf dem Server zu speichern.
Sie sollten einen Testbuild ausführen, um zu überprüfen, ob die Builddefinition wie erwartet funktioniert. Weitere Informationen finden Sie unter Einfügen eines Builds in die Warteschlange für Team Foundation Server 2010 (Team Explorer Everywhere).
So erstellen Sie eine Builddefinition, die nach einem angegebenen Zeitplan erstellt
Klicken Sie auf die Registerkarte Trigger.
Klicken Sie auf Erstellung jede Woche an folgenden Tagen.
Aktivieren Sie die Kontrollkästchen für die Tage, an denen der Build ausgeführt werden soll.
Geben Sie in Build für den standardmäßigen Build-Agent in die Warteschlange stellen bei die die Uhrzeit an, zu der der Build in die Warteschlange gestellt werden soll.
(Optional) Aktivieren Sie das Kontrollkästchen Auch erstellen, wenn seit dem vorherigen Build keine Änderungen vorgenommen wurden.
Klicken Sie auf OK, um die Builddefinition auf dem Server zu speichern.
Sie sollten einen Testbuild ausführen, um zu überprüfen, ob die Builddefinition wie erwartet funktioniert. Weitere Informationen finden Sie unter Einfügen eines Builds in die Warteschlange für Team Foundation Server 2010 (Team Explorer Everywhere).
Anschließend geben Sie die Arbeitsordner an, die Sie in den Build einschließen möchten.
Angeben der in den Build einzuschließenden Arbeitsordner
Auf dieser Registerkarte geben Sie die Ordner an, die im Build enthalten sein sollen. Jeder Pfad wird einem relativen Speicherort unterhalb eines Stammbuildverzeichnisses im Build-Agent zugeordnet, auf das mit $(SourceDir) verwiesen wird. Der Build-Agent wird unter einem Windows-Betriebssystem ausgeführt. Daher müssen die relativen Pfade für Lokale Ordner unter Berücksichtigung der Namenskonventionen für Windows-Verzeichnisse angegeben werden. Beispielsweise muss der umgekehrte Schrägstrich (\) als Pfadtrennzeichen verwendet werden.
Standardmäßig ist das ganze Teamprojekt eingeschlossen. Es kann jedoch ratsam sein, nur die Ordner einzuschließen, die für die Builddefinition erforderlich sind. Auf diese Weise können Sie die Anzahl der Dateien reduzieren, die aus der Versionskontrolle heruntergeladen werden, um den Build auszuführen.
Klicken Sie auf die Registerkarte Arbeitsbereich.
Um die Arbeitsordner zu ändern, führen Sie eine der folgenden Aufgaben aus:
Um eine andere Team Foundation Server-Arbeitsbereichsdefinition zu kopieren, klicken Sie auf Vorhandenen Arbeitsbereich kopieren, und geben Sie den Arbeitsbereich an, den Sie kopieren möchten.
Um einen Arbeitsordner hinzuzufügen, klicken Sie auf Klicken Sie hier, um einen neuen Arbeitsordner einzugeben. Geben Sie für jeden Arbeitsordner, den Sie hinzufügen, einen Quellcode-Verwaltungsordner und einen Lokalen Ordner an. Sie können auch auf Durchsuchen (...) klicken, um die Ordner anzugeben.
Um einen Arbeitsordner zu löschen, klicken Sie mit der rechten Maustaste auf den Ordner, der gelöscht werden soll, und dann auf Löschen.
Danach geben Sie die Standardeinstellungen für den Build an.
Angeben der Standardeinstellungen für den Build
Sie müssen einen Buildcontroller und einen Ablagespeicherort angeben, an dem die Buildausgabe bereitgestellt wird.
Klicken Sie auf die Registerkarte Build-Standardwerte.
Geben Sie in Buildcontroller den Build-Agent an, den Sie für die Builddefinition verwenden möchten.
Aktivieren Sie das Kontrollkästchen Dieser Build kopiert Ausgabedateien in einen Ablageordner, wenn es noch nicht aktiviert ist.
Geben Sie unter Builds werden in der folgenden Freigabe bereitgestellt einen gültigen Pfad für eine Windows-Dateifreigabe (oder eine Samba-Freigabe) an. Der Buildserver kopiert die Buildausgabe in diesen Pfad.
Der Pfad muss im UNC-Format angegeben werden, z. B. \\Servername\Freigabe.
Anschließend geben Sie den Speicherort der Projektdatei an.
Angeben des Projektdateispeicherorts
Team Foundation Build verwendet ein MSBuild-Skript mit dem Namen TFSBuild.proj, um den Buildprozess zu steuern. Verwenden Sie die Registerkarte Profildatei, um zu einer vorhandenen TFSBuild.proj-Datei in der Versionskontrolle zu wechseln oder eine TFSBuild.proj-Datei zu erstellen, die Sie der Builddefinition zuordnen. Wenn für zwei oder mehr Builddefinitionen dieselbe TFSBuild.proj-Datei verwendet wird, wirken sich Änderungen an dieser Datei auf alle Builddefinitionen aus.
Sie können entweder einen Ordner angeben, der eine vorhandene TFSBuild.proj-Datei enthält, oder Sie können eine neue TFSBuild.proj-Datei aus einer vorhandenen Ant-Builddatei (Build.xml) oder aus einem vorhandenen Maven-Projektobjektmodell (pom.xml) erstellen.
Wenn Sie eine Builddefinition mit einem Visual Studio 2005-Client verwalten müssen, müssen Sie die Projektdatei in einem Ordner mit dem Namen TeamBuildTypes im Stamm des Teamprojekts in der Versionskontrolle speichern. Wenn alle am Build Mitwirkenden Visual Studio 2008, Visual Studio 2010 oder das Team Foundation Server-Plug-In für Eclipse verwenden, kann der Buildordner an einem beliebigen Speicherort innerhalb des Teamprojekts in der Versionskontrolle liegen.
So geben Sie eine vorhandene TFSBuild.proj-Datei an
Klicken Sie auf die Registerkarte Projektdatei.
Klicken Sie auf Durchsuchen, um den Versionskontrollordner anzugeben, der die TFSBuild.proj-Datei enthält.
So erstellen Sie eine TFSBuild.proj-Datei
Klicken Sie auf die Registerkarte Projektdatei.
Klicken Sie auf Durchsuchen, um den Versionskontrollordner anzugeben, in dem die neue TFSBuild.proj-Datei erstellt werden soll.
Klicken Sie auf Erstellen.
Der Assistent zum Erstellen einer Buildkonfiguration wird angezeigt.
Klicken Sie in der Liste Assistenten entweder auf MSBuild-Konfiguration aus vorhandener Ant-Builddatei oder auf MSBuild-Konfiguration aus vorhandener Maven-POM-Datei.
Klicken Sie auf Weiter.
Geben Sie in Builddatei die Ant-Builddatei oder die Maven-POM-Datei auf dem Versionskontrollserver an.
Klicken Sie auf Fertig stellen.
Aus der Ant-Builddatei oder der Maven-POM-Datei wird eine neue TFSBuild.proj-Datei erstellt.
Danach geben Sie eine Beibehaltungsrichtlinie für den Build an, um anzugeben, wie lange Builds beibehalten werden sollen.
Angeben der Beibehaltungsrichtlinie für den Build
Für jeden Status abgeschlossener Builds können Sie eine Reihe von Builds dieses Typs angeben, die automatisch beibehalten werden. Wenn Sie Builds mit Team Foundation Server 2010 definieren, können Sie eine Beibehaltungsrichtlinie für ausgelöste und manuelle Builds und eine weitere Beibehaltungsrichtlinie für private Builds angeben.
Klicken Sie auf die Registerkarte Beibehaltungsrichtlinie.
Klicken Sie unter Beibehaltungsrichtlinie auf die entsprechende Option neben jedem Buildstatus, um anzugeben, wie viele Builds beibehalten werden sollen.
Sie können auf Beizubehaltende Anzahl angeben klicken und eine bestimmte Anzahl von Builds angeben, wenn keiner der bereitgestellten Werte die Anforderungen erfüllt.
Tipp
Benutzer können in Build Explorer die Beibehaltungsrichtlinie für einen oder mehrere Builds überschreiben, indem sie Unbegrenzt beibehalten angeben. Weitere Informationen finden Sie unter Unbegrenztes Beibehalten eines Builds.
Speichern der Builddefinition
Klicken Sie im Dialogfeld Builddefinition auf OK.
Die Builddefinition wird auf dem Server gespeichert.
Sie sollten einen Testbuild ausführen, um zu überprüfen, ob die Builddefinition wie erwartet funktioniert. Weitere Informationen finden Sie unter Einfügen eines Builds in die Warteschlange für Team Foundation Server 2010 (Team Explorer Everywhere).
Siehe auch
Weitere Ressourcen
Erstellen von und Arbeiten mit Builddefinitionen (Team Explorer Everywhere)
Erstellen einer Builddefinition für Visual Studio 2005 Team Foundation Server
Erstellen einer Builddefinition für Team System 2008 Team Foundation Server