Das Build-System hat im TFS 2015 eine Runderneuerung bekommen. Was muss man nun aber machen, um eine simple Build-Definition für eine .NET-Solution aufzusetzen? Was bietet das neue System für Vorteile? Dieser Artikel gibt eine kurze Einführung von den Build-Agents über die Build-Schritte bis hin zum Abrufen der Testergebnisse.
Wie im Bild zu sehen, ist die komplette Oberfläche des neuen Build-Systems in das Web-Interface des TFS ausgelagert worden, zu finden im Reiter “BUILD”. Auch im Visual Studio 2015 können nur noch die alten XAML-Definitionen bearbeitet werden. Zum Editieren einer neuen Definition wird man an das Web-Interface weitergeleitet.
Auch die Verwaltung der Build-Agents findet im Web statt. Diese sind nun nicht mehr in Build Controller organisiert, sondern in Agent Pools und Build Queues:
Jede Collection kann mehrere Queues besitzen, wobei jede Queue genau einem Pool zugewiesen ist. Ein Pool ist für jede Collection verfügbar. Jeder Pool kann mehrere Agents benutzen, wobei ein Agent an nur genau einem Pool registriert sein darf. Ein Rechner wiederrum kann mehrere Agents beherbergen.
Damit ist sofort offensichtlich, dass es prinzipiell möglich ist, einen Build-Rechner über alle Collections hinweg zu nutzen. Wir haben also nicht mehr eine strikte Baumstruktur wie zuvor. Das neue System ist durch die Agent Pools flexibler und skalierbarer.
Zudem ist es nun möglich, die Verwaltung der Agenten von Benutzern ohne spezielle Adminrechte in der Collection oder im Projekt vornehmen zu lassen. Zwar werden immer noch Adminrechte für das Anlegen der Queues und Pools benötigt, jedoch hat jeder Pool eine eigene Administratorengruppe, deren Mitglieder Agenten nur bei diesem Pool registrieren und abmelden dürfen.
Microsoft geht nun auch das große Thema Cross-Plattform-Builds an. Somit gibt es momentan 2 Agents: einen Windows-Agent und einen Node.js-Agent für Mac OSX und Linux. Die Installation des Windows-Agents erfolgt über Copy & Paste und die Konfiguration über das Ausführen eines PowerShell-Skripts. Der Node.js-Agent wird als npm-Paket angeboten und die Installation ist ausführlich dokumentiert. Damit können Build-Rechner mit unterschiedlichen Betriebssystem leicht ins Build-System integriert und wiederverwendet werden.
Sind diese ersten Hürden beim Einrichten der Pools, Queues und Agents genommen, kann man eine neue Build-Definition anlegen. Dabei gibt es schon eine Vorlage für eine Visual-Studio-Build-Definition. Diese sieht initial wie folgt aus:
Neu ist, dass der Ablauf des Builds nun durch Build-Schritte definiert werden kann, welche per Drag & Drop in der Reihenfolge verschoben werden können. Wählt man einen Schritt aus, so erscheinen dessen Details auf der rechten Seite. Für den Schritt “Visual Studio Build” kann man z.B. die Solutions mit Wildcards auswählen. Auch der Schritt zum Ausführen der Tests kann konfiguriert werden. Das Veröffentlichen der Testergebnisse ist in diesem Schritt schon fest integriert. Weiterhin werden in der Standardvorlage die Quellen indiziert, die Symbole veröffentlicht und die Build-Ergebnisse können im Server oder auf einem Fileshare veröffentlicht werden.
Ein essentieller Schritt fehlt hier jedoch: das Abrufen der Quellen. Dies kann oben im Reiter “Repository” eingestellt werden.
Die restlichen Einstellungsmöglichkeiten sollten aus den XAML-Definitionen bekannt sein. Ist dies nicht der Fall, so gibt es nützliche Hinweise direkt neben den Konfigurationsfeldern.
Eine wichtige und lang ersehnte Neuerung ist die Versionierung der Build-Definitionen, welche unter dem Reiter “History” zu finden ist.
Generell ist es nun um einiges einfacher Build-Definitionen anzupassen, da keine eigene Domain Specific Language wie XAML verwendet wird. Microsoft scheint hier den “Best of Breed”-Ansatz zu verfolgen und nutzt schon vorhandene Dinge, anstatt das Rad neu zu erfinden.
Hat man nun die Build-Definition nach seinen Wünschen konfiguriert, so kann man einen neuen Build in die Warteschlange einreihen. Hierbei kann man eine Build-Queue auswählen, welche der aktuellen Collection zugeordnet ist. Eine Standard-Queue für eine Build-Definition kann natürlich auch angegeben werden.
Den Fortschritt des Builds kann man live im Web-Interface mitverfolgen. Dabei kann man sehen, dass hinter den Build-Schritten sich tatsächlich simple Skripte verbergen, z.B. für den “Visual Studio Test”-Schritt wird das Skript “VSTest.ps1” ausgeführt, welches Teil des Agents ist.
Nach Beendigung des Builds kann die Übersicht abgerufen werden:
Die Testergebnisse wurden automatisch veröffentlicht und weitere Details können mit Klick auf die Test Results eingesehen werden.
Fazit:
Für eine .NET-Solution kann man eine Standardvorlage einer Build-Definition nutzen. Die gegebenen Build-Schritte decken die häufigsten Szenarien ab und vieles funktioniert Out-of-the-Box. Für alle anderen Individuallösungen kann ganz einfach ein Build-Schritt hinzugefügt werden, der ein PowerShell-Skript ausführt. Es wurde angekündigt, dass es prinzipiell natürlich möglich sei, eigene Build-Schritte zu erstellen, jedoch sollte dies nur gemacht werden, wenn der Schritt sehr generisch angelegt und leicht wiederverwendet werden kann. Ansonsten ist ein Skript zu bevorzugen.
Wie flexibel man dadurch die Build-Definitionen gestalten kann, werde ich in einem kommenden Beitrag anhand einer Build-Definition für eine Node.js App zeigen.