Informationen zum Team Foundation-Buildsystem

Sie können Team Foundation Build zum Kompilieren, Testen und Bereitstellen der Software in einem automatisierten und verteilten System verwenden. Diese Software ist dafür konzipiert, sowohl kleinere Softwareprojekte von Startupunternehmen als auch etablierte Softwareentwicklungsunternehmen zu unterstützen. Das System ist so ausgelegt, dass Sie das Buildsystem skalieren können, wenn das Team und die CodeBase wächst.

In diesem Thema

• Buildcomputer

  • Team Foundation-Builddienst

  • Verwenden von virtuellen Computern als Buildcomputer

• Buildcontroller

• Build-Agent

• Beispiele für die Topologie des Buildsystems

• Nächste Schritte

Buildcomputer

Um Team Foundation Build verwenden zu können, müssen Sie über mindestens einen Buildcomputer verfügen. Für mittlere oder große Softwareprojekte werden in der Regel mehrere Buildcomputer benötigt. Weiter unten in diesem Thema finden Sie Beispiele für verschiedene Buildsystemkonfigurationen.

Ein Buildcomputer ist ein Computer, auf dem Sie Team Foundation-Builddienst installiert und konfiguriert haben. Bei dem Computer kann es sich um einen physischen Computer handeln (beispielsweise einen Personalcomputer unter dem Schreibtisch oder eine Arbeitsstation in einem Labor). Alternativ können Sie als Buildcomputer auch einen virtuellen Computer verwenden und so von dessen Flexibilität zu profitieren.

Obwohl Sie einen Buildcomputer direkt auf dem Computer konfigurieren, ändern und verwalten, auf dem Team Foundation-Builddienst ausgeführt wird, werden die eigentlichen Konfigurationsdaten in der Teamprojektsammlung gespeichert.

Team Foundation-Builddienst

Um einen Buildcomputer einzurichten, müssen Sie Team Foundation-Builddienst installieren, konfigurieren und ausführen.

Team Foundation-Builddienst ist ein Windows-Dienst, der an verschiedenen Stellen im Betriebssystem aufgeführt ist. Die jeweilige Verfügbarkeit hängt davon ab, ob Team Foundation-Builddienst als Windows-Dienst oder interaktiver Dienst ausgeführt wird. (Weitere Informationen zum Festlegen dieser Option finden Sie unter Konfigurieren eines Buildcomputers.)

Wenn der Team Foundation-Builddienst als Windows-Dienst ausgeführt wird:

• Im Knoten Dienste ist Team Foundation-Builddienst als Visual Studio Team Foundation-Builddiensthost aufgeführt. Sie können den Knoten Dienste an einer der folgenden Stellen anzeigen:

  • Unter einem Serverbetriebssystem (z. B. Windows Server 2008) im Server-Manager.

  • Unter einem Clientbetriebssystem (z. B. Windows Vista) in der Computerverwaltung.

• Der Team Foundation-Builddienst wird im Task-Manager auf der Registerkarte Dienste als Visual Studio Team Foundation-Builddiensthost aufgeführt.

Wenn der Team Foundation-Builddienst als interaktiver Dienst ausgeführt wird:

• Der Team Foundation-Builddienst wird im Task-Manager auf der Registerkarte Anwendungen als TFSBuildServiceHost aufgeführt.

Verwenden von virtuellen Computern als Buildcomputer

Team Foundation-Builddienst kann auf einem virtuellen Computer bereitgestellt werden (z. B. ein virtueller Hyper-V-Computer auf einem physischen Computer, auf dem Windows Server 2008 ausgeführt wird). Indem Sie diese Strategie verfolgen, können Sie die folgenden Aufgaben auf einfache Weise ausführen:

• Wiederherstellen des Systems aus jedem Zustand und zu jeder Zeit. Wenn das System z. B. beschädigt wird, können Sie schnell auf eine Momentaufnahme einer sauberen Umgebung zurückgreifen und das System wiederherstellen.

• Erstellen Sie eine Momentaufnahme eines virtuellen Computers, und exportieren Sie diese. Sie können die Momentaufnahme dann archivieren oder für ein anderes Mitglied im Team freigeben.

Der Hauptnachteil bei der Verwendung eines virtuellen Computers besteht darin, dass die Ausführung langsamer als bei einem physischen Computer ist. Wenn der für die Builds erforderliche Arbeitsaufwand gering ist oder wenn Sie nur selten Builds erstellen (z. B. nur nachts), reicht ein virtueller Computer als Buildcomputer im System ggf. aus.

