Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We are trying to simplify the publishing process by utilizing Web Deploy through VS2010. We want to be able to quickly rollback any broken releases, so we create folders for each release:

  • C:\www\1.0.0
  • C:\www\1.1.0

As of now, I publish the site locally, copy the files to the new release folder on our server, and then manually update the site's physical path to the new folder in IIS. Because the site points to a specific release's folder, I am unable to use web deploy on that site as the result would overwrite the existing files.

My solution to the overwrite problem was to create a deployment site that points to root folder (C:\www) and use web deploy to create the new release. The next step is to update the physical path of the site, but I'm unable to find a proper way to accomplish this. I'm aware of executing a command in the post-build event, but I'm getting a little lost with the web deploy documentation since the verb options are to sync, dump and delete.

When the publish is complete, I just need the IIS site to point to the new physical path. Is this possible? I'm open to alternative options (like publish locally then execute a batch file).

share|improve this question
    
I use this model on production servers as well and so far have not been able to make it work with Web Deploy. I use @squillman's approach for qa and staging, but the time it takes to 1) commit change 2) push repo 3) build and deploy is significantly longer than just changing the web root back. Still searching. I'm keeping on eye on Octopus (octopusdeploy.com) and project kudu (github.com/projectkudu/kudu) as possible alternatives. –  RyanW Nov 2 '12 at 21:46

1 Answer 1

If it's not already, then I'd recommend putting your project in source control and forgetting about different deployment targets based on version. Keep a single deployment target and if something in that build is broken then go back to the previous release in source control and redeploy that. That gets you out of the messy situation with multiple folders and having to modify your web root.

share|improve this answer
3  
Hi sorry squillman dont agree. What mathachew has asked for is perfectly feasible. we do exactly the same thing and as he mentioned its a great way of rolling back and providing less interuption when putting your new site up. All files can be copied up without interuption and at the last minute you switch the site over and it literally takes seconds. In answer to Mathachew, i am looking into this and will let you know if i find anything. regards, Andrew. –  user73831 Mar 10 '11 at 0:34
    
any answers to this? I have the same problem –  Martin May 10 '12 at 8:17

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.