Skalieren des Buildsystems

Um Team Foundation Build für automatisiertes Erstellen und Testen der Anwendung zu verwenden, müssen Sie zuerst einen Buildserver installieren, einen Buildcontroller und einige Build-Agents hinzufügen und schließlich Ablageordner festlegen. Bei einem kleinen Startteam für ein neues Projekt, können Sie diese Buildsystemkomponenten wahrscheinlich in ein paar Minuten auf einem einzelnen Computer bereitstellen. In dem Maße, in dem das Team und die CodeBase wächst, können Sie das Buildsystem relativ einfach schrittweise erweitern.

Tipp

Wenn die Teamprojektauflistung auf Visual Studio Online gehostet wird, können Sie diese Schritte überspringen und stattdessen, wie nachstehend beschrieben, den gehosteten Buildcontroller verwenden.

Im Folgenden finden Sie einige Beispiele, die veranschaulichen, wie Sie klein und einfach beginnen und das Buildsystem dann später horizontal skalieren können, wenn die Anforderungen größer werden.

• Visual Studio Online mit gehostetem Buildcontroller

• Visual Studio Online mit lokalen Buildservern

• Buildsystem für Probeverwendung oder ein sehr kleines Team

• Buildsystem für ein kleines Team

• Mehrfachbuildserversysteme

• Buildsystem zur Unterstützung mehrerer Teamprojektauflistungen

• Nächste Schritte

Visual Studio Online mit gehostetem Buildcontroller

Wenn die Teamprojektauflistung auf Visual Studio Online gehostet wird, können Sie möglicherweise den gehosteten Buildcontroller verwenden, anstatt eigene Buildserver bereitzustellen.

Weitere Informationen erhalten Sie unter Verwenden des gehosteten Buildcontrollers in einer Teamprojektauflistung, die auf Visual Studio Online gehostet wird.

Visual Studio Online mit lokalen Buildservern

Wenn die Teamprojektauflistung auf Visual Studio Online gehostet wird und das Team eine größere Skalierung oder benutzerdefinierte Build-Agents benötigt, können Sie eine Verbindung zwischen den lokalen Buildservern und Visual Studio Online herstellen.

Buildsystem für Probeverwendung oder ein sehr kleines Team

Wenn Sie Team Foundation Server probeweise verwenden oder mit einem sehr kleinen Team arbeiten, gilt möglicherweise die folgende Topologie für Sie.

Diese Topologie funktioniert möglicherweise für ein Team, das Builds selten und nur während der Randzeiten ausführt, beispielweise ein Team, das nur einen einzelnen nächtlichen Build ausführt. Für viele Teams ist das allerdings aus folgenden Gründen nicht ausreichend:

• 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 Computers. Siehe Build-Server: Verstehen der Sicherheitsrisiken.

Buildsystem für ein kleines Team

Wenn Sie in einem kleinen Team mit lokalem Team Foundation Server arbeiten, sollten Sie folgende Topologie berücksichtigen:

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 Buildserver ausführen. Die Topologie 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 Buildservers.

Mehrfachbuildserversysteme

In dem Maße, in dem die Größe des Teams und der CodeBase zunimmt, können Sie inkrementell Ressourcen hinzufügen, um die Anforderungen zu erfüllen. Beispielsweise können Sie einen zusätzlichen Controller und Build-Agents hinzufügen.

Das Verwenden von Buildcontroller A auf dem Computer der Anwendungsebene stellt aus Prozessorsicht generell kein Problem dar. Allerdings sollten Sie den Buildcontroller aufgrund der bereits erwähnten Probleme mit der Arbeitsspeicherauslastung und der Angriffsfläche auf einen anderen Server verlegen.

Bei mehreren Buildservern können Sie jeden Server, wie in den folgenden Beispielen beschrieben, einem anderen Zweck zuordnen:

