MS Deploy - New IIS Web Deployment Tool
_3.png)
Months ago, even before I started at Microsoft, I got to talk to some very nice people about a project they were calling AdminX. After I told them that that was very possibly the worst name they could possibly give it (and they took part that very well) we got to dig into what the tool was going to do. As with all great tools it did stuff that we had already written at my last company. It's always nice to throw home-grown tools away if found tools will do the job better.
Anyway, there's a Tech Preview of MS Deploy out for both x86 and x64. It installs a Windows Service, but it doesn't need to be running except when it's doing work so don't panic.
It's got a metric ton (a good thing) of options. For example, if I want to archive/backup a Site, I go:
msdeploy.exe" -verb:sync -source:appHostConfig="Default Web Site" -dest:archivedir=c:\mybackup
You can restore just by reversing source and dest. All the settings are maintained and stored in XML.
There's other "verbs" to use. For example, you can getDependencies (currently only on IIS6, IIS7 to come) and get details on exactly what your app needs in terms of authentication, filters, modules, etc.
You can transfer or 'sync' websites or web servers between each other like this:
msdeploy -verb:sync -source:webserver,targetName=http://computername/MSDEPLOY/ -dest:webserver > msdeploysync.log
Also, because there's a Windows Service involved, you can do remote deploys - that's the part we've all been waiting for. MS Deploy also supports the -whatif flag, showing you what will happen without doing anything.
There is also a plan to have a PowerShell cmdlet interface for MS Deploy when it releases, so things are looking up in the IIS space.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
roy
1) copy the update to a new physical dir such as c:\intepub\wwwroot\webapp\V_1_5_73
2) switch the physical dir in the virtual dir to the new physical from say c:\inetpub\wwwroot\webapp\v_1_5_72 to c:\inetpub\wwwroot\webapp\v_1_5_73
3)if necessary we could roll back to the old verison if there was a test escape and we needed to roll back.
the problem we always had was that we had to do this logged into the box. could never get this to fly remotely. in our server farm this meant logging into the boxes. if your tool can do this there will be much rejoicing.
would be great if you could give us a link to read more or better yet download it...
Download the x86 version or the x64 version of Technical Preview 1.
Could I ask you for a hint in the right direction for best practicies on updating a deployed web-applications? I've searched all over, including MSDN patterns & practices, but all I could find was "how to deploy", but nothing on updating excisting solutions.
Thank you
If you throw a RegEx book at someone to tell them "Learn this and you'll be ready to handle anything" that's cool for the first 10 minutes, then they'll forget half the stuff and be useless to you. The technology stack is already too high for normal consumption and this just piles it on even more. I like applying the 10 minute rule. Give me a tool and a half-decent example (not Hello World or in this case Hello IIS) and it should just work. 30 minutes with this thing and I'm still trying to tweak samples that should be simple (backup for example).
Of course it's my environment. It's not properly configured for this thing, not really sure if this can handle host headers or if it needs the real machine names. However all of that will be painful and long term growing pains with this (and similar) tools. The day someone builds an abstraction over this and says "Enter website here" "Choose operation here" etc. will be the day this becomes useful by all by the power-nerds.
Maybe I'm just being simplistic here, but I like to keep it easy. Complex tools with complicated command lines and all sorts of options (that I'll never use) just make the learning curve that much more steep. Sure I'll sit down for an hour (or two, or ten) and grok this, but that's not the point. It doesn't have to be this hard.
For example from my xp desktop at work I was trying to just backup a local site, then deploy a new version. Of course I realized later this only works with IIS6 and 7 and not 5, but the errors were not intuitive (Error creating class or something obscure).
However doing remote work against an IIS6 server I ran into various problems and again, probably due to firewalls, host headers, my lack of understanding of the IIS metadatabase, etc. To me, the tool certainly isn't entry level and like most MS solutions I've found over the years, *if* you stick to the examples (which are fine) and various stars align, IJW. However I find more often than not, I'm not in the pristine environment or situation so I end up struggling with new concepts and having to hunt down niggly bits of information from various forums and blogs (or having to crack open the thing in Reflector to see just what the heck was going on, like I had to do with TFS).
Maybe I'm an oddball and the exception to the rule.
I think you're an oddball. ;) If you've got a dozen boxes in a far and you want to deploy to all of them, you can't just "Publish to Website."
Comments are closed.