L'automatisation et le framework .NET quels outils utiliser?


8

Je connais les choix d'outils de facto et populaires pour divers langages de programmation tels que Go, NodeJS, Java, Python etc. Cependant, je ne sais pas quelle chaîne d'outils est raisonnable ou même (chaude) dans le monde .NET. J'ai entendu dire que les gens utilisent Octapus deploy, est-ce toujours un choix valable? NuGet est-il toujours le gestionnaire de paquets de facto? Qu'en est-il de l'inspection du code, de l'assurance qualité automatique, etc.?

Je voudrais avoir une idée de la chaîne d'outils complète pour .NET et de ce qui est populaire en ce moment en ce qui concerne le développement, le test automatique et la livraison.

Réponses:


11

Volant quelque peu de la réponse d' Ian Margett car l'architecture est courante dans la plupart des organisations de développement Microsoft / .NET, le modèle d'exploitation cible de haut niveau ressemble à ceci:

Modèle d'exploitation cible .NET

L'objectif est de créer un pipeline de déploiement continu, en utilisant les logiciels existants, à savoir TeamCity , ProGet , SonarQube et Octopus Deploy :

  • GitHub est l'outil de gestion du code source, cependant, il peut s'agir de BitBucket ou de Visual Studio Team Services. Le modèle de branchement et le processus de révision du code sont hors de portée à ce niveau élevé.
  • TeamCity est choisi comme système de construction en raison de son intégration étroite avec Octopus Deploy et de la bonne prise en charge globale de .NET, msbuild et PowerShell. TeamCity est également utilisé comme orchestrateur de déploiements dans Octopus Deploy.
  • ProGet est la solution de gestion de packages qui stocke à la fois les packages Octopus et les référentiels publics de packages / images. La raison de ne pas utiliser le magasin TeamCity NuGet intégré est uniquement pour des raisons d'évolutivité.
  • SonarQube fournit une gestion continue de la qualité du code et les rapports sont publiés dans le cadre des sorties de build TeamCity.
  • Octopus Deploy est utilisé comme outil de déploiement pour l'infrastructure et le code dans les plates-formes cibles.

J'ai vu cette approche globale mise en œuvre dans deux sociétés et l'ai mise en œuvre avec succès dans deux autres sociétés - dans le cas le plus récent, nous avons échangé TeamCity contre AppVeyor qui a fonctionné, bien qu'un peu pénible lors de la configuration des règles de pare-feu.


6

Vous mentionnez quelques catégories différentes dans votre chaîne d'outils pour .NET. Oui, NuGet est toujours le style de package par défaut - et beaucoup de gens utilisent Universal Package Manager pour gérer leurs flux NuGet.

Pour le déploiement, Octopus est en effet une option pour éliminer les artefacts, mais il ne permet pas certains des autres aspects dont vous parliez.

Un outil ARA serait probablement mieux adapté qu'il ne fait plus que l'automatisation du déploiement et les outils ARA sont plus "à la mode" dans le monde DevOps en ce moment - en particulier avec des choses évolutives comme WinOps.

En ce qui concerne les autres outils, jetez un œil à la page wiki de la chaîne d'outils DevOps et à la section des outils ciblés WinOps .

* Divulgation complète Je travaille chez Inedo , et nous faisons une solution pour ces deux options (avec .NET à l'esprit)

Chaîne d'outils Inedo


4

L'expérience chez moi utilise Octopus Deploy, et Proget - ont eu beaucoup de succès à construire un bon pipeline et à bien évoluer. Joue également bien avec les tests unitaires et les outils de test fonctionnel automatisé. Nous sommes principalement dans Azure sur .Net mais déployons également sur le cloud privé et sur site

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.