eWorld.UI - Matt Hawley

Ramblings of Matt

Why I Built WebDeploy

March 5, 2004 02:12 by matthaw

I've received multiple comments on why I developed WebDeploy rather than just using XCopy or VS.NET's inherint "Copy" tool.  I just wanted to take a brief moment to share why WebDeploy was built:

1. I wanted an easy to use tool that would allow me to deploy my personal and work web applications (or anything for that matter) without having to really think about it.
2. Most work environments require you to take the completed web applications and deploy them from a staging server, aka a User Acceptance Testing (UAT) server.
3. I like to use the GUI over the command line.
4. Deploy web applications easily across FTP (a feature soon to be added).

To explain #2 - in most work environments, developers use VS.NET on their local machines to build the applications. Then, a build script/process takes over to get a working build on a development server.  This is where the major problem comes into play...how do I get a build on UAT or on the Live server?  Well, almost all of the time, your UAT & Live servers don't have VS.NET installed...and more often than not, they don't have NAnt installed either...this means you have to manually copy the files from Development to UAT and then from UAT to Live.  Thats where WebDeploy fits in...it alleviates the headache of moving files from Development to UAT and then from UAT to Live servers.

To explain #4 - XCopy or VS.NET's "Copy" tool doesn't have FTP support.  Sure, the Whidbey version of "Copy" probably will have, but Whidbey is still a year out, what should we use until then?

So, I hope my explanation on why I built WebDeploy explains answers and gripes from those saying the same can be done with XCopy or "Copy"..because in practice, it really cant.



Categories: Unleash It
Actions: E-mail | Permalink | Comments (7) | Comment RSSRSS comment feed

Comments

March 5. 2004 02:33

More comments coming... =)



Your UAT or staging server shouldnt need NAnt, vs.net or any other build tool.



The way we currently handle this at work is by having a build server.  Our build server runs a process that uses NAnt to build the projects, then it checks the build back into source control as the latest successful build.  From here our infrastructure team (with no real knowledge of development) can check the latest build of our product into the correct application directory.  We use CVS as our source control and www.tortoisecvs.org is a nice shell enhancement for getting to the repositories via a GUI you are already familiar with, Windows Explorer.  So you install the cvs client on your server, and export your source controlled source code.  



Now, I really want to drive home that I am not dissing your tool in anyway.  It is damn nice.  I can see in a hosting environment where it could be EXTREMELY useful.  That said, the build process is a really nice way to go for enterprise or larger scale development.  It is a little bit of a headache to setup to begin with.  I basically had to figure it all out on my own.  NAnt made life alot easier, but it was just tedious work to get it working.



Jeff Gonzalez

March 5. 2004 02:56

Jeff - I can completely see where your coming from and agree with you.  I come from a small ISV - we have 1 SQL guy, 1 consultant that does some programming, and me...the main .NET developer.  Our environment is a bit different than a larger environment, where we have a development server, which I'm getting my team to move towards using as only a build server.  That server does have VS.NET installed, but that is due to the fact that we used it prior to using NAnt.



I've now created a process where we use NAnt for build scripts, which is GREAT...lemme tell you.  However, this process still doesn't allow us to put the "production-like" files on our UAT server very easily, or moving the UAT files to the live server.



So, I guess what I conclude between these things, is that I built the tool to aim at smaller development teams, or hobby developers that don't have a infrastructure team that copies builds to live servers for you.  I'm not saying its my way or the highway for using this tool, its up to you.  If you find it useful for something, great!  However...like some tools out there, free or $$, they just may not be for you.

Matt Hawley

March 5. 2004 04:01

I agree wholeheartedly.  The tool you made is excellent for smaller teams, without the infrastructure that we have at work.  I showed it to one guy and he is going to use it for his personal site.  Deployment profiles would be a very nice addition.  



Not sure if you are wanting to do this, but maybe you could make the project a sourceforge or gotdotnet project and allow a team to work on it with you?  I'd be willing to put in a few hours for additions if you decide to do so.



Jeff Gonzalez

March 5. 2004 05:17

I must agree that this is a great tool for small teams. I mean, who else would allow modification of your web app over FTP, that's just so easily hackable... Otoh most web hosting companies do not really give you a secure way to upload your content so this will be a great tool for hosted sites.



As for NAnt not allowing moving files to testing/live environments? Why doesn't it allow that? Just include fileset element inside a copy task, specifying file masks you want to move, including things such as moving only specific files in specific directories. And you don't need NAnt on the target server.

http://

March 5. 2004 05:29

Touche... not a bad idea.  I still like WebDeploy though ;)

Matt Hawley

March 5. 2004 09:14

If your main feature is FTP deployment, then the "last updated" file copy feature is a good addition. Why transfer a lot of files if you don't have to, especially if you are on a dial-up connection.

Scott

March 5. 2004 11:06

Thanks for another great tool. I'd been using robocopy scripts. This is much nicer.

Jon Galloway

Comments are closed

Copyright © 2000 - 2025 , Excentrics World