Как настроить среду разработки ASP.NET?

Question

Я веб-разработчик интрасети для довольно крупной компании, и мы наконец-то обновили серверы наших веб-страниц до Windows Server 2008. Ранее мы зависали на Windows Server 2000 и не имели доступа для запуска чего-либо, кроме ASP Classic.

Мы собираемся перейти к разработке на ASP.NET и использовать Visual Studio 2010 Professional.В обозримом будущем над этим сайтом будут работать только два разработчика.Мне интересно, как настроить нашу среду разработки, чтобы мы могли работать на этом сайте.

В настоящее время наш сайт состоит из: онлайн-форм, блога, фотогалерей, информационных ресурсов и т. Д.

Мы получаем три новых сервера под управлением Windows Server 2008. Они будут настроеныкаждый со своей ролью.Разработка, обеспечение качества и производство.

Я совершенно не понимаю, как мы должны развиваться в нашей среде.Вот несколько сценариев, о которых я подумал, но я уверен, что есть и другие варианты.

1. Работа с файлами, расположенными на сервере разработки.
2. Проверка завершенных обновлений наСервер разработки
3. Публикация в QA и повторное тестирование
4. Публикация в производство и повторное тестирование

Или

1. Разработка на наших локальных машинах(Если мы делаем это, как мы справляемся с извлечением любых файлов, необходимых для обновления чего-либо?)
2. Публикация изменений в разработке
3. Выполните шаги 2-4, перечисленные выше

Заранее спасибо всем, кто может мне помочь.Я действительно хочу вникнуть в это правильным способом, чтобы мы не создавали вредных привычек, которые нам придется сломать позже.

Answer 1

В нашей компании мы используем ваш второй вариант (сначала разрабатывать на локальных машинах, а затем развертывать / копировать на серверы для дальнейшего тестирования). Для обработки получения исходных файлов мы используем Team Foundation Server (который был бесплатным с нашими подписками MSDN) для управления исходным кодом - я очень рекомендую какой-либо тип системы управления исходным кодом для любого магазина разработчика: помогает, когда вы случайно удаленные файлы, перезаписанный код, внесенные вами изменения в алгоритм и т. д.

Причина, по которой мы это делаем, заключается в том, что, хотя у нас не так много разработчиков, работающих над одним и тем же приложением в одно и то же время, в прошлом у нас были проблемы, когда один разработчик перезаписывал работу другого, думая, что это не повлияло бы на другого человека, но стерло много часов работы (и это случалось много раз в прошлом с приложениями, над которыми работали только два человека). Кроме того, вы (разработчик) имеете полный контроль над средой, поэтому вам не нужно беспокоиться о том, что администраторы вносят изменения, которые нарушают ваш код, когда вы пытаетесь выяснить другую проблему (например, они сбрасывают IIS без объявления в dev) .