ASP.NET Deployment – Proper Way to Deploy to Production Server

asp.netdeploymentiisiis7visual studio

Here is how I was told to deploy my ASP.net(mostly intranet) website\program\application to the production web server in my company.

  1. Change necessary settings in web.config for production web server.
  2. Copy EVERYTHING of my source codes, then paste in the designated virtual directory\folder in the web server.

As far as I know, I should be:

  1. using the Publish.. or Publish Web Site in Visual Studio to generate the codes.
  2. Copy the generated codes to the designated virtual directory\folder in the web server.

Which is a better deploy method?

What are the pros & cons of these two deploy methods?

Is there a standard(for poor man or cheap) way to do this?

Best Answer

From my painful experience, the more of deployment process is being done manually, the bigger trouble you'll get into. And both your current steps require heavy manual effort. Here are my recommendations:

1. Use VS Publish functionality as your bare minimum

First step toward having automated deployment process is, as you are aware of, using Publish functionality in Visual Studio. With the right setup of XML transformation, this functionality will handle the changes you need to happen on web.config (and other XML-based config files).

Ideally, if you have access to production server, you can target the Publish to the production server website. This will do the copy/paste for you. Otherwise, target to an isolated Folder in your system (that you will never mistake it with the source code folder).

2. Employ Continuous Integration (CI) and Continuous Deployment (CD)

This may be overkill for small projects that are mainly maintained by sole developer. But CI/CD is the way to go if your project evolves to a monster. Here are the indicators to start using CI/CD:

  • Your project and the team working on it become big enough that you literally cannot manual test all aspect of the website every time new changes are introduced => You need automated test, and need it done every single time someone commits a change.

  • You now have multiple environments to deploy to (dev, staging, UAT, production, you name it). While creating Publish profile for each of them is still feasible, knowing when you should deploy to a specific environment will become tricky (say, only deploy to production if all your tests are passed in other environments, and your boss - aka your customer - is happy with UAT).

  • You need the ability of rolling back your deployment. See how cool it is? CD could literally save you hours when something goes south with your newest deployment with just one button click.

  • You want to keep sensitive configuration data from checking in to source control (say you don't want to expose connection string to your production DB to a newly-hired junior dev). The workflow with VS Publish + XML transformation makes it harder to achieve this.

There are plenty of CI/CD tools for you to start with, some of them are FREE. Currently I'm happy with TeamCity for CI and Octopus Deploy for CD (both are free for small teams).

Related Topic