Sie sind hier
E-Book

TFS 2012 TFS 2012 Team Build - Architektur und Installation

Architektur und Installation

AutorMichael Klei, Tobias Richling
Verlagentwickler.press
Erscheinungsjahr2013
Seitenanzahl65 Seiten
ISBN9783868024746
FormatePUB
KopierschutzWasserzeichen
GerätePC/MAC/eReader/Tablet
Preis4,99 EUR
Eine Software zu erstellen, geht weit über das Kompilieren im Visual Studio hinaus. Der Erstellungsprozess bezieht mehrere Lösungen mit ein und erzeugt Kompilate verschiedenen Typs, zum Beispiel Clientapplikationen, Dienste und ein Setup. Im Zuge der Erstellung müssen automatisierte Tests ausgeführt werden, die Änderungen seit dem letzten Build ermittelt und bei erfolgreicher Ausführung die fertigen Dateien für den Tester oder die Auslieferung bereitgelegt werden. Für verschiedene Codelinien wie Entwicklung, Main oder die Releases müssen verschiedentlich getaktete Builds definiert werden. In diesem shortcut werden ausgehend von einem Branch-Modell Build-Definitionen erzeugt. Zudem gibt es Erläuterungen zu privaten Builds, dem Workflow, den Reaktionsmöglichkeiten auf Build-Ereignisse.

Tobias Richling ist 28 Jahre alt und lebt im Münsterland. Er hat Wirtschafts-informatik studiert und während und nach seiner Studienzeit als Software-entwickler und IT-Trainer gearbeitet. Seine Kernkompetenzen sind Micro-soft-Technologien, von C# und SQL Server bis hin zu WCF, ASP.NET und Silverlight. Er ist außerdem regelmäßig als Sprecher auf Fachkonferenzen und als Autor tätig. Michael Klei ist bereits seit den 90er Jahren als Consultant und Entwickler im Microsoft-Umfeld tätig. Mit seiner Firma meta-objects.NET IT Solutions GmbH bei Osnabrück entwickelt er auf Basis von Microsoft-Technologien Individualsysteme, unterstützt bei der Geschäftsprozessoptimierung, integriert innovative Neuentwicklungen in bestehende Systemlandschaften und baut damit Brücken zwischen Mensch und Maschine. Als Coach, Berater und Microsoft Certified Trainer gibt er seine Erfahrung und Leidenschaft für die Softwareentwicklung im Team in Workshops und Seminaren weiter.

Kaufen Sie hier:

Horizontale Tabs

Leseprobe

2 Grundlagen

2.1 Architektur

Der Team Build ist als Bestandteil des TFS natürlich in die Gesamtarchitektur eingebunden. Dementsprechend benötigt er einen TFS und dessen Datenbanken, um grundsätzlich zu funktionieren. Darüber hinaus gibt es zwei wesentliche logische Komponenten, die den Team Build ausmachen: der Build-Controller und der oder die Build-Agenten. Beide sind Bestandteile des Build Service.

Logische Architektur

Der Build Service ist die logische Einheit, die die Grundlage für Controller und Agenten darstellt. Der Build-Dienst muss auf jedem Rechner installiert sein, auf dem ein Controller und/oder ein Agent ausgeführt werden soll.

Der Build Controller nimmt alle Build-Anforderungen entgegen, legt die Ausführungsreihenfolge fest und startet die Ausführung der Builds. Auf einem physikalischen Rechner kann nur jeweils ein Build Controller installiert werden, der immer einer Teamprojektsammlung zugeordnet ist. Die Abarbeitung eines Build-Laufs beginnt auf dem Controller, auf dem Initialisierungsarbeiten erledigt werden. Die Hauptarbeit für die Durchführung der Builds delegiert der Controller an einen Build Agent. Die Arbeit des Build Controllers erfordert nicht viel CPU-Leistung, kann aber speicherintensiv sein – also lieber mehr Speicher als leistungsstarker Prozessor (Abbildung 2.1).

