Answers: <p>You mention a few different categories in your toolchain for .NET. Yes, NuGet is still the default package style – and a lot of people use a <a href="https://en.wikipedia.org/wiki/Binary_repository_manager" rel="nofollow noreferrer">Universal Package Manager</a> to manage their NuGet feeds. </p>
  
  <p>For Deployment, Octopus is indeed an option for pushing out artifacts, but it doesn’t enable some of the other aspects you were talking about. </p>
  
  <p>An <a href="https://en.wikipedia.org/wiki/Application_release_automation" rel="nofollow noreferrer">ARA tool</a> would probably be a better fit it does more than just Deployment automation and ARA tools are more "Hot" in the DevOps world right now - especially with evolving things like WinOps.</p>
  
  <p>As far as other tools, take a look at the <a href="https://en.wikipedia.org/wiki/DevOps_toolchain" rel="nofollow noreferrer">DevOps toolchain</a> wiki page and the <a href="https://en.wikipedia.org/wiki/WinOps#WinOps_focused_tools" rel="nofollow noreferrer">WinOps focused tools</a> section. </p>
  
  <p>*Full disclosure I work at <a href="http://inedo.com" rel="nofollow noreferrer">Inedo</a>, and we make a solution for both of these options (with .NET in mind)</p>
  
  <p><a href="https://i.sstatic.net/jmjBn.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/jmjBn.png" alt="Inedo toolchain"></a></p>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-05T14:06:44.237Z
Answers: 2017-04-06T20:47:14.453Z
Answers: 2017-04-06T20:47:14.453Z
Answers: Karl Harnagy
Answers: <p>Experience at my place has been using Octopus Deploy, <a href="/questions/tagged/teamcity" class="post-tag" title="show questions tagged &#39;teamcity&#39;" rel="tag">teamcity</a> and Proget - had great success building a good pipeline and its scaling well. Also plays nicely with unit testing and automated functional test tools. We are predominantly in Azure on .Net but also deploying to private cloud and on premise</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-05T19:57:27.463Z
Answers: 2017-04-05T22:17:29.943Z
Answers: 2017-04-05T22:17:29.943Z
Answers: Ian Margetts
Answers: <p>Somewhat stealing from <a href="https://devops.stackexchange.com/users/1163/ian-margetts">Ian Margett's</a> <a href="https://devops.stackexchange.com/a/792/397">answer</a> as the architecture is common amongst most Microsoft/.NET development organizations, the high-level target operating model for looks something like this:</p>
  
  <p><a href="https://i.sstatic.net/rT3rA.png" rel="noreferrer"><img src="https://i.sstatic.net/rT3rA.png" alt=".NET Target Operating Model"></a></p>
  
  <p>The goal is to create a Continuous Deployment pipeline, using existing off-the-shelf software, namely <a href="https://www.jetbrains.com/teamcity/" rel="noreferrer">TeamCity</a>, <a href="https://inedo.com/proget" rel="noreferrer">ProGet</a>, <a href="https://www.sonarqube.org/" rel="noreferrer">SonarQube</a> and <a href="https://octopus.com/" rel="noreferrer">Octopus Deploy</a>:</p>
  
  <ul>
  <li><strong>GitHub</strong> is the source code management tool, however, it could be BitBucket or Visual Studio Team Services.  The branching model and code review process are out of scope at this high level.</li>
  <li><strong>TeamCity</strong> is chosen as the Build System due to its tight integration with Octopus Deploy and good all-round support for .NET, msbuild and PowerShell.  TeamCity is also used as the orchestrator of deployments in Octopus Deploy.</li>
  <li><strong>ProGet</strong> is the package management solution which both stores Octopus Packages and proxies public package/image repositories.  The rationale for not using the built-in TeamCity NuGet store is purely for scalability reasons.</li>
  <li><strong>SonarQube</strong> provides continuous code quality management and reports are published as part of the TeamCity build outputs.</li>
  <li><strong>Octopus Deploy</strong> is used as the deployment tool for both infrastructure and code into the target platforms.</li>
  </ul>
  
  <p>I've seen this broad approach implemented across two companies and successfully implemented it in two additional companies - in the most recent case we swapped TeamCity out for AppVeyor which worked, albeit a little painful when setting up firewall rules.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-06T12:43:38.413Z
