Innovations-Nummer +49 (0)7304 / 803 0

Blog-n-Roll:
Wissen,
das rockt!

ALM

2016.01.31

Päckchen packen mit NuGet, TFS 2015 und Build vNext. Teil 3: Pakete verteilen
By admin / 31 January / ALM, Entwickler / 0 comm.

Funktionalität automatisiert für andere Anwendungen bereitstellen Anmerkung: Dies ist die für Visual Studio / TFS 2015 und Build vNext überarbeitete Version unseres Artikels auf entwickler.de. Es hat sich Einiges getan: Das neue Buildsystem vereinfacht das zentrale Erstellen und Bereitstellen von NuGet-Paketen erheblich, und die NuGet-Integration in Visual Studio Team Services bietet einen einfachen weg, eigene […]

Funktionalität automatisiert für andere Anwendungen bereitstellen Anmerkung: Dies ist die für Visual Studio / TFS 2015 und Build vNext überarbeitete Version unseres Artikels auf entwickler.de. Es hat sich Einiges getan: Das neue Buildsystem vereinfacht das zentrale Erstellen und Bereitstellen von NuGet-Paketen erheblich, und die NuGet-Integration in Visual Studio Team Services bietet einen einfachen weg, eigene Paket-Feeds in der Cloud zu hosten. Viel Spaß! Der Open Source-Paketmanager NuGet hat sich in der .NET-Welt zur Standardmethode einwickelt, um Funktionalität zwischen mehreren Projekten zu teilen oder öffentlich bereitzustellen – fast jeder Programmierer hat schon ein NuGet-Paket in sein Projekt eingebunden. Doch NuGet kann mehr: Es bietet die Möglichkeit, wichtige Teile des Entwicklungsprozesses innerhalb der eigenen Organisation weiter zu verbessern und zu automatisieren.

Blogserie


 

Ein eigener NuGet-Server

Im vorigen Teil dieser Artikelserie haben wir gelernt, lokal oder per Team Build Pakete zu schnüren. Jetzt geht es an die sichere und komfortable Auslieferung. In der einfachsten Variante ist, wie wir gesehen haben, fast kein Aufwand nötig: Es genügt ein Netzwerkshare, auf den alle Konsumenten Zugang haben. Dieses kann im Package Manager in Visual Studio als Package Source angegeben werden, und schon stehen die Pakete auf dem Share zur Einbindung in eigene Projekte zur Verfügung. Etwas eleganter ist die Einrichtung eines eigenen, webbasierten NuGet-Servers, der im IIS lebt, über HTTP ansprechbar ist und den Abruf und das Veröffentlichen (nuget push) von Paketen über das Web unterstützt – denn Netzwerkshares sind – wenn überhaupt – nur in lokalen Netzwerken praktikabel. Auch die Bereitstellung eines “echten” Servers geht erschreckend einfach: Es genügt, eine leere ASP.NET-Applikation zu erzeugen und dort –  natürlich per NuGet  – das Paket NuGet.Server einzubinden. Dieser “NuGet-Server-In-A-Box” bringt alles mit, was benötigt wird. image image In der web.config des Projekts können einige wichtige Einstellungen vorgenommen werden:
  • Passwort: Ein API Key dient als Passwort für den Upload von Paketen auf den Server. Der Key kann frei als alphanumerisches Schlüsselwort angegeben werden: <add key=”requireApiKey” value=”true”/> <add key=”apiKey” value=”1234567890″/>
  • Paketpfad: Standardmäßig werden die Pakete im Ordner Packages innerhalb unseres Web-Projektes abgelegt. Mit der Einstellung packagesPath kann ein anderer Ort angegeben werden – Achtung, Berechtigungen nicht vergessen! <add key=”packagesPath” value=””/>
  • Pakete überschreiben: Normalerweise ist nicht vorgesehen, dass Pakete auf dem Server überschrieben werden können, da dies ja das Verhalten der Anwendungen verändern könnte, die das Paket konsumieren. Dieses Verhalten kann jedoch über den Parameter allowOverrideExistingPackageOnPush konfiguriert werden.