Abbildung 2.1: Logische Team-Build-Architektur

Der Build Agent führt die Hauptarbeit bei der Ausführung von Builds aus. Jeder Build Agent ist einem Build Controller zugeordnet, der für ihn verantwortlich ist um ihm die Ausführung eines konkreten Builds zuweist. Während es pro Teamprojektsammlung genau einen Build Controller geben kann, können mehrere Build Agents existieren. Jeder Build Agent kann zur gleichen Zeit nur einen Build ausführen. Wenn mehr Builds angefordert werden als Build Agents verfügbar sind, werden diese vom Controller in einer Warteschlange gesammelt. Sie können auf dem gleichen Rechner wie der Build Controller laufen, oder auf separaten Maschinen. Auf einem physikalischen Computer können auch mehrere Build Agents ausgeführt werden. Da der Build Agent die rechenzeitintensiven und datenlastigen Tätigkeiten im Team Build übernimmt, sollten nicht zu viele Agents auf einem Rechner laufen. Wenn man mit der Einrichtung einer Build-Umgebung beginnt, kann man mit einer kleinen Anzahl an Agents beginnen – für den Anfang tut es für gewöhnlich ein einziger. Später wird die Anzahl der durchzuführenden Builds eventuell steigen, dann kann man weitere Agents ins System bringen. Es ist auch möglich, Agents für spezielle Aufgaben einzurichten, zum Beispiel einen Agents, der nur nächtliche Builds durchführt, oder eine Gruppe von Agents, die nur Continuous Integration Builds durchführen. Zu diesem Zweck kann man Agents Tags zuweisen. Bei der Definition eines Builds können ebenfalls Tags angegeben werden. Der Build Controller versucht dann, einen freien Agent zu finden, der mit den angegebenen Tags übereinstimmt.

Physikalische Architektur

Es gibt verschiedene Möglichkeiten, die logischen Komponenten auf physikalische Computer zu verteilen. Alle gezeigten Ansätze gehen von einer Teamprojektsammlung aus, für jede weitere Sammlung wird jeweils ein weiterer Build Controller fällig, der auf einem eigenen Rechner laufen muss und somit wiederum mit jedem Architekturansatz kombiniert werden kann. Drei mögliche Architekturansätze sind in Abbildung 2.2 zusammengefasst.


Abbildung 2.2: Drei mögliche physikalische Team-Build-Architekturen

Die einfachste Topologie ist die, alle Komponenten auf einer Maschine zu installieren (in der Abbildung ganz links). Die Vorteile dieser Variante liegen auf der Hand: Sie ist einfach zu installieren und zu warten, und es fallen relativ geringe Hardwarekosten an. Für Einzelentwickler lässt sich dieses Setup auf dem Notebook einrichten und betreiben. Für kleine Teams reicht ein PC mit normaler Desktop-Hardware. Abhängig von der Anzahl der Builds, Teamprojekte und Entwickler kann man die Rechnerleistung langsam steigern. Wenn man leistungsfähige Server-Hardware einsetzt, kann man bis zu 15 Entwickler mit dieser Installation bedienen. Dieses Deployment läuft auch auf virtuellen Maschinen sehr gut.

Die erforderliche Rechenleistung hängt wesentlich von der Anzahl und dem Umfang der durchzuführenden Builds ab. Die Versionskontrolle hat relativ moderate Anforderungen, mit durchschnittlicher Hardware kann man auch größere Teams bedienen. Solange nur ein Build parallel ausgeführt werden muss, reicht auch ein einzelner Rechner aus. Es kann aber leicht zu einer Situation kommen, wo mehrere Builds parallel laufen sollen. Dies ist nur möglich, wenn auch mehrere Build Agents vorhanden sind. Und dann wird es auf einer Maschine schnell eng. In diesem Fall kann man das erste Szenario erweitern, indem man einen weiteren Rechner aufsetzt und dort weitere Build Agents installiert (in der Abbildung mittig). Es ist für durchschnittliche Deployments problemlos möglich, den Build Controller auf einem Rechner mit den übrigen TFS-Diensten laufen zu lassen und nur die Agents auf weitere Knoten zu verteilen. Natürlich kann der Build Controller auch auf einem separaten Rechner installiert werden.

