Laden...

Azure Devops & Lokal: NuGet-~ bzw. Assembly-Referenzen automatisch überprüfen

Erstellt von dr4g0n76 vor 4 Jahren Letzter Beitrag vor 4 Jahren 988 Views
dr4g0n76 Themenstarter:in
2.921 Beiträge seit 2005
vor 4 Jahren
Azure Devops & Lokal: NuGet-~ bzw. Assembly-Referenzen automatisch überprüfen

Was wir haben möchten:

Bei uns soll ein Quality-Gate erstellt werden, das zur Aufgabe hat NuGet-Referenzen zu erstellen. Zuerst lokal (eigener Rechner). Dann online (Azure).

Warum? Damit wir automatisch überprüfen können, dass beim Online Build
nicht Probleme auftreten, die wir schon vor dem Check-In finden hätten können.

Grund dafür:

Von der Entwicklungsabteilung wurde eine Solution gebaut, die normalerweise in Ordnung sein sollte.
Aber im Visual Studio treten gelbe Warndreiecke für die NuGet-Referenzen auf.
Leider kann im Visual Studio keine Fehlermeldung gesehen werden.

Wie macht ihr das bisher?

Was ich bisher gefunden habe (abgesehen von NDepend, was ich bei dieser Suche vorerst ausschliesse):

  • Appcelerate
    (ebenfalls als NuGet Package), um das zu überprüfen
    wird aber anscheinend schon sehr lange nicht mehr weiterentwickelt)

  • Selbst eine Lösung bauen, die die NuGet-References auflöst.
    Dazu gibt es auch schon ein anfängliches Beispiel von Microsoft, das eine gute Grundlage
    bietet

  • Reference Analyzer Extension vom Visual Studio Marketplace.

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

16.806 Beiträge seit 2008
vor 4 Jahren

Damit wir automatisch überprüfen können, dass beim Online Build
nicht Probleme auftreten, die wir schon vor dem Check-In finden hätten können.

Das ist ehrlich gesagt kein guter Weg.
Wenn Du auf ein Client-Tool-Weg setzt, dann hast Du das Problem, dass Du Entwickler an ein Tool bindest: das gilt es zu vermeiden.

  • Wenn jemand mit seinem Notepad programmieren will, dann lass ihn.
  • Wenn jemand mit seinem VSCode programmieren will, dann lass ihn.
  • Wenn jemand mit seinem VS IDE programmieren will, dann lass ihn.
  • Wenn jemand auf Din A4 schreiben und das einscannen will, dann lass ihn.

Es geht nicht darum, wie der Quellcode entsteht, sondern wie nachher der Quellcode aussieht.

Probleme können immer erst beim Online Build überprüft werden; Client-Side ist nicht genug.
Client-Side darf natürlich zusätzlich erfolgen - ersetzt aber niemals die Aufgabe des Builds.

In ein master Branch kann dies auch nie auftreten, weil Änderungen ja optimalerweise nur über einen Pull Request erfolgen.
Der PR ist damit Dein Quality Gate für den Master - inkl. eigenem Build.

Wir machen das genau so.

6.911 Beiträge seit 2009
vor 4 Jahren

Hallo dr4g0n76,

Damit wir automatisch überprüfen können, dass beim Online Build nicht Probleme auftreten, die wir schon vor dem Check-In finden hätten können.

Was ist / wäre daran so schlimm (also wenn beim Online-Build Probleme auftreten)?
Wie Abt schon schreibt sollten Änderungen nur via PRs nach master kommen und nie direkt. So werden die Probleme beim Build entdeckt und können behoben werden bevor der PR akzeptiert wird.

(ebenfalls als NuGet Package)

Da kann sich die Katze auch schnell in den Schwanz beißen, wenn mit einem NuGet Paket die Korrektheit der anderen NuGet Pakete validiert werden soll 😉

Geht eher den einfachen Weg und lasst ggf. den Online-Build fehlschlagen, dann wisst ihr sicher dass etwas nicht stimmt.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"