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:
GitHub is ...
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 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 would ...
Specifically in answer to your 3rd question, if you are willing to look outside of the Jenkins Ecosystem there are alternatives out there that might be of value to you.
For my clients who use the Microsoft Stack and have fewer than four teams, I have been recommending the use of AppVeyor it is highly tuned for the .NET Stack and integrated very naturally ...
Experience at my place has been using Octopus Deploy, 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
It may be helpful to look at the different AWS developer services as you are trying to achieve your goal in the wrong services:
Running the specific dotnet testing and publish steps are not done in CodeDeploy. Rather, they would be done in AWS CodeBuild, in the AWS Pipeline, or directly on your Jenkins Server.
AWS CodeDeploy is for taking your build ...
I noticed that the description for the filepath properties of the pack command is different than the descriptions in the test and publish commands:
Pattern to search for csproj or nuspec files to pack.
You can separate multiple patterns with a semicolon, and you can
make a pattern negative by prefixing it with '-:'. Example:
For something that requires being agnostic to the tooling, and having the flexibility you need, your best bet is Jenkins. https://jenkins.io/. They have a ton of plugins that would meet any use case. Be aware that Jenkins can be heavy for small teams, but your other options lack the flexibility and support for different communities.
You can check out ...
Are they indeed runnable in containers and this makes sense?
According to this documentation it is possible to run windows in docker. Yes it could make sense as this would be comparable to the positive effects of running linux in docker. Note that:
Disclaimer: This lab is still in work, and is based off of the blog,
but you can test and leverage the ...
OK - found the solution myself. It's a kind of tricky one. Even though my project is written in F#, I still have to set
in my .travis.yml file. That's a bit counter-intuitive, but I must admit that it's written in the doc, so can't really blame anyone.
It is wise to think about package management early on.
There are multiple options in terms of package management. The 2 largest are jFrog Artifactory and Sonatype Nexus. Both offer support for multiple formats such as maven, NuGet, Docker, npm, ...
If you only have standard requirements, both of these will suffice. If you have specific requirements, it's ...
You need to provide commands in list. Something like below:
V1ExecAction execommand = new V1ExecAction("curl", "http://localhost:5001/checkhealth/");
Since you already an endpoint for healthcheck, you should use V1HTTPGetAction instead of V1ExecAction. In your case, V1ExecAction will always give exit status as 0 and thus liveliness check ...
Kubernetes supports TCP, HTTP, and shell-exec probes for an application startup, readiness, and liveness health checks. If your application is a web application, you can use HTTP based liveness healthcheck as shown in the following code snippet:
As far as I know, I think Octopus doesn't packages anything. The package should come from your CI Tool (Jenkins or TeamCity maybe?)
Having said that, I would check on your previous step in the CI/CD chain to see how are you packaging your solution, and filter those folders there, before packaging.
That will also help you:
Reducing the package size
Yes.. we can control the packages using nuspec file which will be added to your solution and you will be specifying the list of folders/files you dont wanna deploy. And you will use that nuspec to create the nuget package for deployments