There must be a better way than just
"Publishing" in Visual Studio and then
having to manually FTP the files that
have changed?
Occam's razor is typically the preferred approach: the simpler, the better. FTP is easy with little to no complications. Some people use XCOPY, Filezilla or WSFTP, others may use the MS Web Deployment Tool (which I'm not familiar with yet), but all-in-all, there is a better way of deploying ASP.NET web apps (and other apps in general). IMO, if deployment is taken into consideration from the beginning of development, deployment can be integrated with the web app which makes for a relatively pain-free and smooth deployment in the future.
As a .NET developer who has worked at several companies developing ASP.NET web apps ranging in size, complexity and number of users (from several hundred users to tens of thousands), IMO 'deployment' is often the most "fluid" topic. Some organizations take it too far in terms of bureaucracy while others don't address any issues with deployment at all. In my experience, issues with deployment tend to fall into 1 or more of 3 categories in terms of difficulties/failures:
Deployment is ignored/forgotten in depth during the design phase:
Most web apps tend to incorporate a web server and a database. Beyond application code, maybe some stored procedures and database tables, deployment doesn't need much thought. ASP.NET is more than capable of aiding in deployment but most often developers are distracted in terms of getting the actual application running and doing it's task while leaving the how of deployment as a separate issue.
Deployment is complex across multiple systems and people at play:
Complexity is a bitch. From MSMQ, T-SQL stored procedures and triggers, Reporting Services, SOAP/XML messaging, AD authentication, SSAS/SSIS, etc. etc. the number of technologies at play increase the number people involved. Worst of all, all these different components are typically managed by different entities within an organization. Unless everyone is in sync with one another, deployments can increase in complexity quickly leading to multiple points of failure.
Laziness, apathy or lack of communication and/or management:
From little to no documentation to lack of coordinated communication and protocol, it's easy to screw up a relatively simple process. Deployment should be a simple procedure with numerous checks in place all the while documenting what's done, but often it's never the case. Most people just want the damn site to be up an running. In my experience, people (non-programmers) don't really care until something goes really fubar. Responsibility seldom falls on just one person to actually do the deployment as no one really wants to be the reason for failure so accountability is usually dispersed.
There are so many fiddly file
exceptions that I'd must rather
automate the process as much as
possible, to prevent accidental
uploads. So how does your team do it?
I don't know of any vendors on hand to automate deployment although I wouldn't be surprised if there were a few. You could probably script a solution via VBScript/WMI or batch script a solution, but the reality is you need to tailor a solution together for more complex ASP.NET sites. Simple sites consisting of pages, database connectivity and nothing else, you don't need to do nearly as much so scale your deployment efforts in line with the complexity of the application itself.
So far, at my current work deployment is still done over FTP and moving a bunch of files. It's ugly, easy to screw up and there's no sense of an accurate history. Granted you could comb through FTP logs, no one really bothers to do so. Our apps are fairly simple without much need beyond FTP. How my team deploys our web apps is of really little to no use for you. Instead, I'd rather use this opportunity to suggest better practices.
- Assume nothing. User accounts, R/W/X privileges, ACLs, firewalls, timing (when to deploy and how much time you have to do it), and if possible, test deployment to all environments before the final "launch date".
- Before development actually begins, factor deployment into development. If it's a simple site, so be it. If there are numerous moving parts, factor all of it in and actually build a plan to which all the components (code, database, reports, queues, etc.) are all on the same plan.
- Coordinate with other parities and communicate effectively and efficiently.
- Document as much pertinent information if possible.
- Environment: one web server vs. web farm; 32-bit vs. 64-bit; find a way to monitor logs/errors/rotate, etc.
- Find (or build) tools that can aid in deployment.
- If possible for programmable deployment, pick a paradigm and stick with it. For example, if you want to use a database server as the primary means for carrying out an application's state, deployment, access and such, bake it into the application and stick with it. If you prefer reading XML files (like web.config) by all means, just stick with a consistent paradigm of deploying the application. Another example: some organizations leave web.config as a static file in each environment that should not be deployed to other environments. Other's program web.config in such a way that it can be deployed across environments without error.
I realize that this post might be overkill for the question that was originally asked. Unfortunately, deployment just isn't a simple thing as applications can vary in complexity. I'd bet that most organizations that deploy complex ASP.NET apps have over time developed certain strategies the work (at the least) reliably.
