Building and Deploying a ASP MVC website to production

Developing and troubleshooting an ASP MVC website can be fun and exciting. You’re generally learning new concepts, discovering and resolving issues, and driving your objectives to a successful website. When it comes time to deploy the website to a production server, often times the fun and excitement becomes a frustrating, time consuming and tedious exercise.

Reason for this are many including: (1) The development machine has all the necessary files needed to make the website work, however, isolating these files and publishing to a server can be trying the first few times, (2) Finding the right host for your website - if you’re working solely with Microsoft .NET, a Windows host that supports the current version is a requirement.

Fortunately, Microsoft Visual Studio comes with native publishing methods to make isolating development to production relatively easy.

In the following article, we’ll see how to isolate a development to production environment, and how to deploy only the necessary files for production.

Creating development and release environment

There are multiple avenues to creating a development & production environment, too many to include in this article. Instead, we’ll discuss a couple popular avenues prevalent today, and then from there, you’ll decide which option to take.

Option 1

From this path you create the following hierarchy:

  1. C:\Project Name
    1. C:\Project Name\trunk
    2. C:\Project Name\branches
      1. C:\Project Name\branches\v1.0
      2. C:\Project Name\branches\v2.0
    3. C:\Project Name\Release\v1.0
    4. C:\Project Name\Release\v2.0

In this approach you have: (a) trunk, which is considered the main line, in other words, the golden branch for development, (b) branches, which is considered a specific version of the code base by development version. This could be useful if there’s a specific bug related to either version 1 or 2 that needs to be addressed and (c) & (d) are release versions of the product that have been certified a public stable version.

If you’re working in a large team or have many different versions of the same product this can be the desired approach.

Option 2

From this path you create the following hierarchy:

  1. C:\Project Name
    1. C:\Project Name\Dev
    2. C:\Project Name\Release

In this approach you have: (a) Dev, which is considered the main line, in other words, the golden branch for development, (b) Release, which is the released version of the product that have been certified a public stable version. Sometimes in this approach release is extended to include another folder named branch, which is used to store a certified public stable version product:

  1. C:\Project Name
    1. C:\Project Name\Dev
    2. C:\Project Name\Release
      1. C:\Project Name\Release\v1.0

Typically, (1.i) would be used if you have many different versions of the same product.

From personal experience I tend to favor option 2. It seems to be less complicated of a branching strategy and allows development to be centralized to one location, rather than working from multiple branches and having to merge code if needed between branches. Typically the more complex the branching strategy the harder merges become and keeping code working in those specific configurations.

Regardless of which option is selected including this pathing structure in a version control system such as Team Foundation Server (TFS), Subversion, CodePlex, GitHub, etc. is essential to keeping development and release environments isolated.

Option 2 development environment

Working with option 2 in a development environment our folder hierarchy looks like:

Root Solution

When we expand Dev we see:

Expand Development Folder

As you can see we have two root folders inside Dev: (1) packages which include all pre-packaged assemblies (DLL) that Visual Studio creates for each new project and (2) the name of our solution. Expanding the name of our solution we see:

Expand Solution Folder

As you can see these are the folders in a given solution. As a reader you may be wondering why not publish all these to the server for production?

Simple answer - the server for production is expecting compiled assemblies (binary code 0’s & 1’s) and our dev folder doesn’t contain compiled assemblies except for those found in packages. When we write code in our Model, DAL or Controllers and build our solution the compiled assembly is referenced in the bin folder.

So how are we to know which files a published server needs to correctly display our website? Visual Studio publishing capabilities has the answer.