Neu in TFS 2018: Neues für Build und Release Extensions

Extensions bieten die Möglichkeiten den TFS um weitere Funktionalität an vordefinierten Stellen, sogenannten Extension Points, zu erweitern. Im Build- und Releasemanagement gibt es hierfür einige Anwendungsfälle: zusätzliche Menüeinträge an Build- und Release Definitionen, eigene Tasks, zusätzliche Informationen in Build- und Release Zusammenfassungen (Build- und Release Summary), u.v.m.

In vorhergehenden Beiträgen unserer Blogserie “Neu in TFS 2018” wurden bereits einige spannende Neuerungen für das Build- und Releasemanagement für die neueste Major Version des TFS, wie z.B. Task Groups, beschrieben. Mit diesem Blogbeitrag möchten wir Ihnen nun die Neuigkeiten für Extension-Entwickler(innen) in diesem Bereich näherbringen sowie zwei Neuerungen für server-seitige Tasks im Release Management.

Hilfe, meine Testergebnisse stimmen nicht – was nun?

Seit Einführung des neuen JSON-Build Systems im TFS steht auch der Build Task Run Functional Tests zur Verfügung. Dieser ermöglicht die Ausführung von Selenium – und anderen funktionalen Test-Frameworks durch einen Test Agent auf einer Menge von Remote-Maschinen (d.h. auf Rechnern ohne Build Agent). Mit diesem ist es möglich nicht nur Tests auf Basis von Test Assemblies auszuführen, sondern auch Test Suiten zu verwenden. In letzterem Fall werden alle darin enthaltenen Test Cases, welche mit einer automatisierten Test Methode verknüpft sind und somit den Automation Status = Automated aufweisen, ausgeführt und die Ergebnisse der Test Cases im TFS automatisch gesetzt. Für datengetriebene Tests jedoch kann es vorkommen, dass Test Cases fälschlicherweise als Passed markiert werden. Damit verlieren die Ergebnisse der automatisierten Testläufe innerhalb der ausgeführten Test Suiten ihre Aussagekraft.

Hilfe, meine TFS Collection Datenbank ist riesig!

Eine TFS Collection Datenbank wächst stetig an. Das ist völlig normal. Dabei kann es immer wieder Phasen geben, in denen das Wachstum stärker oder schwächer ausgeprägt ist. Auch hier schellen meistens noch keine Alarmglocken. Erst wenn ein vorher eingestellter Schwellwert (z.B. DB-Größe, Festplattenauslastung, Backup-Zeiten) erreicht wird, sucht man nach Ursachen und Möglichkeiten.

Dependency Manager – Abkündigung der XAML-Build-Aktivitäten

Das neue Build-System in Visual Studio Team Services (VSTS) bzw. im Team Foundation Server (TFS) gewinnt immer mehr an Bedeutung. Deshalb haben wir uns nach reiflicher Überlegung entschieden, die Unterstützung der XAML-Build-Aktivitäten CleanDependencies und GetDependencies im AIT Dependency Manager abzukündigen. An der aktuellen Produktversion ändert sich nichts, alles funktioniert wie gewohnt. Bei zukünftigen Releases werden wir…

HoloLens: Automatisierter Build

Wer seine HoloLens-App im Source Control hat, der möchte diese natürlich auch irgendwann zentral kompilieren. Dadurch wird nicht nur sichergestellt, dass der Source Code überall kompilierbar ist, sondern es gibt auch eine zentrale Stelle, an dem das UWP-Paket erstellt wird, welches später im Marketplace veröffentlicht oder direkt auf der HoloLens installiert werden kann. In diesem Teil der Blogserie soll beschrieben werden, was benötigt wird, um automatisiert aus einem Unity-Projekt ein UWP-App-Paket zu bauen.

ALM kompakt: Copy and Publish Build Artifacts vs Copy Files und Publish Build Artifacts

Wer schon einmal in seinem Build verschiedene Dateien kopieren und als Artifakte ablegen wollte, der kommt an den Tasks Copy Files und Publish Build Artifacts nicht vorbei. Wer beide Tasks kombinieren möchte kann Copy and Publish Build Artifacts verwenden.

Sofern jemand seine Dateien nicht kopieren möchte, um diese vor dem Publish noch anzupassen, lassen sich beide ähnlich anwenden. Es kann ein Quellverzeichnis ausgewählt und mehrere Dateien über ein Minimatch-Pattern selektiert werden. Anschließend lässt sich ein Artifaktname und der Artifakttyp angeben. Doch wo genau unterscheiden sich diese nun?

ALM Kompakt: Versionieren von Assemblies im Build-Prozess

Um welche Version der Software handelt es sich denn?

Diese Frage wird spätestens dann gestellt, wenn die Software den Entwickler-PC verlässt und von Endanwendern getestet wird. Beim Reproduzieren und fixen von Fehlern ist die Angabe einer Verionsnummer und die Rückverfolgbarkeit zu dem passenden Quellcode-Stand eine zentrale Information. Doch wie werden Versionsnummern richtig vergeben?

Rückblick auf die //Build 2016/

Die Softwareentwicklung unterliegt ständigen Veränderungen und Neuerungen. Einer der wichtigsten Zeitpunkte, in denen die Microsoft-Entwicklergemeinde von Neuerungen erfährt, ist die Build. Ich hatte die Gelegenheit, die Neuerungen vor Ort zu erfahren und mich 3 Tage lang mit den Experten zu verschiedensten Themen auszutauschen. Im Folgenden möchte ich meine ganz persönlichen Eindrücke schildern. Die mit Spannung…

Neu in TFS 2015 – Das Build-System mit Node.js

In einem vorigen Blog-Artikel hatte ich das neue Build-System vorgestellt. Auch in jenem Standard-Szenario eines Builds einer .NET-Solution bietet das neue Build-System einige Verbesserungen. Im heutigen Artikel möchte ich nun auf einen weiteren großen Vorteil eingehen: Builds für verschiedene Technologien – nicht nur aus der Microsoft-Welt. Anhand einer Build-Definition für eine Node.js-App zeige ich, dass das neue Build-System einfach und schnell erweitert und angepasst werden kann.

image