Answers: 2017-04-06T12:43:38.413Z
Answers: 2017-04-13T13:01:29.297Z
Answers: Richard Slater
Body: <p>I am aware of the de facto and popular tool choices for various programming languages such as Go, NodeJS, Java, Python etc.
  However, I do not know what toolchain is reasonable or even (hot) in the .NET world.
  I have heard that people use Octapus deploy, is this still a valid choice?
  Is NuGet still the defacto package manager?
  What about code inspection, automatic QA etc.?</p>
  
  <p>I would like to get a feeling of the complete toolchain for .NET and what is popular right now when considering development, automatic test, and delivery.</p>
  
Tags: <automation><toolchain><dotnet>
Title: Automation and the .NET framework which tools to use?
UserDisplayName: Steiniche
ThreadText: # Automation and the .NET framework which tools to use?
  
  (Asked by: username_0 on 2017-04-05)
  
  I am aware of the de facto and popular tool choices for various programming languages such as Go, NodeJS, Java, Python etc.
  However, I do not know what toolchain is reasonable or even (hot) in the .NET world.
  I have heard that people use Octapus deploy, is this still a valid choice?
  Is NuGet still the defacto package manager?
  What about code inspection, automatic QA etc.?
  
  I would like to get a feeling of the complete toolchain for .NET and what is popular right now when considering development, automatic test, and delivery.
  
  **Tags:** automation, toolchain, dotnet
  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_3 on 2017-04-06. Score: 11 | Accepted answer
  
  Somewhat stealing from [Ian Margett's](https://devops.stackexchange.com/users/1163/ian-username_2) [answer](https://devops.stackexchange.com/a/792/397) as the architecture is common amongst most Microsoft/.NET development organizations, the high-level target operating model for looks something like this:
  
  [![.NET Target Operating Model](https://i.sstatic.net/rT3rA.png)](https://i.sstatic.net/rT3rA.png)
  
  The goal is to create a Continuous Deployment pipeline, using existing off-the-shelf software, namely [TeamCity](https://www.jetbrains.com/teamcity/), [ProGet](https://inedo.com/proget), [SonarQube](https://www.sonarqube.org/) and [Octopus Deploy](https://octopus.com/):
  
  * **GitHub** is the source code management tool, however, it could be BitBucket or Visual Studio Team Services. The branching model and code review process are out of scope at this high level.
  * **TeamCity** is chosen as the Build System due to its tight integration with Octopus Deploy and good all-round support for .NET, msbuild and PowerShell. TeamCity is also used as the orchestrator of deployments in Octopus Deploy.
  * **ProGet** is the package management solution which both stores Octopus Packages and proxies public package/image repositories. The rationale for not using the built-in TeamCity NuGet store is purely for scalability reasons.
  * **SonarQube** provides continuous code quality management and reports are published as part of the TeamCity build outputs.
  * **Octopus Deploy** is used as the deployment tool for both infrastructure and code into the target platforms.
  
  I've seen this broad approach implemented across two companies and successfully implemented it in two additional companies - in the most recent case we swapped TeamCity out for AppVeyor which worked, albeit a little painful when setting up firewall rules.
  
  
  ---
  
  ### Answer by username_1 on 2017-04-05. Score: 6
  
  You mention a few different categories in your toolchain for .NET. Yes, NuGet is still the default package style – and a lot of people use a [Universal Package Manager](https://en.wikipedia.org/wiki/Binary_repository_manager) to manage their NuGet feeds.
  
  For Deployment, Octopus is indeed an option for pushing out artifacts, but it doesn’t enable some of the other aspects you were talking about.
  
  An [ARA tool](https://en.wikipedia.org/wiki/Application_release_automation) would probably be a better fit it does more than just Deployment automation and ARA tools are more "Hot" in the DevOps world right now - especially with evolving things like WinOps.
  
  As far as other tools, take a look at the [DevOps toolchain](https://en.wikipedia.org/wiki/DevOps_toolchain) wiki page and the [WinOps focused tools](https://en.wikipedia.org/wiki/WinOps#WinOps_focused_tools) section.
  
  \*Full disclosure I work at [Inedo](http://inedo.com), and we make a solution for both of these options (with .NET in mind)
  
  [![Inedo toolchain](https://i.sstatic.net/jmjBn.png)](https://i.sstatic.net/jmjBn.png)
  
  
  ---
  
  ### Answer by username_2 on 2017-04-05. Score: 4
  
  Experience at my place has been using Octopus Deploy, [teamcity](/questions/tagged/teamcity "show questions tagged 'teamcity'") and Proget - had great success building a good pipeline and its scaling well. Also plays nicely with unit testing and automated functional test tools. We are predominantly in Azure on .Net but also deploying to private cloud and on premise
  
  
  ---
  
  