The ideal, even with a small group, is to have three machines:
1. A development machine (or one for each developer)
2. A Test machine
3. A Production machine
You develop your code on the development machine. when you think it is
ready, you deploy (typically, for me, xcopy) to the test machine and your QA
person (in a small team that may be the other developers, or your client
test it. When it is ready, you then deploy to the production machine. You
never (except when you do) change code on the production machine that hasn't
been tested on the test machine.
I personally use xcopy development, put anything that might be different
between machines in web.config and ftp the files from one machine to
another, making sure to either fix up the web.config on the other machine or
not to copy over the unchanged web.config later in the project.
You can use the Enterprise Library's configuration tool to edit the
web.config if you would rather not muck about with a complex web.config
tool. See
http://msdn.microsoft.com/practices/ -- but that is using a big
hammer for a small nail.
Hope that helps; if not, just holler :-)
--
Jesse Liberty
Author, Programmer
Microsoft MVP
<ja***@cyberpine.comwrote in message
news:11**********************@m73g2000cwd.googlegr oups.com...
In a small shop with 3 .net developers. What would typically be
considered a good deployment practice if there is a chance of
developers might be working on the same websites at the same time?
Do most developers work on the desktop and deploy individual sources
using xcopy compiling on the remote web servers?
