У нас должен быть отдельный экземпляр базы данных для каждого разработчика?

Подумал, что брослю это там, но почему бы не позволить каждому разработчику разместить свой собственный экземпляр SQL Server Developer на своих рабочих столах, а затем иметь общий сервер для каждого из них среды (разработка, контроль качества и продакшн)? Я думаю, что даже базовый MSDN, который поставляется с Visual Studio Pro (если вы выберете его), включает лицензию для SQL Server Developer.

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

РЕДАКТИРОВАТЬ: Я должен добавить, что настольный экземпляр позволяет разработчикам делать то, что администраторы баз данных часто ограничивают в общих средах. Это включает в себя создание базы данных, резервное копирование / восстановление, профилировщик и т. Д. Эти вещи не являются существенными, но они позволяют разработчику стать намного более продуктивным, одновременно снижая требования, которые они предъявляют к администраторам баз данных.

Общая среда совершенно необходима для тестирования - я бы не рекомендовал переходить с рабочего стола на продакшн. Но вы можете добавить так много, позволив разработчикам иметь 100% контроль над данной средой базы данных (включая изоляцию от других) с относительно небольшими затратами.

Простой ответ:

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

Мы делаем и то, и другое:

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

Что хорошо в этом подходе, так это то, что когда наш "источник истины" регистрируется в системе контроля исходных текстов, все изменения базы данных автоматически распространяются среди других разработчиков, когда они перебазируют и регенерируют. Это хорошо работает для нас.

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

Зависит от ваших циклов разработки, тестирования и сопровождения. А также от размера и местонахождения команды разработчиков (и, конечно, организации). Если вы поддерживаете несколько версий базы данных, вам может понадобиться еще больше окружений.

В реальном мире я нашел следующий подход довольно удовлетворительным:

• единая центральная база данных/приложение для целей тестирования, в которую периодически сливаются все изменения различных разработчиков
• локальные копии для разработки (так что вы можете свободно сбрасывать и перезагружать всю базу данных)
• скрипты обновления поддерживаются для любых изменений схемы, вспомогательных и выборочных наборов данных

Вот некоторые дополнительные моменты:

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

Если они работают над изменениями, которые не влияют друг на друга, они могут работать на главном сервере. Или на своих собственных локальных копиях базы данных.

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

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

EDIT:
Все вышесказанное предполагает, что наличие копии всей системы на локальной машине для целей тестирования вполне осуществимо (размер, производительность, лицензии и т.д.).

Я бы выбрал решение №1: одна общая база данных для всех разработчиков.

Плюсы

1. Меньше затрат на инфраструктуру;
2. Требуется только один дамп, когда пришло время обновить базу данных разработки;
3. Все разрабатывают одни и те же данные, поэтому они точно представляют производственную среду;

] Минусы

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

Что касается решения №2: Одна независимая база данных для каждого из разработчиков;

Плюсы

1. Это может быть полезно для разработки новых функций, когда разработка требует изоляции;

Минусы

1. Дороже для компания (инфраструктура, лицензии ...);
2. Умножение проблем, вызванных нетерпеливой изоляцией среды разработки (работает в среде разработчика, не интегрировано);
3. Умножение дампов администраторами одной и той же копии из производственной среды.

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

1. Одна база данных для разработки;
2. Одна база данных для тестирования интеграции;
3. Одна база данных для приемочных испытаний;
4. Одна база данных для новых разработка функции, которая, возможно, потребует интеграционных тестов.

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

Общая база данных

• Проще
• Меньше случаев "Это работает на моей машине".
• Форсированная интеграция
• Проблемы находятся быстро (fail fast)

Индивидуальные базы данных

• Никогда не затрагивают других разработчиков, но это тоже плохо, при непрерывной интеграции

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

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

По одному на разработчика плюс сервер непрерывной интеграции и сборки для выполнения модульных и интеграционных тестов. Это дает вам лучшее из обоих миров.

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

Лучше всего использовать одну базу данных на сервере Test / QA и одну базу данных (возможно, на локальном компьютере разработчика) для каждого разработчика (так, 10 разработчиков работают с 10 + 1 базами данных).

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

Кроме того, подход с несколькими базами данных упрощает хранение схемы базы данных в системах контроля версий. Мы храним скрипты создания базы данных в SVN.

Мы используем подход, описанный здесь: http://www.sqlaccessories.com/Howto/Version_Control.aspx

Зачем вам отдельная база данных для всех разработчиков? Имейте одну общую базу данных для всех, тогда структура таблиц будет согласованной, и sql-запросы тоже.

Самые большие проблемы с собственными базами данных у разработчиков:

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

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

Теперь на сервере общей базы данных должно быть то, что мы называем scratch database, место, где люди могут создавать и тестировать изменения таблиц, так что если они делают что-то, что может потребовать удаления и воссоздания таблицы (что должно быть редким случаем!), они могут сначала протестировать процесс, скопировав таблицу в scratch database и запустив там свой процесс, а затем изменив его на реальную базу данных, когда они будут уверены, что он работает. Или мы часто копируем резервную таблицу в нулевую базу данных перед тестированием конкретного изменения, чтобы можно было легко воссоздать старые данные, если они испортятся.

Я не вижу никаких преимуществ в использовании отдельных баз данных".