I follow a very raw approach while updating my website on server. The approach I follow doesn't seem right, so I am interested in knowing a recommended way of updating a LIVE project, be it on shared host or dedicated server.

Right now, for any changes in View, I simply upload and overwrite the view files on server. Similarly for any code changes, I upload and overwrite the .dll and .pdb files. Currently my website doesn't have any traffic so there has been no issue so far. But, Is this a recommended approach for a website with good amount of traffic. And if not, then how should one approach updation on the server.

  • How else would the files get there except by copying and overlaying the old files? WHat problems do you foresee? Are you worried about testing? – S.Lott Jan 11 '12 at 11:33
  • I mean if thousand vistors are visiting my site and i overwrite the main dll file. Won't they see errors ? Should we do some redirect to construction page or use sub-domains for transfer. For example, SO also makes changes but we never see it down for a second. Or I need not worry about these things – Pankaj Upadhyay Jan 11 '12 at 11:37
  • 3
    @PankajUpadhyay: I've seen SO, and particularly Programmers.se "offline" many times. It just tells me to come back later, and I do. – pdr Jan 11 '12 at 11:43
  • 1
    @PankajUpadhyay If you have some visitors but not enough to justify more than one server, then I just a deploy script that runs in off-peak hours. I wouldn't worry about this issue. If you have thousands of visitors per day then you are probably making good money and you can pay somebody to worry about this for you :-) – maple_shaft Jan 11 '12 at 13:03
  • 2
    1000 visitors. Let's say they each click a dozen times. And they're spread over a 12 hour window. That's an average of a click ever 3.6 seconds. You can easily copy all of the files between clicks and no one would even notice. – S.Lott Jan 11 '12 at 19:29

What many high traffic sites do is deploy using a web farm.

The general workflow is like this:

  • Take half of the servers off the farm
  • Update these servers and test
  • Put servers back in farm and take remaining servers off the farm
  • Update these servers and test
  • Put remaining servers back in farm

If this is no possible, I suggest creating two sites on your live server - a live site and a deployment site web applications and directories:

  • Deploy to the deployment site
  • Test
  • Change IIS configuration so:
    • The live site now points to the directory of the deployment site
    • The deployment site now points to the directory of the formerly live site
  • 3
    ... and script the process, whatever it is, to remove human error. If you use WebDeploy (I'm assuming IIS/.NET from the mention of PDBs) to do the copy, you can use the Web Farm Framework to automate the first approach. The second can be done easily in Powershell. – pdr Jan 11 '12 at 11:51

From your question it seem like you only have one server, which begs the question "How do you test your changes?"

A better workflow would be to make the changes on your development PC and upload them to a test server first and then test the changes there. This "test server" need not be a physical server; it could be a virtual machine on your development box. The point being that changes need to be tested on some sort of webserver with the appropriate database engine or whatever your website requires. Ideally you would have some sort of automated regression and link checking etc to make sure that the changes you made did not break anything.

Once you feel happy with your changes then they would be moved to a staging site for turnover to production. The staging site should be as close to your production environment as possible. Further it should be accessible to your clients and users so that they can review and approve the changes before being placed into production.

Once everyone has had a change to review and approve the changes on the staging site the next step is to move them to the production server. Depending on the changes this might be as simple as copying files or could possibly involve schema changes to database tables etc.

The key to properly moving from the staging site to the production site is to insure: 1) You have a complete backup of the production site. 2) Have a plan to revert the changes (restore the backup files perhaps) should your changes cause a problem.

For a high volume or mission critical site you might have multiple sets of production servers with the changes moved from staging to half the servers at a time so that the website is never down. For the majority of sites scheduling 5 minutes of down time in the middle of the night to backup files and move the changes to a single production server is probably more than good enough.


Load balancing refers to efficiently distributing incoming network traffic across a group of backend servers, also known as a server farm or server pool.In this manner, a load balancer performs the following functions: Distributes client requests or network load efficiently across multiple servers.

You want to try to load-balance your site, that means you have two identical instances running. In case of an update, tell the load-balancer to only forward traffic to one instance and update the "offline" instance.

When the update is done, switch the load-balancer to the other instance and again update the instance that's not publically reachable.

Once you're done, revert the load-balancer config to distribute load across both instances. This way your website is online even during updates and your visitors won't even recognize it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.