Automatisierung und das .NET Framework, welche Tools verwendet werden sollen?

Ich bin mir der faktischen und beliebten Toolauswahl für verschiedene Programmiersprachen wie Go, NodeJS, Java, Python usw. bewusst. Ich weiß jedoch nicht, welche Toolchain in der .NET-Welt sinnvoll oder sogar (heiß) ist. Ich habe gehört, dass Benutzer Octapus Deploy verwenden. Ist dies immer noch eine gültige Wahl? Ist NuGet immer noch der defacto-Paketmanager? Was ist mit Code-Inspektion, automatischer Qualitätssicherung usw.?

Ich möchte ein Gefühl für die gesamte Toolchain für .NET bekommen und was derzeit beliebt ist, wenn ich über Entwicklung, automatischen Test und Bereitstellung nachdenke.

Ian Margetts Antwort stiehlt etwas, da die Architektur in den meisten Microsoft / .NET-Entwicklungsorganisationen üblich ist. Das übergeordnete Zielbetriebsmodell sieht ungefähr so aus:

Ziel ist die Erstellung einer Continuous Deployment-Pipeline unter Verwendung der vorhandenen Standardsoftware TeamCity , ProGet , SonarQube und Octopus Deploy :

• GitHub ist das Quellcodeverwaltungstool. Es kann sich jedoch auch um BitBucket oder Visual Studio Team Services handeln. Das Verzweigungsmodell und der Codeüberprüfungsprozess sind auf dieser hohen Ebene nicht möglich.
• TeamCity wird aufgrund seiner engen Integration mit Octopus Deploy und der umfassenden Unterstützung für .NET, msbuild und PowerShell als Build-System ausgewählt. TeamCity wird auch als Orchestrator für Bereitstellungen in Octopus Deploy verwendet.
• ProGet ist die Paketverwaltungslösung, in der sowohl Octopus-Pakete als auch öffentliche Paket- / Image-Repositorys gespeichert werden. Der Grund dafür, dass der integrierte TeamCity NuGet-Speicher nicht verwendet wird, liegt ausschließlich in der Skalierbarkeit.
• SonarQube bietet ein kontinuierliches Codequalitätsmanagement und Berichte werden als Teil der TeamCity-Build-Ausgaben veröffentlicht.
• Octopus Deploy wird als Bereitstellungstool für Infrastruktur und Code auf den Zielplattformen verwendet.

Ich habe gesehen, dass dieser umfassende Ansatz in zwei Unternehmen implementiert und in zwei weiteren Unternehmen erfolgreich implementiert wurde. Im letzten Fall haben wir TeamCity gegen AppVeyor ausgetauscht, was funktioniert hat, wenn auch etwas schmerzhaft beim Einrichten von Firewall-Regeln.

Sie erwähnen einige verschiedene Kategorien in Ihrer Toolchain für .NET. Ja, NuGet ist immer noch der Standardpaketstil - und viele Benutzer verwenden einen Universal Package Manager , um ihre NuGet-Feeds zu verwalten.

Für die Bereitstellung ist Octopus zwar eine Option zum Herausschieben von Artefakten, aktiviert jedoch einige der anderen Aspekte, über die Sie gesprochen haben, nicht.

Ein ARA-Tool passt wahrscheinlich besser zu mehr als nur der Bereitstellungsautomatisierung, und ARA-Tools sind derzeit in der DevOps-Welt "heißer" - insbesondere bei sich entwickelnden Dingen wie WinOps.

Weitere Tools finden Sie auf der DevOps-Toolchain- Wiki-Seite und im Abschnitt WinOps-Tools .

* Vollständige Offenlegung Ich arbeite bei Inedo und wir entwickeln eine Lösung für beide Optionen (unter Berücksichtigung von .NET).

Ich habe Erfahrung mit Octopus Deploy, Teamcity und Proget gesammelt - hatte großen Erfolg beim Aufbau einer guten Pipeline und deren Skalierung. Spielt auch gut mit Unit-Tests und automatisierten Funktionstest-Tools. Wir sind vorwiegend in Azure auf .Net, stellen aber auch in der privaten Cloud und vor Ort bereit