Treffen Sie die folgenden Vorkehrungen, um die Leistung von Team Foundation-Builddienst bei der Ausführung auf einem virtuellen Computer zu verbessern:

• Führen Sie die virtuellen Computer auf einem physischen Computer aus, der über einen Multicore-Prozessor verfügt. Wenn der physische Computer z. B. über einen Quad-Core-Prozessor verfügt, können Sie vier virtuelle Computer gleichzeitig ausführen. Als Buildcomputer erzielen diese dann in vielen Situationen eine annehmbare Leistung.

• Weisen Sie jedem virtuellen Computer eine physische Festplatte zu, und mounten Sie diese.

Buildcontroller

Jeder Buildcontroller ist einer bestimmten Teamprojektsammlung fest zugewiesen. Der Controller akzeptiert Buildanforderungen von allen Teamprojekten in einer angegebenen Teamprojektsammlung.

Jeder Buildcontroller legt die Dienste von einem oder mehreren Build-Agents in einem Pool ab und verwaltet diese. Er verteilt die prozessorintensive Arbeit (z. B. das Kompilieren von Code oder das Durchführen von Tests) auf die Build-Agents innerhalb des Pools.

Der Buildcontroller verarbeitet den Workflow und führt hauptsächlich einfache Arbeiten aus, z. B. das Ermitteln des Namens für den Build, das Erstellen der Bezeichnung in der Versionskontrolle, das Protokollieren von Hinweisen und das Melden des Status aus dem Build.

Da ein Buildcontroller in der Regel nicht viel Prozessorzeit erfordert, reicht ein virtueller Computer häufig aus, um als Plattform für einen Buildcontroller zu dienen. Ein Buildcontroller kann in bestimmten Situationen jedoch sehr viel Arbeitsspeicher erfordern. Daher sollten Sie sicherstellen, dass der physische Computer oder der virtuelle Computer, auf dem Sie die Buildcontroller einrichten, über genügend Arbeitsspeicher verfügt.

Build-Agent

Jeder Build-Agent ist einem einzelnen Buildcontroller fest zugeordnet und wird von diesem gesteuert. Der Build-Agent übernimmt die prozessor- und datenträgerintensiven Aufgaben. Diese Aufgaben umfassen das Abrufen von Dateien aus und das Einchecken von Dateien in die Versionskontrolle, das Bereitstellen des Arbeitsbereichs, das Kompilieren des Codes und das Ausführen von Tests.

Wenn Sie ein Buildsystem zusammenstellen, können Sie mit einer niedrigen Anzahl von Agents beginnen. Sie können das Buildsystem dann vergrößern und weitere Build-Agents hinzufügen, wenn weitere Teammitglieder hinzukommen, die CodeBase anwächst und mehr Arbeit anfällt, die vom Buildsystem erledigt werden muss.

Wenn Sie für die Agents spezielle Funktionen einrichten, sollten Sie den Agents Tags zuweisen. Indem Sie diese Strategie verfolgen, können Sie Builddefinitionen erstellen, die diese spezialisierten Agents verwenden können. Sie können z. B. das BVT-Tag einer Gruppe von Agents zuweisen, die für die Ausführung der BVT-Tests ausgelegt sind. Anschließend können Sie festlegen, dass während des nächtlichen Buildvorgangs nur diese Build-Agents verwendet werden sollen.

Da die Build-Agents den Großteil der prozessorintensiven Arbeitsschritte übernehmen, sollten Sie sicherstellen, dass der Buildcomputer über eine ausreichend leistungsstarke Hardware verfügt, sodass die Build-Agents die Aufgaben in einem akzeptablen Zeitraum verarbeiten können.

Beispiele für die Topologie des Buildsystems

Team Foundation-Builddienst ist so konzipiert, dass Sie mit einem kleineren und weniger komplexen Buildsystem beginnen können. Wenn die CodeBase anwächst und sich das Team vergrößert, können Sie das System relativ einfach schrittweise erweitern, indem Sie dem vorhandenen System Buildcomputer hinzufügen.

System mit einem einzelnen Computer (gemeinsame Nutzung mit Anwendungsebene)

Die folgende Konfiguration kann ein sehr kleines Team unterstützen, das Buildvorgänge beispielsweise nur unregelmäßig und nicht während der Stoßzeiten ausführt. (Beispiel: Nur ein Buildvorgang während der Nacht.)

