Разрешить ли разработчикам использовать LocalDB против экземпляра «разработки»?

Очень похоже на вопрос, который был опубликован здесь ранее: « Могут ли разработчики запрашивать производственные базы данных? » Я хотел бы поделиться вашими соображениями по другой особенно раздражающей теме!

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

В частности, это сделано для обеспечения:

• Соответствие уровня исправлений между серверами разработки и производством
  
• Возможность доказать и проверить любые патчи на выше
  
• Безопасность данных; только данные на серверах разработки используются для разработки
  
• восстанавливаемость; данные восстанавливаемы и до сих пор сохраняются
  
• Различия в сортировке, которые могут вызвать проблемы при переносе в производство

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

Похоже, что сопоставление не является действительной причиной, так как если это касается базы данных, ее следует установить при ее создании в любом случае. Насколько мне известно, только SharePoint и SCCM имеют проблемы с этим;)

Теперь, предполагая, что это ТОЛЬКО для разработки, и база данных не будет «перемещена» в производство, и единственными движениями будут:

• Скрипты, которые создали базу данных, создаваемую для развертывания в производство
• Резервные копии из «производственных» сторонних систем восстанавливаются и усекаются в случае необходимости для проверки и разработки.

Кто-нибудь может увидеть какие-либо проблемы? Я что-то пропустил?

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

Да. Все разработчики должны иметь локальный экземпляр SQL Server И общий экземпляр SQL-сервера. Они существуют для разных целей. Оба необходимы.

Возможно, ваша текущая среда выглядит так?

Выше несколько разработчиков создают изменения и размещают их в общей базе данных SQL Developer. Это плохо. Microsoft MVP Troy Hunt документирует некоторые болевые точки этого устаревшего подхода, здесь . Основные из них ...

1. Неспособность надлежащим образом контролировать источники. BIG!
2. Невозможность настройки производительности без прав на уровне сервера.
3. Неспособность экспериментировать без влияния на других.

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

На приведенной выше схеме каждый разработчик использует Visual Studio для записи и сохранения изменений своей базы данных в локальный экземпляр SQL Server. Эти локальные изменения затем синхронизируются в соответствующей системе контроля версий. Здесь каждый разработчик может спроектировать и поэкспериментировать в среде, где его изменения не будут влиять на кого-либо еще до регистрации. И тогда конфликты будут разрешены.

Локальная база данных, использованная выше, может быть редакцией LocalDB, Express или Developer. Простой-Talk делает большую работу , взвешивая плюсы и минусы каждого из них здесь . Существует причина, по которой Microsoft создала так много вариантов локальных баз данных для разработки: LocalDB, Express, Developer ... мы должны их использовать!

Если вам нужно выбрать, трудно не спорить, что у каждого разработчика установлена ​​локальная версия SQL Server Developer edition. Это абсолютно бесплатно и имеет функциональное соотношение с редакцией Enterprise. Это позволит всей вашей группе безопасно исследовать и проектировать весь стек Microsoft BI (SQL Server, SSIS, SSRS и SSAS).

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

Для меня все эти аргументы являются особенно недействительными

Хорошо. Но они не для всех нас. Почему?

Соответствие уровня исправлений между серверами разработки и производством

исправление было бы доказано, когда приложение прошло через Test

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

Безопасность данных; только данные на серверах разработки используются для разработки

Полезно отделить «что должно быть» от «что есть». Разработчики получают конфиденциальные (не обязательно PII, но и не бесплатные) данные в своих базах данных. Бывает.

восстанавливаемость; данные восстанавливаемы и до сих пор сохраняются

Супер важно.

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

Только SharePoint и SCCM имеют проблемы с этим

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

при условии, что это ТОЛЬКО для разработки, и база данных не будет "перемещена" в производство

Зачем нам это считать? Вещи часто идут от разработки до производства. Как еще вы попали в производство впервые? Чистые сценарии? Не обязательно, когда приложение находилось в стадии подготовки в течение некоторого времени.

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

Вам просто нужно сделать заявление о том, что вы делаете и не поддерживаете и почему.

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

Но консолидация на централизованных серверах разработки все же имеет смысл. А теперь, когда Developer Edition бесплатен, еще проще оправдать наличие большего количества из них.

Концептуально говоря, вы на правильном пути. Для организации, у которой есть зрелый процесс разработки / жизненный цикл разработки программного обеспечения (SDLC), который включает в себя контроль исходного кода, непрерывную интеграцию (CI), автоматическое тестирование и ИТ-группу, которая знает, как управлять различными средами и рабочими станциями, чтобы поддерживать их синхронизацию что касается программного обеспечения и уровней исправлений, а также дисциплинированных разработчиков, которые а) следуют процессу, б) работают вместе и в) работают с ИТ, то могут иметь 50 (или столько же) БД для разработки:

