База данных SQL Server изменяет лучшие практики рабочего процесса
Фон
У моей группы есть 4 Базы данных SQL Server:
- Производство
- UAT
- Тест
- Dev
Я работаю в среде Dev. Когда время настает для продвижения объектов, я продолжал работать (таблицы, представления, функции, сохранили procs), я выполняю запрос своего менеджера, который продвигает Тест. После тестирования она отправляет запрос Администратору, который продвигает UAT. После успешного пользователя, тестирующего, тот же Администратор способствует Производству.
Проблема
Весь процесс является неловким по нескольким причинам.
- Каждый человек должен вручную отследить их изменения. Если я обновляю, добавьте, удалите любые объекты, я должен отследить их так, чтобы мой запрос продвижения содержал все, что я сделал. В теории, если я пропускаю что-то, тестирование или UAT должны поймать его, но это не бесспорно, и это - пустая трата времени тестера, так или иначе.
- Много изменений, которые я вношу, является повторяющимся и сделано в GUI, что означает, что нет никакой записи того, какие изменения я внес, только конечный результат (по крайней мере, насколько я знаю).
- Мы находимся на довольно ранних стадиях пристраивания витрины данных, таким образом, большинство внесенных изменений, по крайней мере, мудрых количеством, является незначительными вещами: изменение типа данных для столбца, изменение названий таблиц, поскольку мы кристаллизуем то, для чего они будут использоваться, настраивая функции и храниться procs и т.д.
Вопрос
Люди делали этот вид работы в течение многих десятилетий, таким образом, я предполагаю, что должен быть намного лучший способ справиться с процессом. То, что я любил бы, - то, если я мог бы выполнить разность между двумя базами данных, чтобы видеть, как структура отличалась, используйте ту разность для генерации сценария изменения, используйте тот сценарий изменения в качестве моего запроса продвижения. Действительно ли это возможно? В противном случае есть ли какие-либо другие способы организовать этот процесс?
Для записи мы - 100%-й магазин Microsoft, сейчас обновляя все к SQL Server 2008, таким образом, любые инструменты, доступные в том пакете, были бы справедливой игрой.
Я должен разъяснить, что не обязательно ищу различные инструменты. Если это - лучший способ синхронизировать наши среды затем, хорошо, но если существует лучший способ, которым я ищу это.
Примером, делающим, что я хочу действительно хорошо, являются миграции в Ruby on Rails. Очень простой синтаксис, все изменения хорошо документируются автоматически и по умолчанию, определяя то, что должны выполнить миграции, почти тривиально легко. Я любил бы, если было что-то подобное этому для SQL Server.
Мое идеальное решение легко 2) 1) легкий и 2) трудно испортить. Миграции направляющих - оба; все, что я сделал до сих пор на SQL Server, не является ни одним.
7 ответов
Контроль версий и ваша база данных
Корень всего зла - это внесение изменений в пользовательский интерфейс. SSMS - это инструмент DBA, а не инструмент разработчика. Разработчики должны использовать сценарии для внесения любых изменений в модель / схему базы данных. Версионирование ваших метаданных и наличие сценария обновления от каждой версии N до версии N + 1 - это единственный способ, который доказал свою надежность. Это решение, которое SQL Server развертывает для отслеживания изменений метаданных (изменения базы данных ресурсов).
Инструменты сравнения, такие как SQL Compare или файлы vsdbcmd и .dbschema из проектов VS Database, являются лишь последним прибежищем для тех магазинов, которые не в состоянии реализовать надлежащий подход с управлением версиями. Они работают в простых сценариях, но я вижу, что все они сильно терпят неудачу при серьезных развертываниях. Нельзя доверять инструменту, чтобы сделать изменение таблицы + 5 ТБ, если инструмент пытается скопировать данные ...
Вам доступно несколько инструментов. Один от Red-Gate называется SQL Compare . Замечательно и очень рекомендуется. SQL Compare позволит вам выполнять различие в схемах между двумя базами данных и даже создавать для вас сценарии изменения sql.
Обратите внимание, что они уже некоторое время работают над продуктом управления версиями SQL Server.
Другой (если вы являетесь магазином визуальной студии) - это функции сравнения схем и данных, которые являются частью Visual Studio (не знаю, какие версии).
RedGate продает SQL Compare, отличный инструмент для создания сценариев изменений.
Visual Studio также имеет редакции, поддерживающие сравнение баз данных. Раньше это называлось Database Edition.
Там, где я работаю, мы давно упразднили разделение Dev/Test/UAT/Prod в пользу очень быстрого цикла выпуска. Если мы выпускаем что-то сломанное в производство, мы быстро это исправляем. Наши клиенты, безусловно, довольны, но в корпоративных компаниях, избегающих риска, это может быть трудновыполнимой задачей.
Согласитесь, что SQL Compare - удивительный инструмент.
Однако мы не внужли никаких изменений в структуру базы данных или объекты, которые не были написаны и сохранены в системе управления версиями, как и весь другой код. Тогда вы точно знаете, что относится к версии, которую вы продвигаете, потому что у вас есть сценарии для этой конкретной версии.
В любом случае, это плохая идея вносить структурные изменения через графический интерфейс. Если у вас много данных, это намного медленнее, чем использование таблицы alter, по крайней мере, в SQL Server. Вы хотите использовать только протестированные скрипты для внесения изменений в prod.
В нашей команде мы обрабатываем изменения базы данных следующим образом:
- Мы (повторно) генерируем сценарий , который создает полную базу данных и проверяет ее в системе контроля версий вместе с другие изменения. У нас есть 4 файла: таблицы, пользовательские функции и представления, хранимые процедуры и разрешения. Это полностью автоматизировано - для создания сценария требуется только двойной щелчок.
- Если разработчик должен внести изменения в базу данных, он делает это на своей локальной базе данных .
- Для каждого изменения мы создаем скриптов обновления . Их легко создать: разработчик регенерирует сценарий базы данных своей локальной базы данных. Все изменения теперь легко идентифицировать благодаря контролю версий. Большинство изменений (новые таблицы, новые представления и т. Д.) Можно просто скопировать в сценарий обновления, другие изменения (например, добавление столбцов) необходимо создавать вручную.
- Сценарий обновления тестируется либо на нашей общей базе данных разработчиков, либо путем отката локальной базы данных до последней резервной копии, которая была создана перед началом изменения базы данных. Если это пройдет, пора зафиксировать изменения.
- Сценарии обновления следуют соглашению об именах , поэтому каждый знает, в каком порядке их выполнять.
Это работает довольно хорошо для нас, но все же требует некоторой координации, если несколько разработчиков сильно изменяют одни и те же таблицы и представления. Однако это случается не часто.
Важные моменты:
- структура базы данных изменяется только скриптами , за исключением базы данных локального разработчика. Это важно.
- Версии сценариев SQL контролируются системой управления версиями - база данных может быть создана, как это было в любой момент в прошлом
- резервные копии базы данных создаются регулярно - по крайней мере, перед созданием изменения в db
- изменения в db можно сделать быстро, потому что сценарии для этих изменений создаются относительно легко.
Однако, если у вас много долгосрочных ветвей разработки для ваших проектов, это может не сработать.
Это далеко не идеальное решение, и необходимо принять некоторые особые меры предосторожности. Например, если есть обновления, которые могут завершиться ошибкой в зависимости от данных, имеющихся в базе данных, обновление следует протестировать на копии производственной базы данных.
В отличие от миграции rails, мы не создаем сценарии для отмены изменений обновления. Но в любом случае это не всегда возможно, по крайней мере, в отношении данных (содержимое отброшенного столбца теряется, даже если вы воссоздаете столбец).
Я согласен с замечаниями marapet, где каждое изменение должно быть заскриптовано.
Однако проблема, с которой вы можете столкнуться, заключается в создании, тестировании и отслеживании этих скриптов.
Посмотрите на механизм исправления, используемый в DBSourceTools.
http://dbsourcetools.codeplex.com
Он был специально разработан, чтобы помочь разработчикам получить базы данных SQL server под контролем исходного кода.
Этот инструмент позволит вам установить базовую линию вашей базы данных в определенный момент и создать именованную версию (v1).
Затем создайте цель развертывания - и увеличьте именованную версию до v2.
.
Добавьте скрипты исправлений в каталог Patches для любых изменений схемы или данных.
Наконец, проверьте базу данных и все исправления в системе контроля исходного кода, чтобы распространить их среди разработчиков.
Все это дает вам повторяющийся процесс тестирования всех патчей, которые будут применяться от версии 1 к версии 2.
DBSourceTools также имеет функциональность, которая поможет вам создать эти сценарии, т.е. сравнение схем или инструменты данных сценариев.
Как только вы закончите, просто отправьте все файлы в каталоге патчей вашему DBA для обновления с v1 до v2.
Получайте удовольствие.