In den meisten Fällen ist eine Topologie mit nur einem einzelnen Buildcomputer nicht ausreichend. Dafür gibt es folgende Gründe:

• Die von einem Build-Agent ausgeführten Arbeitsschritte führen zu einer hohen Prozessorauslastung, sodass die Leistung auf Anwendungsebene erheblich beeinträchtigt werden kann.

• Der Buildcontroller kann eine Belastung für den Arbeitsspeicher des Systems bedeuten. Dies gilt besonders, wenn der Controller gleichzeitig viele aktive Build-Agents verwaltet.

• Durch die Installation von Team Foundation-Builddienst vergrößert sich die Angriffsfläche eines Buildcomputers. Ein böswilliger Benutzer kann z. B. eine Builddefinition erstellen, mit der beliebiger Code ausgeführt werden kann, um so die Kontrolle über den Server zu übernehmen und Daten zu stehlen.

System mit einem einzelnen Computer (eigenständig)

Die folgende Konfiguration ist ein guter Ausgangspunkt für ein kleines Team.

Da die prozessorintensive Arbeit von Build-Agents auf einem separaten Computer ausgeführt wird, wird die Leistung auf Anwendungsebene nicht beeinträchtigt, wenn Builds ausgeführt werden.

Sie können den Buildcontroller auch auf dem dedizierten Buildcomputer ausführen. Die Konfiguration in der Abbildung hat jedoch den Vorteil, dass Änderungen des Buildsystems weniger störend erfolgen können, z. B. bei einer Reparatur oder einem Austausch des Buildcomputers.

Das Verwenden des Buildcontrollers auf dem gleichen Computer wie die Anwendungsebene stellt aus Prozessorsicht generell kein Problem dar. Es kann aus den folgenden Gründen jedoch trotzdem ratsam sein, auf eine besser skalierbare Topologie umzustellen:

• Der Buildcontroller kann eine Belastung für den Arbeitsspeicher des Systems bedeuten. Dies gilt besonders, wenn der Controller gleichzeitig viele aktive Build-Agents verwaltet.

• Durch die Installation von Team Foundation-Builddienst vergrößert sich die Angriffsfläche eines Buildcomputers. Ein böswilliger Benutzer kann z. B. eine Builddefinition erstellen, mit der beliebiger Code ausgeführt werden kann, um so die Kontrolle über den Server zu übernehmen und Daten zu stehlen.

System mit mehreren Computern

Mittlere und große Teams benötigen für ihre Aufgaben im Allgemeinen mehrere Buildcomputer. Im folgenden Beispiel werden zwei Buildcomputer bereitgestellt.

Bei mehreren Buildcomputern können Sie jeden Computer einem anderen Zweck zuordnen, wie im folgenden Beispiel beschrieben:

• Einem Buildcomputer können die Build-Agents zugeordnet werden, die fortlaufende Integrationsbuilds verarbeiten. Das Team muss sich auf die schnelle Ausführung dieser Arten von Builds (vor allem abgegrenzte Eincheckbuilds) verlassen können, damit dadurch keine Verzögerungen entstehen. Sie können die Parametereinstellungen für den Buildprozess verwenden, um sicherzustellen, dass Builds schnell ausgeführt werden. Beispiele für diese Einstellungen sind das Deaktivieren der Arbeitsbereichbereinigung, das selektive Ausführen von Tests mit hoher Priorität und das Festlegen der Einstellung Maximale Ausführzeit auf einen niedrigen Wert.

• Ein anderer Buildcomputer kann für geplante Builds und Ad-hoc-Builds zugewiesen werden, deren Verarbeitung viel Zeit erfordert. Die Builddefinitionen für die Build-Agents auf diesem Computer können beispielsweise so festgelegt werden, dass der Arbeitsbereich bereinigt wird, alle Tests durchgeführt werden und eine Analyse des Ausführungscodes erfolgt.

System mit mehreren Computern und Controllern

Das folgende Topologiebeispiel unterstützt Softwareprojekte größerer Unternehmen.

Wie gezeigt, muss jede Teamprojektsammlung über einen eigenen Buildcontroller verfügen. Beachten Sie, wie diese Topologie die Buildcomputer isoliert. Teammitglieder, die mit Teamprojektsammlung A arbeiten, können nur die Build-Agents verwenden, die von Buildcontroller A gesteuert werden.

Nächste Schritte

Da Sie jetzt wissen, wie das Team Foundation Build-System funktioniert, können Sie die nächsten Schritte ausführen:

• Konfigurieren des Buildsystems

• Verwalten des Buildsystems