Безопасно ли и приемлемо ли устанавливать VS.NET на ваш производственный сервер?

Question

Обычно мы устанавливаем VS.NET на нашем производственном сервере, чтобы при необходимости легко решать проблемы с нашим продуктом.

Это хорошая или плохая идея?

Answer 1

Отладка и разработка должны выполняться в «безопасной» среде - что-то, что не является критическим. Например, у вас должен быть сервер разработки и/или QA, который вы используете для разработки и отладки.

EDIT: Ваш сервер QA должен отражать ваш производственный сервер, чтобы вы могли отлаживать среду, похожую, если не идентичную, в вашу производственную среду.

Answer 2

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

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

Answer 3

В зависимости от того, как вы его используете. Большая часть тяжелой работы, для которой он предназначен, не должен быть необходим на производственном сервере. Обычно я устанавливаю Notepad ++ на рабочий сервер для редактирования xml, файлов конфигурации и т. Д. Я бы сказал, если вы хотите установить VS, идите на это.

Answer 4

Рекомендуемый способ - иметь зеркало производственного сервера для тестирования/отладки. Чтобы сохранить текущее зеркало, вам необходимо одновременно установить все обновления приложений на обоих серверах и создать резервную/восстановительную производственную базу данных на зеркале по ночам или по требованию.

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

Answer 5

Я бы никогда ничего не делал непосредственно на производственном сервере, для которого потребуется Visual Studio. Слишком рискованно делать изменения в производстве, которые не возвращают его в базу кода и, следовательно, в управление версиями. В конце концов, вы в конечном итоге вернете ошибку, которую, по вашему мнению, решили, потому что вы только изменили ее на рабочем сервере. Иногда я обновляю файлы разметки или XML на производственном сервере, но только после внесения изменений в разработку и проверки их в поле QA и только тогда, когда не задействован никакой реальный код.

Answer 6

Конечно, это зависит от продукта и от того, что вы отлаживаете. Вообще говоря, вы должны попытаться избежать этого, но есть случаи, когда вы не можете точно дублировать сценарий на сервере тестирования, и может быть полезно приложить отладчик к выполняемому процессу, чтобы быстро сузить проблему. т.е. если вы используете сервер MMORPG, и есть некорректная ошибка, которая возникает при определенных условиях загрузки, вы можете потратить недели или месяцы, пытаясь понять это из файлов журналов и/или смоделированных соединений на сервере тестирования, или можете присоединить отладчик, пока проблема возникает в реальном времени на производственном сервере, и выясните это через час.

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

Answer 7

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

На месте работы разработчикам не разрешен доступ к какой-либо производственной среде, которую обрабатывают серверные/сетевые команды, но это потому, что это большой бизнес. Для небольших фирм разработчики будут иметь доступ, но это не значит, что вы должны использовать его для отладки.

Answer 8

Посмотрите на номер Production Debugging Саши Гольдштейн на его blog. У него есть отличные пошаговые руководства и скринкасты о том, что можно сделать для отладки без Visual Studio.

Answer 9

Это действительно зависит от того, вы принимаете ли риск, что установка приносит с собой:

• висячие производственных приложений, когда кто-то присоединяет отладчик к неправильному применению.
• Это ломается с тем, что считается лучшей практикой, так что вы собираетесь сломать со следующей? В худшем случае люди начнут делать задачи разработки по производству
• Потенциальные проблемы с получением поддержки, я бы пометил с Microsoft, если IIS и SQL Server и т. Д. Поддерживаются в производственной среде, где установлен VS.

Вы также должны спросить себя, что является самым сложным с отладкой вопрос без VS на сервере:

• Вы знакомы с stack traces and how to read them?
• Вы знаете, как запустить версию режима отладки приложения по сравнению с версией/свободной сборкой?
• Знаете ли вы, что вы можете использовать приложения SOS debugger extension для .NET с помощью Windows Debugging Tools?
• Рассматривали ли вы использование инструментов для автоматического сбора и отправки отчетов о сбоях сервера?
• Что вы делаете для предотвращения проблем, возникающих в производстве. Можете ли вы сделать какой-то статический анализ, перепроектировать модули на основе проблем или использовать технику, такую ​​как тестовая разработка?

Answer 10

Это определенно не приемлемо. Прежде всего, для отладки вы всегда можете использовать инструменты отладки для windows/windbg. Поддерживает также отладку .NET (SOS/сын забастовки) и с чит-листом не так сложно использовать. Windbg может работать с USB-накопителя без установки.

Во-вторых, и самая главная причина: всякий раз, когда вы устанавливаете какую-либо новую версию VS, она регистрирует свой отладчик для интерактивного режима ** - вы получаете окно сообщения при возникновении исключения. Вам необходимо вручную отредактировать реестр, чтобы вернуться к поведению по умолчанию после установки - и никто этого не помнит.

Не делайте этого. Существуют более эффективные способы диагностики проблем.

Answer 11

Обычно считается, что это не «Лучшая практика» для установки Visual Studio на рабочих серверах. Это может привести к рискам безопасности, но одна большая проблема, с которой я столкнулся, - это производительность. Visual Studio использует огромное количество ресурсов и запускает отладку, что может существенно повлиять на производительность производственных приложений.