Лучшая практика в среде разработки и тестирования?

Question

Этот вопрос для разработчиков ASP.NET и SQL Server. Каковы ваши лучшие практики по настройке среды разработки и тестирования? Мне интересны следующие вопросы:

1. Сколько уровней вы рекомендуете и что происходит на каждом уровне? Просто dev, test, and production или, возможно, dev, test, staging and production?
2. Какие типы приложений и / или серверов должны работать на реальном физическом оборудовании, а какие - с виртуальной машиной?
3. Каковы ваши стратегии для слабой связи пользователей с веб-сайтов, веб-разработчиков с их веб-серверов / серверов приложений / БД и разработчиков БД с их серверов БД?
4. Как разработчики остаются «сухими»? (без шуток с дезодорантом, пожалуйста;)
5. Каковы преимущества и недостатки размещения веб-серверов, приложений и БД на своих компьютерах? Помогает ли размещение серверов на отдельных машинах минимизировать конфликты за ресурсы машины, превосходящие любые сетевые адаптеры и сетевые задержки, которые могут возникнуть при размещении их на разных машинах?
6. Как настроить веб-приложения таким образом, чтобы минимизировать конфликты за ресурсы (например, виртуальные каталоги, отдельные пулы приложений и т. Д.)
7. Как и как часто вы обновляете свои базы данных на каждом уровне? Вы просто обновляете данные или и данные, и объекты?

Спасибо.

Answer 1

Я не могу комментировать все это, но вот что я нашел, чтобы работать лучше всего в моем опыте.

1) Зависит от ваших ресурсов, но в идеале мне бы хотелось иметь 4.

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

QA обновляется по расписанию или на основе доставки в зависимости от вашего процесса.Если вы делаете водопад, он обновляется, когда вы находитесь в фазе тестирования, если вы делаете итеративную гибкую настройку, он обновляется каждую итерацию.Это должно имитировать продакшн как можно ближе, но вы можете избежать компромисса (см. # 2)

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

& Prod

2) Dev обычно может быть на ВМ.QA может тоже большую часть времени.Постановка и прод должен соответствовать.Я уже видел, как люди запускали prod на виртуальных машинах, это зависит от ваших ресурсов и спроса на ваше приложение.

3) Наши разработчики используют резервную копию prod на локальных серверах SQL для разработки.Это удерживает всех от центрального сервера разработки SQL.Dev web и dev sql - это отдельные блоки (просто по необходимости они управляют кучей проектов). То же самое с QA, Staging и Prod.

4) Много испытаний и общения.Если у вас есть одна маленькая / средняя команда, это не так сложно.Если у вас много команд, посмотрите на что-то вроде разборок, официальных проверок кода, на то, чтобы поддерживать связь между командами.Не рассматривайте проблемы СУХОГО как предложенные исправления, рассматривайте их как ошибки, которые необходимо исправить.Вы потратите гораздо больше времени на обслуживание кода, чем на его предварительную запись, поэтому относитесь к обслуживанию как к гражданину 1-го класса и убедитесь, что руководство работает с этим.

5 & 6) Не совсем квалифицирован, чтобы комментировать

7) Разработчик, когда командам необходимо, QA и в соответствии с графиком в зависимости от развертываний.QA - это каждая итерация / спринт, Staging и Prod - это каждый релиз.