patternModerate
Automation and the .NET framework which tools to use?
Viewed 0 times
thewhichautomationnetandtoolsframeworkuse
Problem
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.
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.
Solution
Somewhat stealing from Ian Margett's answer as the architecture is common amongst most Microsoft/.NET development organizations, the high-level target operating model for looks something like this:
The goal is to create a Continuous Deployment pipeline, using existing off-the-shelf software, namely TeamCity, ProGet, SonarQube and Octopus Deploy:
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.
The goal is to create a Continuous Deployment pipeline, using existing off-the-shelf software, namely TeamCity, ProGet, SonarQube and Octopus Deploy:
- 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.
Context
StackExchange DevOps Q#782, answer score: 11
Revisions (0)
No revisions yet.