• Ein Buildserver auf einem Hochleistungscomputer, der auf Build-Agents dediziert ist, die Builds mit fortlaufender Integration oder abgegrenztem Eincheckvorgang 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.

• Ein Buildserver, der auf nächtlich geplante BVT Builds dediziert ist, die viel Zeit erfordern, um Prozesse wie große Testläufe und Codeanalyse auszuführen.

• Ein Buildserver, der auf spezialisierte Aufgaben wie das Erstellen und Testen einer Windows Store-App vorbereitet und dediziert ist.

Tipp

In solchen Szenarien können Sie Tags auf spezialisierte Build-Agents anwenden und dann die Builddefinitionen auf die Verwendung von Build-Agents mit dem richtigen Satz von Tags einschränken.Siehe Zuweisen von Tags zum Darstellen von Build-Agent-Funktionen oder -Zwecken, Angeben welche Build-Agents den Build für einen einfachen Standardbuildprozess verarbeiten und Ausführen von Aktivitäten auf Build-Agents für einen erweiterten benutzerdefinierten Buildprozess.

Buildsystem zur Unterstützung mehrerer Teamprojektauflistungen

Das folgende Buildsystemtopologiebeispiel könnte Softwareprojekte größerer Unternehmen unterstützen.

Wie weiter oben gezeigt, muss jede Teamprojektauflistung über einen eigenen Buildcontroller verfügen. Beachten Sie, wie diese Topologie die Buildserver isoliert. Teammitglieder, die mit Teamprojektsammlung A arbeiten, können nur die Build-Agents verwenden, die von Buildcontroller A gesteuert werden. Diese Einschränkung kann in Situationen nützlich sein, in denen Sie den Zugriff auf vertraulicheres geistiges Eigentum eng steuern müssen.

Nächste Schritte

• Bereitstellen und Arbeiten mit einem Buildserver
  Um Team Foundation Build mit einem lokalen Team Foundation Server zu verwenden, müssen Sie mindestens einen Buildserver bereitstellen. Sie können auch eine Verbindung zwischen einem oder mehreren lokalen Buildservern und Visual Studio Online herstellen.

  Tipp

  Wenn Sie das System horizontal sklalieren, können Sie einen vorhandenen Buildserver bei Bereitstellen eines neuen Buildservers ersetzen.Beispielsweise können Sie die gleiche Konfiguration und den gleichen Satz von Buildcontrollern und Build-Agents auf einem neuen, leistungsfähigeren Computer hosten.Siehe Einrichten des Team Foundation-Builddiensts.

• Bereitstellen und Konfigurieren eines Buildcontrollers
  Verwenden Sie einen Buildcontroller, um mindestens einen Build-Agent zusammenzulegen. Sie können auf einem Buildserver einen Buildcontroller hosten.

• Bereitstellen und Konfigurieren von Build-Agents
  Verwenden Sie einen Build-Agent für die prozessorintensiven Arbeiten des Builds. Hierzu zählt das Abrufen von Dateien aus der Versionskontrolle, das Bereitstellen des Arbeitsbereichs, das Kompilieren des Codes sowie das Ausführen von Tests.

• Einrichten von Ablageordnern
  Sie können einen oder mehrere Ablageordner vorbereiten und dann festlegen, damit dem Team Binärdateien, Testergebnisse und Protokolldateien durch das Buildsystem bereitgestellt werden können.

• Ein Buildsystem verwalten
  Nachdem Sie den Buildserver bereitgestellt haben, können Sie ihn von der Team Foundation-Verwaltungskonsole aus verwalten. Sie können den Buildcontroller und die Build-Agents entweder über die Team Foundation-Verwaltungskonsole oder aus Visual Studio heraus verwalten.

• Verwenden von Team Foundation Build
  Sobald das Buildsystem eingerichtet ist, ist das Team bereit zum Erstellen eines einfachen Buildprozesses (beispielsweise ein fortlaufender Integrations-Build) und kann den Vorteil nutzen, dass die App automatisch erstellt und getestet wird.