Deployment Strategies for ASP.Net web application used across several time zones

[Freaki Li Cuatre]

Is there any best practice for this kind of thing?

Want as little impact at all and ideally no downtime.

I'm not in a technical role at present but am I right in saying that with ASP.Net web applications there are a couple of different build models - one where it's compiled into a dll (in which case I assume there would be downtime to shut down the site and overwrite the old dll) and some kind of dynamic compilation model where the aspx files are deployed to the server and each page compiled into its own dll. Not sure if theres any need for downtime with this model though.

Thanks for any help.

[woohoo]

Is there any best practice for this kind of thing?

Want as little impact at all and ideally no downtime.

I'm not in a technical role at present but am I right in saying that with ASP.Net web applications there are a couple of different build models - one where it's compiled into a dll (in which case I assume there would be downtime to shut down the site and overwrite the old dll) and some kind of dynamic compilation model where the aspx files are deployed to the server and each page compiled into its own dll. Not sure if theres any need for downtime with this model though.

Thanks for any help.

I believe the default with ASP.Net is that the application once released is compiled when the first user hits the site. You can choose to precompile before release which has the advantage that the first person to hit the site doesn't get the hit of the compilation. Another advantage is that any compilation errors are going to show up before you release to production. Also, you don't have to release your source code to your production server (just the assembly).

The disadvantages of precompiling are if your making lots of little changes frequently then you have to recompile everything and release. With dynamic compilation you can just copy up say the .aspx page. If your copying a whole load of assemblies then the user downtime might be significant.

The advantage of dynamic compilation is as you said you can just release changes and the site will recompile and mostly your user will be unaffected unless the change impacts the page they are using.

It depends on your requirements but dynamic compilation is an ok approach in most cases (in my experience), especially if your making small frequent changes to pages. Most of your users will be unaffected unless they are using a page that has been updated

Not sure of your deployment strategy but test server->staging server->production is a good approach. It's good to catch issues before they get to production and you would be surprised how often a release from test to production goes wrong which is why a staging server is good.

[Freaki Li Cuatre]

I believe the default with ASP.Net is that the application once released is compiled when the first user hits the site. You can choose to precompile before release which has the advantage that the first person to hit the site doesn't get the hit of the compilation. Another advantage is that any compilation errors are going to show up before you release to production. Also, you don't have to release your source code to your production server (just the assembly).

The disadvantages of precompiling are if your making lots of little changes frequently then you have to recompile everything and release. With dynamic compilation you can just copy up say the .aspx page. If your copying a whole load of assemblies then the user downtime might be significant.

The advantage of dynamic compilation is as you said you can just release changes and the site will recompile and mostly your user will be unaffected unless the change impacts the page they are using.

It depends on your requirements but dynamic compilation is an ok approach in most cases (in my experience), especially if your making small frequent changes to pages. Most of your users will be unaffected unless they are using a page that has been updated

Not sure of your deployment strategy but test server->staging server->production is a good approach. It's good to catch issues before they get to production and you would be surprised how often a release from test to production goes wrong which is why a staging server is good.

Thanks for that. Pretty much as I thought then.

This is actually something I've been asked to consider by a prospective client before I go for interview and the more I think about it the more it seems like a "How long is a piece of string?" type question.

They merely state that it's an application that is used in several time zones. My assumptions are that it's a web app. Of course, what we were discussing earlier is only relevant to an Asp.Net webforms app since MVC doesn't use dynamic compilation.

What assumptions do I make about the infrastructure? Multiple web servers? In process session state? Are any database schema changes to be deployed?

I think the answer, in short, is to eliminate downtime altogether. That can be done if the right infrastructure is in place coupled with factors like a backwards compatible database design.

[garethevans1986]

Just automate the deployment process using TeamCity and Octopus Deploy.

I've managed to get a manual build/deploy down from 1hr to under 5 minutes using the tools above.

GE

[woohoo]

Just automate the deployment process using TeamCity and Octopus Deploy.

I've managed to get a manual build/deploy down from 1hr to under 5 minutes using the tools above.

GE

+1 for this, though I've only ever had one client that automated their deployment. Out of interest does TeamCity + Octopus work well with DB scripts?

[lilelvis2000]

Yeah when I need to deploy I have to run DB scripts to update the database, sometimes quite a lot of them. So downtime is inevitable.

I've been trying to get the team to at least use the VS publish feature. As presently the currently guy sucks all the source out of subversion on the server. Compiles the DLL and then resets the app.
Not entirely the best approach.

Do those tools help out at all?

[garethevans1986]

woohoo - Theres a tool that integrates with Octopus - ReadyRoll SQL Projects - Database change management I've not used it so cant tell you how it works etc but something for you to look at.

One other option is, to have a manual intervention step in the deployment - Manual intervention and approvals - Octopus Deploy 2.0 - Octopus Deploy

GE

[garethevans1986]

lilelvis2000 - You need both TeamCity and Octopus to do a build/deploy. I did have TeamCity setup to do both but it's easier to use the two seperate components.

GE