Sollte auch dieser Umfang nicht mehr ausreichen, kann man auf die große Variante zurückgreifen und alle Komponenten separat installieren (in der Abbildung links). Bei dieser Größenordnung wird die TFS-Datenbank ebenfalls auf einem eigenen dedizierten Datenbankserver untergebracht, das Application Tier bekommt einen eigenen Rechner, ebenso der Build Controller. Je nach Leistung der einzelnen Build-Knoten können dort ein oder mehrere Agents laufen.

2.2 Installation und Konfiguration

Einrichten eines Computers als Build-Computer

Damit ein Computer als Build-Computer fungieren kann, müssen die entsprechenden Komponenten installiert werden. Im Wesentlichen handelt es sich dabei um den Team Foundation Build Service, der sich in dem Prozess TFSBuildServiceHost.exe manifestiert und in der Regel als Windows-Dienst ausgeführt wird. Die Installation kann auf einem Rechner erfolgen, auf dem keine weiteren TFS-Komponenten installiert sind. In diesem Fall handelt es sich um eine reine Build-Maschine, die separat von der Datenbank und den restlichen Diensten des TFS läuft. Die andere Möglichkeit, für kleinere Teams zu empfehlen, ist es, den Build-Dienst auf dem gleichen Rechner mit den übrigen Komponenten des TFS zu installieren – in diesem Fall bietet es sich an, dies direkt im Anschluss an die Installation zu erledigen. In diesem Fall fährt man in dem Dialog aus Abbildung 2.3 einfach mit dem Punkt Configure Team Foundation Build Service fort.

Abbildung 2.3: Assistent zur Installation der Build-Dienste

Die Installation erfolgt in drei einfachen Schritten. Im ersten Schritt muss eine Teamprojektsammlung angegeben werden, für die der zu installierende Build Controller tätig sein soll. Ein Build Controller kann immer nur für genau ein Teamprojekt zuständig sein, und jede Teamprojektsammlung hat genau einen Build Controller. Auf einer Maschine kann nur genau ein Build Controller installiert werden. Da für jede Teamprojektsammlung ein Controller benötigt wird, empfiehlt sich ggf. die Nutzung von virtuellen Maschinen. Die gewünschte Teamprojektsammlung kann über einen Dialog ausgewählt werden. Der URL der Sammlung wird dann automatisch ermittelt und übernommen. Danach wird angezeigt, wie viele Build Controller und Build Agents bereits für die ausgewählte Sammlung registriert sind und über wie viele Maschinen sie sich verteilen.

Im nächsten Schritt muss festgelegt werden, wie viele Build Agents auf der Maschine laufen sollen. Der Vorschlagswert ist 1, er kann für kleinere Deployments oder zum Testen getrost beibehalten werden. Die Anzahl der parallelen Agents lässt sich später noch erhöhen. Die Agents können parallel laufen und führen die rechenzeitintensiven Vorgänge im Build aus, daher sollte man es je nach CPU-Leistung der Maschine nicht übertreiben.

Schließlich muss noch ein Konto ausgewählt werden, unter dem der Build-Dienst ausgeführt wird. Auch hier kann man sich an den Vorschlagswert halten und das lokale Dienstkonto übernehmen. Wenn bei der Build-Ausführung spezielle Anforderungen an die Benutzerrechte bestehen, kann ein abweichendes Konto angegeben werden.

Der nächste Schritt im Assistenten ist eine Zusammenfassung der getätigten Einstellungen. Es folgt, wie schon bei der Installation des TFS, eine Überprüfung, ob für die Einrichtung des Build-Dienstes alles in Ordnung ist. Ist das der Fall, kann man zur Tat schreiten und wird hoffentlich mit vollem Erfolg belohnt (Abbildung 2.4).

