Deploying An ASP.NET Core Site, You're Still Doing It Wrong : Part 1

This day and age, predictability and reliability are two of the most important words when it comes deployments. In this series, I am going to talk about how to add both predictability and reliability to your ASP.NET Core Continuous Integration pipeline using TeamCity and Octopus Deploy.

  1. Intro
  2. TeamCity
  3. Octopus Deploy: Installation And Targets
  4. Octopus Deploy: Configuration And Deployments
  5. Why Stop Now

You're Still Doing It Wrong!

In 2010 there were two key resources published that helped identify many of the common mistakes developers were making when dealing with deployments and how you might go about solving them.

Both Scott and Troy based their work on the fact that at the time, many of the common practices being followed when deploying a web application were unpredictable due to the human variable. It does not matter which way you slice it, we as humans are error prone. No matter how many step-by-step instructions sets are put in front of us or how many times we have performed the same task over and over, we will mess it up at some point. That is a guarantee!

The key to reducing the problems then are the still the same now, introduce automation into your deployment process and introduce it early. If a human is needed to perform a task, be that configuration or deployment, we should clearly define that individual task and look to automate the hell out of it.

With Predictability, Comes Reliability

Though the high-level concepts are the same now as they were then, the landscape in which they exist in has drastically changed. With that in mind, let's define some of the familiar high-level goals that we would like to achieve.

  1. Automate builds through version control triggers.
  2. Automate deployments.
    • Automate configuration per specific deployment target.
    • Deploy automated pre-configured build to a deployment target.

In other words, the code is pushed to our repository. The "push" triggers an automated build. The "automated build" triggers an automated deployment. The automated "deployment" configures the "build" and pushes the deployment to a target.

As you might have noticed, I am opting to emphasize the concept of automation here. When we automate steps in the deployment process, we are removing points in which a human has a chance to screw something up. By doing such, we are introducing the concept of predictability. If we automate "a", we can predict "x" will happen. The more we can predict and more importantly prove to be accurate, the more reliability we will have in our deployment process.

Changing Landscape

Though conceptually some of the concepts have been around for some time, the tooling used to achieve them has changed. With this in mind, let's define some specifics around our goals.

  1. Use Git as our repository.
  2. Trigger TeamCity to build our ASP.NET Core application.
  3. Trigger Octopus Deploy to...
    • Configure our appsettings.json file with deployment target appropriate values.
    • Deploy our pre-built ASP.NET Core application to our deployment target along with the appropriate configuration.


There will be a few prerequisite that needs to be met before we get started. Like with many of my other blog posts, I will be approaching this from the point of view of my actual blog. Meaning, I will be using the Pioneer Code Blog source in my environment, with the deployment target being That being said, all the high-level concepts hold true to most deployments and all the tooling holds accurate to most ASP.NET deployments.


This day and age, the vast majority of the development community are using GitHub to service their repository needs and I will be doing the same. That being said, alternative services such as Visual Studio Team Services or GitLab will suffice.

If you do not go with GitHub, concepts such as triggering integrations with TeamCity on a status change will differ.

Tooling Home

I will be using an on-perm server to host TeamCity and Octopus Deploy. Any environment you choose to host with, be it a server, virtual machine or local development environment, will be fine.

Deployment Target

Pioneer Code is hosted at DigitalOcean on a Linux VM. For the most part, be it a Linux target or Windows the concept of file transfer on deployment is the same. The means on how we achieve this will differ though. I will address more of this in the following parts to this series.

Up Next

Now that we have some goals defined and our prerequisites out of the way, we can look to setting up and configuring TeamCity to automatically build our application as we push code into our repository. Until then, please feel free to leave any comments below.

Deploying An ASP.NET Core Site, You're Still Doing It Wrong : Part 2 - Octopus Deploy: TeamCity