Marc Müller 4tecture GmbH

„Wie wir alle wissen, liegt der Grundstein für den Erfolg einer guten ALM- oder DevOps-Umgebung in der auf die konkreten Problemstellungen hin angepassten Automatisierungen. Genau hier spielt uns die neue Umgebung in die Hand.“

Mit dem Team Foundation Server 2015 brachte Microsoft ein neues Build-System auf den Markt. Seit Update 2 steht auch Release Management in einer neuen Auflage bereit, das auf dem neuen Build-System aufbaut. Es ist also an der Zeit, die neuen Systeme mit der gesammelten Praxiserfahrung unter die Lupe zu nehmen.

Wer schon des Längeren Team Foundation Server (TFS) als zentrale Application-Lifecycle-Management-Plattform einsetzt, hat sich unweigerlich mit MSBuild und/oder XAML-basierten Build-Workflows auseinandergesetzt. Gerade in kleineren Teams, die keinen dedizierten Build-Verantwortlichen haben, ist die eine oder andere Optimierung oder Anpassung auf der Strecke geblieben, da die bisherigen Technologien eine eher hohe Komplexität aufwiesen. Ebenso stießen bei einigen Systemverantwortlichen die Controller/Agent Deployments pro Team Project Collection nicht gerade auf Begeisterung, da dadurch die notwendige Infrastruktur bei vielen Collections aufgeblasen wurde. Grund genug dachte sich wohl Microsoft und entwickelte ein neues Build-System.

Einfachheit und Effizienz sind sicherlich die zwei Eigenschaften, die einem als Erstes auffallen, wenn man sich mit dem neuen Build-System vertraut macht. Die Anforderungen an die Applikationsentwicklung und entsprechend auch an die darunterliegenden Entwicklungstools hat sich in den letzten Jahren stark verändert. Wo früher mit einem Team Foundation Server „nur“ mit Microsoft-Technologien entwickelt wurde, ist heute eine plattformübergreifende Umgebung schon fast als Standard zu definieren. Entsprechend offen stellt sich die neue Implementierung vor. Aktuell gibt es einen Windows Build Agent sowie einen Node.js-basierten Cross Platform Agent, die die einzelnen Build-Tasks bearbeiten. Richtig, wir sprechen nun nicht mehr von einem komplexen Workflow, sondern von einzelnen Tasks, die als so genannte Build Steps hintereinander bearbeitet werden. Die Einfachheit der Build-Definition setzt sich auch in der Build-Infrastruktur fort. Neue Agents werden in einem Pool direkt auf TFS-Deployment-Ebene registriert, d. h. die Abhängigkeit zu einer Team Project Collection entfällt, und eine einzige Build-Infrastruktur könnte für alle Team Project Collections (TPC) und Team Projects (TP) verwendet werden. Die Kommunikation zwischen Agent und TFS erfolgt per HTTP oder HTTPS von Agent zu TFS Server. Zu guter Letzt sei noch erwähnt, dass sich ein Agent mittels Copy Paste Deployment installieren und mittels einer einfachen Konfiguration in Betrieb nehmen lässt. Dies hört sich fast zu gut an, wo liegen also die Nachteile? Viele lassen sich auf den ersten Blick nicht finden. Natürlich ist es die erste Version einer neuen Implementierung, und es sind noch nicht alle Ecken und Kanten beseitigt; durch die kurzen Releasezyklen und die Offenheit ist das aber nicht zu stark zu bewerten. Alle, die sehr viel in die bisherigen XAML-basierten Build-Definitionen investiert haben, werden es jedoch nicht gerne hören: Es gibt keinen Migrationspfad. Die beiden Systeme sind so unterschiedlich aufgebaut, dass die Build-Definitionen neu aufgebaut werden müssen. Wer schon bei den XAML-basierten Build-Workflows auf PowerShell-Skripte als Erweiterungspunkte gesetzt hat, dürfte diese Erweiterungen jedoch ohne großen Aufwand von Hand auf das neue System migrieren können.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 6.16 - "Entity Framework – die neue Generation"

Alle Infos zum Heft
243066Build und Release mit dem Team Foundation Server 2015
X
- Gib Deinen Standort ein -
- or -