Abbildung 2.4: Erfolgreiche Installation der Build-Dienste

Verwaltung des Build Services

Die Verwaltung des Build Services funktioniert, wie die restliche Konfiguration des TFS, über die Managementkonsole. Dort gibt es in der Navigation einen Bereich Build Configuration (Abbildung 2.5).

Abbildung 2.5: Konfiguration der Build-Dienste

Hier findet man die drei Elemente der logischen Architektur wieder. Ganz oben befinden sich die Informationen darüber, dass der Build-Dienst auf diesem Rechner als lokaler Dienst ausgeführt wird und für welche Teamprojektsammlung dieser Build-Computer arbeitet. Der Dienst kann gestartet, gestoppt, konfiguriert und deregistriert werden. Bei der Deregistrierung können bestehende Controller und Agenten auf diesem Computer für die spätere Reaktivierung gespeichert oder...

Blick ins Buch

Weitere E-Books zum Thema: Sonstiges IT

Citrix Presentation Server

E-Book Citrix Presentation Server
Format: PDF

Der Citrix MetaFrame Presentation Server ist unangefochtener Marktführer unter den Terminalservern für Windows-Systeme. Unternehmen setzen ihn ein, um die Systemverwaltung von Windows-Netzwerken…

Citrix Presentation Server

E-Book Citrix Presentation Server
Format: PDF

Der Citrix MetaFrame Presentation Server ist unangefochtener Marktführer unter den Terminalservern für Windows-Systeme. Unternehmen setzen ihn ein, um die Systemverwaltung von Windows-Netzwerken…

Home Networking

E-Book Home Networking
Format: PDF

Home Networking - das bedeutet die Verbindung der unterschiedlichsten im Haushalt vorhandenen elektronischen Geräte, sei es per Kabel oder drahtlos per Funk. Das beginnt meist mit der Vernetzung von…

Weitere Zeitschriften

Archiv und Wirtschaft

Archiv und Wirtschaft

"Archiv und Wirtschaft" ist die viermal jährlich erscheinende Verbandszeitschrift der Vereinigung der Wirtschaftsarchivarinnen und Wirtschaftsarchivare e. V. (VdW), in der seit 1967 rund 2.500 ...

BIELEFELD GEHT AUS

BIELEFELD GEHT AUS

Freizeit- und Gastronomieführer mit umfangreichem Serviceteil, mehr als 700 Tipps und Adressen für Tag- und Nachtschwärmer Bielefeld genießen Westfälisch und weltoffen – das zeichnet nicht ...

bank und markt

bank und markt

Zeitschrift für Banking - die führende Fachzeitschrift für den Markt und Wettbewerb der Finanzdienstleister, erscheint seit 1972 monatlich. Leitthemen Absatz und Akquise im Multichannel ...

Card-Forum

Card-Forum

Card-Forum ist das marktführende Magazin im Themenbereich der kartengestützten Systeme für Zahlung und Identifikation, Telekommunikation und Kundenbindung sowie der damit verwandten und ...

rfe-Elektrohändler

rfe-Elektrohändler

rfe-Elektrohändler ist die Fachzeitschrift für die CE- und Hausgeräte-Branche. Wichtige Themen sind: Aktuelle Entwicklungen in beiden Branchen, Waren- und Verkaufskunde, Reportagen über ...

EineWelt

EineWelt

Lebendige Reportagen, spannende Interviews, interessante Meldungen, informative Hintergrundberichte. Lesen Sie in der Zeitschrift „EineWelt“, was Menschen in Mission und Kirche bewegt Man kann ...

F- 40

F- 40

Die Flugzeuge der Bundeswehr, Die F-40 Reihe behandelt das eingesetzte Fluggerät der Bundeswehr seit dem Aufbau von Luftwaffe, Heer und Marine. Jede Ausgabe befasst sich mit der genaue Entwicklungs- ...