Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 2 down vote favorite

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.

share|improve this question
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
1  
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
show 3 more comments

2 Answers

up vote 5 down vote accepted

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
share|improve this answer
great ....thanks dude.... – Pankaj Upadhyay Jan 11 '12 at 11:39
2  
... 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
up vote 2 down vote

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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