Erstellen einer Builddefinition für Team System 2008 Team Foundation Server
Bevor Sie eine Anwendung erstellen können, müssen Sie zunächst eine Builddefinition erstellen. Eine Builddefinition gibt an, welche Eclipse-Projekte kompiliert und wo Builds erstellt werden sollen. Nachdem Sie eine Builddefinition erstellt haben, können Sie der Warteschlange Builds hinzufügen.
Wenn Sie Builddefinitionen für Visual Studio Team System 2008 Team Foundation Server erstellen, müssen Sie diese Builds manuell ausführen. Weitere Informationen finden Sie unter Einfügen eines Builds in die Warteschlange für Team System 2008 Team Foundation Server.
Führen Sie zum Erstellen einer Builddefinition für Visual Studio Team System 2008 Team Foundation Server 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 vier 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.
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, dann liegt die tatsächliche Uhrzeit, zu der der Build ausgeführt wird, ggf. in einem unerwarteten Zeitraum, 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.
Aktivieren Sie das Optionsfeld Eincheckvorgänge lösen keinen neuen Build aus.
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.
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.
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.
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 Quellcodeverwaltung 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 neuen Arbeitsordner hinzuzufügen, klicken Sie auf Klicken Sie hier, um einen neuen Arbeitsordner einzugeben. Geben Sie einen Quellcode-Verwaltungsordner und einen Lokalen Ordner für jeden Arbeitsordner an, den Sie hinzufügen. Sie können auch auf Durchsuchen (...) klicken, um die Ordner anzugeben.
Um einen Arbeitsordner zu entfernen, klicken Sie 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 Build-Agent und einen Ablagespeicherort angeben, an dem die Buildausgabe bereitgestellt wird.
Klicken Sie auf die Registerkarte Build-Standardwerte.
Geben Sie in Build-Agent 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.
Wichtig
Für Visual Studio Team System 2008 Team Foundation Server müssen Sie die Buildausgabe in einen Ablageordner kopieren.
Geben Sie unter Builds werden in der folgenden Freigabe bereitgestellt einen gültigen Pfad für eine Windows-Dateifreigabe (oder eine Server Message Block-Freigabe) an. Der Buildserver kopiert die Buildausgabe in diesen Pfad.
Der Pfad muss im Windows-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 neue 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 der TFSBuild.proj-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) erstellen.
Wenn eine Builddefinition mit einem Visual Studio 2005-Client verwaltet werden muss, 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 oder 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 neue 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.
Klicken Sie auf die Registerkarte Beibehaltungsrichtlinie.
Klicken Sie unter Geben Sie an, wie Builds beibehalten werden sollen auf Beibehaltungsrichtlinie, um die Anzahl von Builds anzugeben, die für jeden abgeschlossenen Buildstatus 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 die Beibehaltungsrichtlinie überschreiben, indem sie Unbegrenzt beibehalten für einen oder mehrere Builds in Build Explorer 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 System 2008 Team Foundation Server.
Siehe auch
Weitere Ressourcen
Erstellen einer Builddefinition für Visual Studio 2005 Team Foundation Server
Erstellen einer Builddefinition für Team Foundation Server 2010