| 

.NET C# Java Javascript Exception

8

Wenn ich von NuGet spreche, tue ich das eigentlich mit großer Begeisterung. Generell finde ich es super, wie ich mit NuGet externe Bibliotheken, Werkzeuge und weitere Abhängigkeiten in mein aktuelles Projekt nehmen kann und – ganz wichtig – auch aktuell halten kann. Ich habe selber ein paar Bibliotheken die ich per NuGet verteile. Mit einem eigenen NuGet Server oder einem einfachen Netzwerk Share ist es möglich interne Bibliotheken innerhalb eines größeren Unternehmens zu verteilen.

Aber…

Jetzt kommt das einzige aber große Aber ;)

Das größte und einzige Problem an NuGet ist das automatische “Package Restore”, mit dem es möglich ist, NuGet Packages automatisch per Visual Studio oder direkt per NuGet wieder herstellen oder Updaten zu lassen.

Das übliche Scenario ist ein Build-Server, der vor dem Build alle Pakete lädt und oder aktualisiert. Dadurch ist es nicht mehr nötig Pakete in das Source-Code Repository einzuchecken, wodurch sich die Größe des Repositories erheblich reduzieren kann

Im ersten Moment scheint das ein nützliches Feature zu sein. Plattenplatz sparen UND Abhängigkeiten automatisch auflösen zu lassen. Klasse :)

Wo ist der Haken? Warum sehe ich genau das als Problem?

Wie oben angedeutet, sehe ich NuGet nur als Paket-Verteilungswerkzeug. Mehr nicht. Ich verteile Bibliotheken per NuGet oder lade benötigte Bibliotheken. Mehr nicht. Auch committe ich NuGet Packages in das Source Code Repository.

Warum?

Weil für mich der Grundsatz gilt, dass ich meine Sourcen überall und immer bauen können möchte, ohne von äußeren Einflüssen daran gehindert werden zu können.

Als vor einiger Zeit der offizielle NuGet-Server einige Stunden offline war, schrie die halbe .NET-Entwickler-Welt auf, weil unter anderem keine Packages gefunden werden konnten die wiederhergestellt werden konnten. Build-Server schlugen fehl, weil ohne die Abhängigkeiten nicht gebaut werden konnte.

Alternative NuGet Services, wie z. B. myGet, boten unnötigerweise ihre Diensten an. Ohne eine Lösung für das eigentliche Problem zu liefern.

Fazit

  • Es gibt Unternehmen, in denen ein Server nichts aus dem Internet laden darf.
  • Es gibt instabile Netzwerke, mit Unterbrechungen, etc.
  • NuGet Server die nicht erreichbar sind.
  • Fehlerhafte Packages.

Das dürfen aus meiner Sicht keine Gründe sein für einen Broken-Build. Wenn ein Build fehlschlägt, dann bitte nur wenn Menschen im Spiel sind: Wenn ein Entwickler fehlerhaften Code eincheckt oder ein automatisierter Test aufgrund einer fehlerhaften Implementation nicht durchläuft.

Was bringt mir eine Automatisierung, wenn diese ebenfalls fehlerhaft sein kann?

Aus diesem Grund ist es für mich ein MUSS, dass sowohl der Build selber, als auch alle automatisierten Tests unabhängig von äußeren Einflüssen (außer menschlichen) fehlerfrei durchlaufen kann.

nuget build buildserver source-code-repository
Schreibe einen Kommentar:
Themen:
source-code-repository buildserver build nuget
Entweder einloggen... ...oder ohne Wartezeit registrieren
Benutzername
Passwort
Passwort wiederholen
E-Mail