Очень похоже на вопрос, который был опубликован здесь ранее: « Могут ли разработчики запрашивать производственные базы данных? » Я хотел бы поделиться вашими соображениями по другой особенно раздражающей теме!
Многие компании запрещают разработчикам устанавливать SQL Server Express и тому подобное на компьютерах разработчиков, вместо этого поощряя использование централизованных серверов разработки SQL.
В частности, это сделано для обеспечения:
- Соответствие уровня исправлений между серверами разработки и производством
- Возможность доказать и проверить любые патчи на выше
- Безопасность данных; только данные на серверах разработки используются для разработки
- восстанавливаемость; данные восстанавливаемы и до сих пор сохраняются
- Различия в сортировке, которые могут вызвать проблемы при переносе в производство
Для меня все эти аргументы являются особенно недействительными, возможно, за исключением исправлений; но если база данных на локальном компьютере используется исключительно для деятельности по разработке, а не для тестирования, то исправление будет проверено, когда приложение перейдет через Test / UAT и т. д. в Production.
Похоже, что сопоставление не является действительной причиной, так как если это касается базы данных, ее следует установить при ее создании в любом случае. Насколько мне известно, только SharePoint и SCCM имеют проблемы с этим;)
Теперь, предполагая, что это ТОЛЬКО для разработки, и база данных не будет «перемещена» в производство, и единственными движениями будут:
- Скрипты, которые создали базу данных, создаваемую для развертывания в производство
- Резервные копии из «производственных» сторонних систем восстанавливаются и усекаются в случае необходимости для проверки и разработки.
Кто-нибудь может увидеть какие-либо проблемы? Я что-то пропустил?
Я полагаю, что одной из самых больших проблем будет возможность устаревания локальных экземпляров БД, но это проблема управления программным обеспечением, а не DBA и IMO.
источник
Ответы:
Да. Все разработчики должны иметь локальный экземпляр SQL Server И общий экземпляр SQL-сервера. Они существуют для разных целей. Оба необходимы.
Возможно, ваша текущая среда выглядит так?
Выше несколько разработчиков создают изменения и размещают их в общей базе данных SQL Developer. Это плохо. Microsoft MVP Troy Hunt документирует некоторые болевые точки этого устаревшего подхода, здесь . Основные из них ...
Этот шаблон вызывает конфликт разработчика. Одним из симптомов конфликта является разрастание базы данных. Многие базы данных создаются, поскольку разработчики ищут безопасное, изолированное пространство для выполнения своей работы. Есть несколько причин, по которым организация цепляется за эту модель. Во-первых, они не инвестировали в надлежащую систему контроля источников . Другое - то, что они просто унаследовали этот шаблон проектирования и не могут его изменить. 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).
Мы все еще можем хранить общую базу данных, но она не должна быть для разработки, она должна быть для тестирования. Это сервер, на котором настройки системного уровня синхронизированы с производством. Аппаратное обеспечение, ОС, патчи и т.д ..
источник
Хорошо. Но они не для всех нас. Почему?
Исправления могут исправить проблемы со стабильностью и повреждением данных, которые могли бы мешать разработчикам. Это должно быть сделано на машинах разработки независимо.
Полезно отделить «что должно быть» от «что есть». Разработчики получают конфиденциальные (не обязательно PII, но и не бесплатные) данные в своих базах данных. Бывает.
Супер важно.
Все, что использует временную таблицу, будет иметь эту проблему. Это очень распространено. Вы никогда не замечаете этого, потому что большинство людей в первую очередь используют стандартное сопоставление.
Зачем нам это считать? Вещи часто идут от разработки до производства. Как еще вы попали в производство впервые? Чистые сценарии? Не обязательно, когда приложение находилось в стадии подготовки в течение некоторого времени.
Вам просто нужно сделать заявление о том, что вы делаете и не поддерживаете и почему.
LocalDB является основной частью SSDT сейчас и неизбежна. Однако он недоступен для удаленного доступа и не имеет компонента планирования (у Express есть похожие проблемы). Следовательно, он обычно не поддерживается администраторами баз данных в отношении резервного копирования, обслуживания и проверки целостности.
Но консолидация на централизованных серверах разработки все же имеет смысл. А теперь, когда Developer Edition бесплатен, еще проще оправдать наличие большего количества из них.
источник
Концептуально говоря, вы на правильном пути. Для организации, у которой есть зрелый процесс разработки / жизненный цикл разработки программного обеспечения (SDLC), который включает в себя контроль исходного кода, непрерывную интеграцию (CI), автоматическое тестирование и ИТ-группу, которая знает, как управлять различными средами и рабочими станциями, чтобы поддерживать их синхронизацию что касается программного обеспечения и уровней исправлений, а также дисциплинированных разработчиков, которые а) следуют процессу, б) работают вместе и в) работают с ИТ, то могут иметь 50 (или столько же) БД для разработки:
НО, как и во всем остальном, это действительно сводится к контексту ситуации.
Одно из преимуществ наличия отдельных БД для разработки состоит в том, что над различными проектами можно работать одновременно, не влияя друг на друга. (Конечно, это может быть единственным преимуществом.)
ОДНАКО, есть различные вопросы для рассмотрения:
Каков размер команды и сколько человек работает над каким-то конкретным проектом? Чем больше людей работает над проектом, тем больше вам нужен общий / централизованный сервер разработки, чтобы все получали все изменения.
С точки зрения сопоставления , SQL Server Express LocalDB имеет один особенно раздражающий нюанс / ограничение / ограничение:
Сопоставление на уровне экземпляра влияет не только
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 и использую его довольно часто.
источник