image Schließlich kann der NuGet Server per Web Publish auf einem IIS installiert werden und steht fortan als Paketquelle zur Verfügung: image Der neue NuGet-Server erzählt freundlicherweise gleich auf der Startseite, wie man ihn mit Paketen bestückt: Per lokalem Directory (das auch als Share freigegeben werden kann) oder nuget push-Befehl. nuget push {package file} -s http://tfs-2015-1:9000/ {apikey} Statt die Kommandozeile zu bemühen, werden wir gleich unseren Team Build aufrüsten, um den Server automatisch mit Ware zu beliefern. Dazu fügen wir der aus dem letzten Teil bekannten Builddefinition einen weiteren Build Step hinzu: den NuGet Publisher. image Der NuGet Publisher Step erwartet als Konfigurationsparameter einen sogenannten Endpoint – einen Datensatz mit Informationen über den Server. Das ist schnell erledigt – der Klick auf Manage führt direkt in den entsprechenden Einstellungsdialog im TFS: image Benötigt wird ein Generic Endpoint… image … mit den Daten des NuGet-Servers. Der Benutzername bleibt leer, unter Passwort/Token Key wird der API Key eingetragen, den wir bei der Einrichtung des NuGet-Servers in der web.config festgelegt haben. image Jetzt kann der entsprechende Endpoint im NuGet Publisher-Build Step ausgewählt werden. Gleichzeitig setzen wir auch noch die Maske für die zu veröffentlichenden Pakete. In unserem Fall wird nur veröffentlicht, wenn der Paketname mit HelloLib beginnt – anderenfalls werden auch andere referenzierte Pakete (wie in unserem Beispiel log4net) auf den Server geschoben. Als letzter Schritt löschen wir im NuGet Packager Step das Feld für den Zielpfad – damit wird das erstellte Paket direkt in den Buildordner geschrieben, wo der NuGet Publisher es finden kann. image Nun sind wir bereit, das erste Paket automatisiert auf unserem Server zu veröffentlichen. Also: Queue New Build! image Waren alle Einstellungen richtig, strahlt der Build in frischem Grün, und auf dem NuGet-Server steht ein neues Paket bereit. image Eine einfache Liste zeigt die verfügbaren Bibliotheken (noch nicht sehr viele…) und über ein Suchfeld können bestimmte Pakete einfach lokalisiert werden. Ein Atom-Feed erfreut alle alle Nutzer, die über neue Pakete informiert werden wollen. Die Einbindung des taufrischen NuGet-Servers in Visual Studio geschieht, wie gehabt, über den Einstellungen-Dialog des Paketmanagers. Achtung dabei: Der Paket-Feed steht im Unterverzeichnis /nuget,bereit, das an die URL angehängt werden muss – aufmerksame Leser haben das schon auf der Startseite des Servers gelesen (always read the manual!). image Und schließlich kann der neue Server zum ersten Mal Pakete ausliefern. image Da wir das HelloLib-Paket neu gebaut haben und sich die Versionsnummer erhöht hat, die Hello World-Applikation aber noch das “alte” Paket referenziert, steht für HelloLib jetzt ein Update bereit – erkennbar an der blauen Eins neben dem Update-Tab. image Das Update für die HelloLib-Bibliothek kann jetzt eingespielt werden. image Und so steht mit wenig Aufwand ein firmeninterner – oder sogar öffentlicher – Server bereit, auf den Teams Ihre Komponenten als Pakete zum Konsum für andere Teams zur Verfügung stellen können – inklusive einfacher Updatemöglichkeit. Dabei behalten die Konsumenten immer die Kontrolle und können entscheiden, ob und wann sie auf eine neue Version eines Pakets umsteigen.

Go Pro – professionelle Package-Server, lokal und in der Cloud

Wer in seiner Organisation in großem Stil mit NuGet arbeitet hat unter Umständen jedoch höhere Anforderungen an Skalierbarkeit, Verwaltbarkeit und Sicherheit als der vorgestellte einfache Nuget.Server bieten kann. Hier bietet sich ein kommerzielles Produkt wie ProGet an, das speziell für solche Einsatzzwecke entwickelt wurde. ProGet bietet unter anderem die Möglichkeit mehrere Feeds zu definieren, erlaubt eine ausgefeilte Security-Konfiguration mit ActiveDirectory-Integration, eignet sich für Load Balancing, kann fremde Feeds filtern, archivieren und durchschleifen, bietet wesentlich bessern Bedienkomfort und vieles mehr. Der Preis ist für große Firmen angemessen – und für kleine Teams ist eine freie Version verfügbar, die bereits wesentliche Features mitbringt. image Eine weitere gute Alternative in der Cloud ist der neue Package Management Service  in Visual Studio Team Foundation Services, der ebenfalls umfangreiche Features mitbringt. Eine ausführliche Dokumentation findet sich auf der Microsoft Visual Studio-Seite.

Fazit und Ausblick

Pakete konsumieren, erstellen und verteilen – all das können wir jetzt schon. Aber was, wenn ein eingebundenes Paket Probleme macht? Im letzten Teil der Artikelserie widmen wir uns einem Punkt, der oft für Frust bei NuGet-Nutzer sorgt – dem Debugging von Paketen. Dabei ist auch für diese Herausforderung die Lösung nicht sehr weit. Bleiben Sie dran!
Nach oben