Это нормально для разработки с базой данных DEV, расположенной на том же сервере SQL, что и живое производственное приложение? - PullRequest
1 голос
/ 09 октября 2009

Иногда у нас до 4-6 человек либо RDPed просматривали данные в SQL Management Studio, либо били по серверу с помощью LINQpad, Toad и т. Д. Из разных мест, разрабатывая в основном ASP.NET и Flex с WebOrb. Это плохо? Плохо в том смысле, что мы пытаемся обеспечить стабильную работу нашего живого производственного приложения и максимально возможную задержку для глобальных пользователей?

Ответы [ 10 ]

6 голосов
/ 09 октября 2009

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

С наилучшими пожеланиями, дон

4 голосов
/ 09 октября 2009

Лучшей практикой будет использование отдельных серверов. Далее лучше отдельные экземпляры на одном сервере. Далее лучше отдельные базы данных в экземпляре.

Однако я бы не позволил ни одному разработчику RDP подключиться к производственному SQL Server (или к чему-либо еще) независимо от выбора механизма разделения. Используйте отдельный сервер терминалов с инструментами и все там.

3 голосов
/ 09 октября 2009

Это зависит от множества переменных. Как правило, лучше иметь их на разных серверах. Это действительно зависит от того, как вы используете SQL Server. Если у вас просто есть базы данных, не используйте много инструментов управления, таких как ночные процессы для изменения данных и другие задания, с которыми вы можете быть в порядке. Однако вы рискуете столкнуться с тем, что код переходит от разработки в базе данных dev к производственной. Безопаснее разделять их, особенно за небольшую сумму денег, необходимую для создания экземпляра сервера SQL.

2 голосов
/ 09 октября 2009

Вы можете использовать dev и prod db в одном экземпляре. Просто убедитесь, что разрешение настроено так, чтобы разработчики не могли коснуться prod db. Отрицательным является то, что длительный запрос в dev повлияет на prod. В SQL SERVER 2005 лучшее решение - использовать dev "instance" и prod "instance". Тогда кто-то плохо себя ведет в случае с вами и просто разрушает этот страх. В SQL Server 2008 вы можете настроить планы использования ЦП, которые помогут регулировать объем используемых ресурсов. Вы должны расследовать это.

1 голос
/ 09 октября 2009

Я склонен согласиться с людьми с «отдельными серверами», хотя с моей компанией мы фактически выполняем большую часть нашей повседневной работы по разработке на наших локальных компьютерах - поэтому у нас установлен SQL Server локально. Конечно, это может быть неприятно, если вы разрабатываете отчеты или что-то, что требует производственных данных. В этом сценарии разработчики, как правило, получают подмножество производственных данных, экспортируемых для работы.

Для приемочного тестирования и развертывания мы используем отдельные экземпляры.

Разработчики, вероятно, не должны иметь доступа к продукту, если только они не занимаются развертыванием приложений (как это может быть в случае с небольшими командами, такими как та, в которой я работаю). Если вы в конечном итоге используете отдельные БД на одном и том же сервере, я бы по крайней мере заблокировал доступ RDP и предоставил бы доступ к каждой БД разработки на индивидуальной основе. Вот как это работает здесь - у меня нет прав администратора ни на одном из наших серверов, и я могу администрировать базы данных только для приложений, которые принадлежат именно моей команде.

1 голос
/ 09 октября 2009

Я считаю это плохой практикой по нескольким причинам:

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

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

В-третьих, если база данных находится на том же сервере, у нее должно быть другое имя, это может затруднить перемещение и вызвать ошибки. Я думаю, это также означает, что менее вероятно, что вы развернете правильно с помощью сценариев, контролируемых исходным кодом. Если вы решите скопировать объекты из одной базы данных в другую, то у вас могут возникнуть проблемы с этим. Во-первых, если в объекте уже есть данные, вы можете случайно стереть их (надеюсь, у вас есть резервная копия) или вы можете переместить новую структуру таблицы, но пропустите такие вещи, как PK и FKS, а также значения по умолчанию, триггеры, ограничения и индексы или мастеру может потребоваться гораздо больше времени для перемещения, поскольку в фоновом режиме он создает и заполняет новую таблицу, а затем удаляет старую и переименовывает новую, а не использует alter table. К сожалению, продукт не работает или серьезно замедлен без веской причины.

0 голосов
/ 09 октября 2009

По другим причинам тестирования приложений мы создали копию нашего рабочего сервера (который является виртуальным сервером) в отдельном домене. Это позволило идентифицировать имя сервера Windows, имя SQL Serer и имя базы данных (многие настройки сторонних приложений требуют такого уровня конфигурации для работы различных процессов). Теперь мы можем перестроить тестовую среду, создав точный виртуальный образ нашего рабочего сервера.

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

0 голосов
/ 09 октября 2009

Это будет «ОК», если у команды нет прав администратора на сервере (SQL или Windows), а их учетные записи пользователей просто предоставляют доступ, чтобы потенциально уничтожить только базу данных разработки и связанную с ней файлы, отказавшие в доступе к производственным базам данных

0 голосов
/ 09 октября 2009

Обычно я использую настройку базы данных DEV на локальном экземпляре SQL Server (версия для меня, но Express, вероятно, также будет работать), базу данных QA на тестовом экземпляре SQL Server. В нашей среде это находится на виртуальном экземпляре W2K3 - скоро будет W2K8. Производственные базы данных живут либо на выделенных экземплярах сервера SQL, либо на одном из различных кластеризованных экземпляров. Мы вообще не смешиваем PROD / QA / DEV. Я использую RedGate SQL Compare для синхронизации схем между различными системами, включая разные экземпляры базы данных для разработчиков.

0 голосов
/ 09 октября 2009

Зависит от того, насколько вы цените свою живую услугу. Я знаю, что не буду доверять мне и моим толстым рукам, использующим SQL на том же оборудовании, что и живое приложение.

Даже если приложение не является критически важным для бизнеса, и приложение не привязано к данным, вы можете настроить среду разработки на неиспользуемом настольном компьютере, так почему бы не сделать это вместо того, чтобы рисковать? *

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...