Friday, November 29, 2013

NuGet 2.8 in Jan 2014: Disallow pushing same version

Die stattfindende zunehmende Hinwendung zur Praxis der Buildautomatisierung ist sehr zu bergüßen. Ein diesbzgl. Kernaspekt ist dass bei Änderungen am produktiven Code-Repository sehr schnelles Feedback über den Zustand des Gesamtsystems möglicht ist; angefangen bei der grundlegenden Frage: "lässt sich der Code noch kompilieren?".

Eine zweite Entwicklung ist ebenfalls sehr zu begrüßen, nämlich die Hinwendung zur zeitgemäßen Modularisierung in Form von Paketen mittels sog. Binary Repositories. Der Kerngedanke dabei ist, wiederwendbare Bibliotheken nicht in jedem Projekt neu zu übersetzen sondern direkt in binärer Form zu nutzen. Die Nachvollziehbarkeit der Paket-Versionen genießt dabei einen hohen Stellenwert. In der Regel wird dabei die sog. semantische Verisonierung verwendet. Ingesamt hat die Praxis des Dependency Managements mit Binary Repositories viele Vorteile, die hier aufzuzählen den Rahmen sprengen würde und von denen der Geringste einfach die Verkürzung der Build-Zeiten ist.

Anders als bei Applikationen beinhaltet die Buildautomatisierung von Bibliotheken nicht ein Deployment einer lauffähigen Software sondern das Deployment eines Paketes in ein Binary Repository wie Maven oder NuGet. Ebenso wichtig ist allerdings die konsistente Versionierung:-Artefakt Software-Artefakt "ausgeliefert" kann die Verwendung ein- und derselben Versionsnummer zu vielerlei Problemen führen.

Eine grundlegende Anforderung der Buildautomatisierung ist daher, den Build fehlschlagen zu lassen falls es
  1. den Code-Änderungen gibt (ansonten müsste ja nicht gebaut werden)
  2. die Versionsnummer nicht geändert wurde und
  3. schon "eine Auslieferung existiert".
Im Falle der Pakteverwaltung ist das zwar bisher mit den meisten Repositories schon prinzipiell möglich, erfordert noch einige Zuarbeit. Konkret für NuGet steht diese Frage schon seit mehreren Jahren im Raum (vgl. dazu diesen Beitrag bei StackOverflow). Im aktuellen NuGet-Master-Branch habe ich das entsprechende Feature aber schon gesehen. Es soll mit der NuGet-Version 2.8 kommen die für Januar 2014 geplant ist.

Das Datum sollten wir uns merken, denn dann ist es leicht möglich die Buildautomatisierung von NuGet-Pakten um eine bedeutende menschliche Fehlerquelle zu erleichtern.

No comments:

Post a Comment