¿Automatización y .NET Framework qué herramientas usar?

Soy consciente de las opciones de herramientas populares y de facto para varios lenguajes de programación como Go, NodeJS, Java, Python, etc. Sin embargo, no sé qué cadena de herramientas es razonable o incluso (actual) en el mundo .NET. He oído que la gente usa el despliegue de Octapus, ¿sigue siendo una opción válida? ¿NuGet sigue siendo el administrador de paquetes de facto? ¿Qué pasa con la inspección de código, control de calidad automático, etc.?

Me gustaría tener una idea de la cadena de herramientas completa para .NET y lo que es popular en este momento al considerar el desarrollo, la prueba automática y la entrega.

Un tanto robado de la respuesta de Ian Margett, ya que la arquitectura es común entre la mayoría de las organizaciones de desarrollo de Microsoft / .NET, el modelo operativo objetivo de alto nivel se parece a esto:

El objetivo es crear una tubería de despliegue continuo, utilizando el software existente fuera de la plataforma, a saber TeamCity , Proget , sonarqube y pulpo Implementar :

• GitHub es la herramienta de administración del código fuente, sin embargo, podría ser BitBucket o Visual Studio Team Services. El modelo de ramificación y el proceso de revisión de código están fuera del alcance en este alto nivel.
• TeamCity se elige como Build System debido a su estrecha integración con Octopus Deploy y su buen soporte integral para .NET, msbuild y PowerShell. TeamCity también se utiliza como orquestador de implementaciones en Octopus Deploy.
• ProGet es la solución de gestión de paquetes que almacena paquetes de Octopus y proporciona repositorios de paquetes / imágenes públicas. La razón para no usar la tienda incorporada de TeamCity NuGet es puramente por razones de escalabilidad.
• SonarQube proporciona una gestión continua de la calidad del código y los informes se publican como parte de los resultados de construcción de TeamCity.
• Octopus Deploy se utiliza como herramienta de implementación para infraestructura y código en las plataformas de destino.

He visto este amplio enfoque implementado en dos compañías y lo implementé con éxito en dos compañías adicionales: en el caso más reciente, cambiamos TeamCity por AppVeyor, que funcionó, aunque fue un poco doloroso al configurar las reglas de firewall.

Menciona algunas categorías diferentes en su cadena de herramientas para .NET. Sí, NuGet sigue siendo el estilo de paquete predeterminado, y muchas personas usan un Universal Package Manager para administrar sus feeds NuGet.

Para la implementación, Octopus es de hecho una opción para expulsar artefactos, pero no permite algunos de los otros aspectos de los que estaba hablando.

Una herramienta ARA probablemente encajaría mejor que hace más que solo la automatización de implementación y las herramientas ARA son más "populares" en el mundo de DevOps en este momento, especialmente con cosas en evolución como WinOps.

En cuanto a otras herramientas, eche un vistazo a la página wiki de la cadena de herramientas DevOps y la sección de herramientas enfocadas de WinOps .

* Divulgación completa Trabajo en Inedo , y hacemos una solución para ambas opciones (con .NET en mente)

La experiencia en mi casa ha sido usar Octopus Deploy, equipo de trabajoy Proget: tuvo un gran éxito al construir una buena tubería y su escalamiento bien. También juega muy bien con las pruebas unitarias y las herramientas de pruebas funcionales automatizadas. Estamos predominantemente en Azure en .Net pero también implementamos en la nube privada y en las instalaciones