Recently I’ve been working on an application that runs partially in Azure ServiceFabric. I’ve created a local cluster to work against and now it’s time to configure my TeamCity deployment to deploy upgrades to my application automatically. Initial details: Deploying 2 projects: a .Net 4.6.2 ASP.Net Core app to web app .Net 4.6.2 ServiceFabric project […]
Less Than Dot is a community of passionate IT professionals and enthusiasts dedicated to sharing technical knowledge, experience, and assistance. Inside you will find reference materials, interesting technical discussions, and expert tips and commentary.
ASP.Net Projects and NuGet have been a moving target the last couple years. I have an ASP.Net Core project (.Net Framework) with several class libraries and had to work through a number of problems to get NuGet Restore working on a TeamCity CI server. Hopefully this will help someone else along the way. It turns […]
A few years back, I posted “Displaying .Net Build Warnings in TeamCity“. Many folks found it useful (and it served as a good reference the last time I needed to re-setup warnings). Recently, Mitch Terlisner reached out to me with a much improved version to share with folks that includes better build status output, an […]
Recently I needed access to the list of commits that were included with each of my TeamCity builds. TeamCity provides a pretty big list of Predefined Build Parameters, but it doesn’t provide access to details of the commits it is currently building. Having Powershell and Git on my server, though, I can write some scripts […]
I like it when I kick off a build and there aren’t any warnings. Unfortunately I’m forgetful and it’s always easier to edit the code now then it is 3 months later (when I remember to look at the warnings).
This post will cover capturing MSBuild warnings in TeamCity and displayign the results in the dashboard, a custom chart, the build log, a raw text artifact, and a custom report tab in the run results.
While re-implementing my continuous delivery pipeline in TeamCity last week, I skipped over charting the load tests results from WCAT. This weekend I returned to this task to find that it was less tricky than it originally appeared.
So what do you do when you have a nice little build lab with two implementations of an automated deployment pipeline that includes unit testing, automated interface testing, automated deployments, smoke testing, automated load tests, static analysis, warning tracking, and automated sort-of QA and production deployments?
Take it to the cloud, of course.
Over the series of 12 posts, I have built a continuous delivery pipeline around the MVC Music Store tutorial web site. The journey included making changes to support unit testing, creating a CI build, adding automated multi-environment deployment, automated interface testing, automated load testing stage, and static analysis. Up until now, this was entirely on Jenkins, but today I intend to re-implement the pipeline on TeamCity.