オートメーションと.NETフレームワーク、どのツールを使用しますか？

Go、NodeJS、Java、Pythonなどのさまざまなプログラミング言語のデファクトで人気のあるツールの選択を知っています。しかし、.NETの世界でどのツールチェーンが合理的または（ホット）かさえわかりません。Octapusデプロイを使用していると聞きましたが、これはまだ有効な選択肢ですか？NuGetはまだ事実上​​のパッケージマネージャーですか？コード検査、自動QAなどについてはどうですか？

.NETの完全なツールチェーンと、開発、自動テスト、および配信を検討する際に現在人気のあるものについて感じたいと思います。

アーキテクチャはほとんどのMicrosoft / .NET開発組織の間で一般的であるため、Ian Margettの 回答からやや盗みます。高レベルのターゲットオペレーティングモデルは次のようになります。

目標は、既存の既成のソフトウェア、つまりTeamCity、ProGet、SonarQube、およびOctopus Deployを使用して、継続的デプロイメントパイプラインを作成することです。

• GitHubはソースコード管理ツールですが、BitBucketやVisual Studio Team Servicesの場合もあります。分岐モデルとコードレビュープロセスは、この高レベルでは範囲外です。
• TeamCityは、Octopus Deployとの緊密な統合、および.NET、msbuild、PowerShellの優れたオールラウンドサポートにより、ビルドシステムとして選択されています。TeamCityはOctopus Deployのデプロイメントのオーケストレーターとしても使用されます。
• ProGetは、Octopusパッケージとプロキシのパブリックパッケージ/イメージリポジトリの両方を格納するパッケージ管理ソリューションです。組み込みのTeamCity NuGetストアを使用しない理由は、純粋にスケーラビリティの理由によるものです。
• SonarQubeは継続的なコード品質管理を提供し、TeamCityビルド出力の一部としてレポートが公開されます。
• Octopus Deployは、ターゲットプラットフォームへのインフラストラクチャとコードの両方の展開ツールとして使用されます。

この広範なアプローチが2つの会社に実装され、さらに2つの会社で正常に実装されたのを見てきました。最近のケースでは、ファイアウォールルールを設定するときに少し面倒ではありましたが、機能したAppVeyorにTeamCityを入れ替えました。

.NETのツールチェーンでいくつかの異なるカテゴリについて言及しました。はい、NuGetは依然としてデフォルトのパッケージスタイルです。多くの人がUniversal Package Managerを使用してNuGetフィードを管理しています。

デプロイメントの場合、タコは確かにアーティファクトを押し出すためのオプションですが、それはあなたが話していた他のいくつかの側面を有効にしません。

ARAツールは、特にWinOpsのようなものを進化と-おそらく、より良い、それはより多くのちょうど展開の自動化およびARAのツールよりも、今DevOpsチームの世界でより多くの「ホット」ですん収まるだろう。

他のツールについては、DevOpsツールチェーンの WikiページとWinOpsに焦点を当てたツールセクションをご覧ください。

*私はInedoで完全な開示を行っており、これらのオプションの両方に対してソリューションを作成します（.NETを念頭に置いて）

私の場所での経験はOctopus Deploy、teamcity、Proget を使用してきました-優れたパイプラインとそのスケーリングの構築に大成功を収めました。単体テストや自動機能テストツールともうまく連携します。私たちは主にAzure on .Netにいますが、プライベートクラウドやオンプレミスにも展開しています