• Да, согласованное программное обеспечение и уровни исправлений могут поддерживаться на любом количестве рабочих станций.
• Да, любые «проблемы» могут возникать в автоматизированных средах тестирования и / или QA / UAT.
• Многие dev-базы данных не так просто создать резервную копию, но и не невозможно. При использовании перемещаемых профилей резервное копирование файлов данных, находящихся в папке «Локальные настройки» каждого пользователя Windows, может быть проще. Или, по крайней мере, ИТ-специалисты могут создавать сценарии для захвата файлов со всех рабочих станций разработчиков, аналогично тому, как они гарантируют, что все исправлены должным образом.

НО, как и во всем остальном, это действительно сводится к контексту ситуации.

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

ОДНАКО, есть различные вопросы для рассмотрения:

• Каков размер команды и сколько человек работает над каким-то конкретным проектом? Чем больше людей работает над проектом, тем больше вам нужен общий / централизованный сервер разработки, чтобы все получали все изменения.

• С точки зрения сопоставления , SQL Server Express LocalDB имеет один особенно раздражающий нюанс / ограничение / ограничение:

  Параметры сортировки для LocalDB установлены в SQL_Latin1_General_CP1_CI_AS и не могут быть изменены. Параметры сортировки на уровне базы данных, на уровне столбцов и на уровне выражений поддерживаются в обычном режиме. Содержащиеся базы данных следуют правилам сопоставления метаданных и базы данных tempdb, определенным в соответствии с Собранными сопоставлениями базы данных .

  Сопоставление на уровне экземпляра влияет не только tempdb(то есть разрешение имен объектов в db-области и сопоставление по умолчанию для временных таблиц, но не переменных таблиц), но и на имена локальных переменных, имена курсоров / имена параметров и имена gotoметок. Следовательно, если ваши производственные серверы имеют SQL_Latin1_General_CP1_CI_ASсопоставление на уровне экземпляра чего-то другого , то LocalDB не является хорошим выбором.

• Используете ли вы функции Enterprise Edition? Если это только вопрос перестройки индекса ONLINE, то это, вероятно, не имеет значения. Но если вы используете что-то вроде Table Partitioning, то LocalDB не является хорошим выбором.

• Возможно, самая большая проблема заключается в общем увеличении объема потенциальных проблем, возникающих из-за любых экологических различий (уровень ОС, уровень программного исправления, конфигурация экземпляра, конфигурация БД и т. Д.), Которые могут привести к ошибке. Хотя мы уже приняли (в общем смысле), что автоматическое тестирование / QA / UAT обнаружит эти проблемы, это не гарантируется ! Учитывая, что люди совершают ошибки и что людям необходимо выполнить все тесты, которые проверяли бы все пути кода и все варианты данных (типы, размер и т. Д.), Весьма вероятно, что любое количество сценариев не будетбыть проверенным и что ошибка могла бы пройти и не быть замечена, пока клиент не обнаружит ее в Производстве. В любом случае это происходит, но при использовании LocalDB шансы возрастают, поэтому у каждого разработчика может быть своя собственная БД.

На самом деле это сводится к тому, что является веской причиной для его использования в командной среде? На разных работах я всегда работал в группах, где были разработчики приложений и инженеры баз данных, и хотя разработчики приложений иногда копировали хранимую процедуру просто для того, чтобы сделать это быстрее (не достаточно для нас, DBE), DBE делали большую часть Программирование БД, включая проверку (т.е. исправление) любого кода, написанного разработчиками приложений. Использование LocalDB усложнило бы работу в группе. И хотя при использовании SQL Server Express (или даже Developer Edition) личные экземпляры на каждой рабочей станции разработчика были доступны удаленно - что облегчало совместную работу - на самом деле никогда не было необходимости иметь такой уровень изоляции, так как редко изменения БД для одного проекта негативно влияют на другой.

Конечно, у тех из нас, кто был инженером баз данных (DBE), были локальные версии Express Edition и / или Developer Edition. Но это должно было сделать тестирование, которое требовало большего контроля над конфигурацией / безопасностью на уровне экземпляра и т. Д., Чем это можно было разрешить на общем сервере. И я использовал местные экземпляры иногда, но не очень часто. Но для моих личных проектов я люблю LocalDB и использую его довольно часто.