Automazione e .NET framework quali strumenti usare?

Sono a conoscenza delle scelte di fatto e popolari degli strumenti per vari linguaggi di programmazione come Go, NodeJS, Java, Python ecc. Tuttavia, non so quale toolchain sia ragionevole o addirittura (caldo) nel mondo .NET. Ho sentito che la gente usa Octapus deploy, è ancora una scelta valida? NuGet è ancora il gestore dei pacchetti defacto? Che dire dell'ispezione del codice, del QA automatico ecc.?

Vorrei avere un'idea della toolchain completa per .NET e di ciò che è popolare in questo momento quando si considera lo sviluppo, il test automatico e la consegna.

In qualche modo rubando alla risposta di Ian Margett poiché l'architettura è comune nella maggior parte delle organizzazioni di sviluppo Microsoft / .NET, il modello operativo di destinazione di alto livello è simile al seguente:

L'obiettivo è quello di creare una pipeline di implementazione continua, utilizzando il software standard esistente, ovvero TeamCity , ProGet , SonarQube e Octopus Deploy :

• GitHub è lo strumento di gestione del codice sorgente, tuttavia, potrebbe essere BitBucket o Visual Studio Team Services. Il modello di diramazione e il processo di revisione del codice non rientrano nell'ambito di questo livello elevato.
• TeamCity è scelto come sistema di compilazione grazie alla sua stretta integrazione con Octopus Deploy e al buon supporto a tutto tondo per .NET, msbuild e PowerShell. TeamCity viene anche utilizzato come orchestratore delle implementazioni in Octopus Deploy.
• ProGet è la soluzione di gestione dei pacchetti che archivia sia i pacchetti Octopus sia i proxy di repository di pacchetti / immagini pubblici. La logica per non utilizzare il negozio NuGet TeamCity integrato è puramente per motivi di scalabilità.
• SonarQube fornisce una gestione continua della qualità del codice e i report sono pubblicati come parte degli output di build di TeamCity.
• Octopus Deploy viene utilizzato come strumento di distribuzione sia per l'infrastruttura che per il codice nelle piattaforme di destinazione.

Ho visto questo ampio approccio implementato in due società e implementato con successo in altre due aziende: nel caso più recente abbiamo sostituito TeamCity con AppVeyor che ha funzionato, anche se un po 'doloroso durante l'impostazione delle regole del firewall.

Citi alcune diverse categorie nella tua toolchain per .NET. Sì, NuGet è ancora lo stile di pacchetto predefinito e molte persone usano un gestore pacchetti universale per gestire i loro feed NuGet.

Per Deployment, Octopus è davvero un'opzione per espellere gli artefatti, ma non consente alcuni degli altri aspetti di cui stavi parlando.

Uno strumento ARA potrebbe probabilmente adattarsi meglio di quanto non faccia solo l'automazione della distribuzione e gli strumenti ARA sono più "caldi" nel mondo DevOps in questo momento - specialmente con cose in evoluzione come WinOps.

Per quanto riguarda gli altri strumenti, dai un'occhiata alla pagina wiki del toolchain DevOps e alla sezione degli strumenti focalizzati su WinOps .

* Informativa completa Lavoro in Inedo e creiamo una soluzione per entrambe queste opzioni (tenendo conto di .NET)

L'esperienza al mio posto è stata l'utilizzo di Octopus Deploy, TeamCitye Proget - ha avuto un grande successo nel costruire una buona pipeline e il suo ridimensionamento. Funziona bene anche con test unitari e strumenti di test funzionali automatizzati. Siamo prevalentemente in Azure su .Net, ma stiamo anche implementando su cloud privato e on premise