Octopus 2.0 Part 10 - Deploying an asp.net web application

In this video, I’ll show how Octopus can be used to deploy an ASP.NET web site. Here I have an ASP.NET MVC web site. I’ve used OctoPack to package up the site. OctoPack knows that when packaging an ASP.NET site, it should only package the content files – that is, the views, JavaScript, CSS and image files – needed to run the application, as well as any binaries and configuration files. I’ll be deploying this web site to machines in my web-server role. For Test and Acceptance I only have one machine in this role, but for the production environment, I have two web servers. I’ll go to the process tab in my project, and add another NuGet package step to my deployment process. I’ll turn on the Configuration Variables feature, because my ASP.NET web site is using a connection string in the web.config file, which I want Octopus to automatically update. I’ll also enable the Configuration Transforms feature, because I have a Web.release.config transformation file that I want to run. Instead of running configuration transforms at build time, Octopus actually runs them during deployment. You can even have different configuration transform files depending on the environment you are deploying to. Finally, I’ll enable the IIS web site and application pool feature. I’ll specify the name of the web site in IIS that I will be deploying to. I’ll reference an Octopus variable so that I can use a different web site names depending on the environment. I’ll also specify the name of an application pool to create or update in the same way. I can tell Octopus to configure the application pool to run under a specific identity, including as a custom user. I can also specify the bindings that the IIS web site will listen on. I’m going to remove the default binding, and add a custom binding, using the name of the current machine as the host header for the binding. Finally, I can choose which authentication modes IIS should enable. Now, I showed before that I have two web servers in my production environment. By default, Octopus runs the package step in parallel on all machines in the roles I specify, meaning that normally, both web servers would be updated at the same time. Instead, I can configure what we call a "rolling deployment". I can specify a batch size – that tells Octopus how many machines should be deployed to at any one time. For example, if I was deploying to ten servers, and I specified a batch size of one, it would deploy to one machine, and then the next, and the next, and so on. Since this is a rolling deployment, I can also add a child step. Child steps are executed at the same time as the parent step. In my rolling deployment, this means that both steps are executed on one machine, and then when they finish, the rolling step will start on the next machine, and the next machine, and so on. My child step is simply going to be a PowerShell script that waits 10 seconds, so that you can see the rolling deployment in action. I’ll create a release and deploy it to my Test environment. Viewing the logs, I can see that the web site has been deployed, and we are now waiting on the sleep operation. If I browse to the test web server, I can see that this site is now running. I’ll promote this release to Production. Note that in the preview, it will run on both web servers. The first server has been deployed to, and if I refresh the site in IIS, I can see that the site is loading. But if I refresh the second server, it is still showing the IIS landing page. Eventually the rolling deployment has finished, and now both web servers are running the site.