Как вы управляете базами данных во время разработки?

Question

Моя команда разработчиков из четырех человек уже некоторое время сталкивается с этой проблемой:

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

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

Есть ли лучший способ обойти эту дилемму? Есть ли что-то вроде инструмента «SCM для данных»?

Странным образом было бы полезно сохранить текстовый файл запросов SQL на вставку / удаление / обновление в git-репозитории, но я думаю, что это может очень быстро стать очень медленным.

Как вы, ребята, справляетесь с этим?

Answer 1

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

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

Часто более эффективно предоставлять отдельным разработчикам собственную изолированную среду, в которой они могут выполнять разработку и модульное тестирование, не затрагивая других разработчиков или тестировщиков. Это не панацея, потому что теперь вы должны предоставить механизм для синхронизации этих нескольких отдельных сред с течением времени. Вы должны убедиться, что разработчики имеют разумный способ сбора изменений друг друга (как данных, схемы, так и кода). Это не обязательно проще. Хорошая практика СКМ может помочь, но для ее реализации все же требуется значительный уровень сотрудничества и координации. Не только это, но и предоставление каждому разработчику своей собственной копии всей среды может привести к затратам на хранение и дополнительным ресурсам DBA, которые помогут в управлении и надзоре за этими средами.

Вот несколько идей для рассмотрения:

1. Создание общей, общедоступной "доски среды" (она может быть электронной), где разработчики могут легко увидеть, какие среды доступны и кто их использует.
2. Идентифицирует отдельное лицо или группу для собственных ресурсов базы данных. Они отвечают за отслеживание окружения и помогают разрешать конфликтующие потребности различных групп (разработчиков, тестировщиков и т. Д.).
3. Если время и бюджеты позволяют, рассмотрите возможность создания сред песочницы для всех ваших разработчиков.
4. Если вы этого еще не сделали, рассмотрите возможность отделения «игровых зон» для разработчиков от сред интеграции, тестирования и приемочного тестирования.
5. Убедитесь, что вы управляете версиями критически важных объектов базы данных - особенно тех, которые часто изменяются, таких как триггеры, хранимые процедуры и представления. Вы не хотите терять работу, если кто-то перезаписывает чужие изменения.

Answer 2

Мы используем локальные базы данных разработчиков и одну основную базу данных для интеграционного тестирования. Мы храним сценарии создания в SCM. Один разработчик отвечает за обновление сценариев SQL на основе схемы «золотой мастер». Разработчик может вносить необходимые изменения в свою локальную базу данных, по мере необходимости заполняя данные из базы данных интеграции, используя процесс импорта, или генерируя данные с помощью инструмента (в нашем случае Red Gate Data Generator). При необходимости разработчики стирают свою локальную копию и могут по мере необходимости обновлять сценарий создания и данные интеграции. Обычно базы данных используются только для интеграционного тестирования, и мы макетируем их для модульных тестов, чтобы минимизировать объем работы, обеспечивающей синхронизацию.

Answer 3

Я рекомендую вам взглянуть на взгляды Скотта Аллена по этому вопросу. Он написал серию блогов, которые, на мой взгляд, превосходны. Три правила работы с базой данных , Базовая линия , Смена скриптов , Просмотры, сохраненные процы и т. Д. , Ветвление и слияние .

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

Answer 4

Я бы согласился со всем, что сказал Л.Бушкин в своем ответе. Если вы используете SQL Server, у нас в Red Gate есть решение, которое позволит вам легко обмениваться изменениями между несколькими средами разработки.

http://www.red -gate.com / продукция / sql_source_control / index.htm

Если существуют проблемы с хранилищем, из-за которых вашему администратору баз данных трудно разрешить использование нескольких сред разработки, у Red Gate есть решение для этого. С технологией Red Gate HyperBac вы можете создавать виртуальные базы данных для каждого разработчика. Они выглядят точно так же, как обычные базы данных, но в фоновом режиме общие данные распределяются между различными базами данных. Это позволяет разработчикам иметь собственные базы данных, не занимая непрактичный объем дискового пространства на вашем SQL Server.

Answer 5

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

• Подобно тому, что рекомендовал @tvanfosson, вы сохраняете набор сценариев SQL, которые могут создавать базу данных с нуля, или

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

Answer 6

А как насчет этого подхода:

Поддерживать отдельный репо для «чистого дБ». В репо будет файл sql с таблицей создает / вставляет и т. Д.

Используя Rails (я уверен, что он может быть адаптирован для любого git-репо), поддерживайте "clean db" как подмодуль в приложении. Напишите скрипт (возможно, задачу rake), который запрашивает локальную базу данных dev с помощью операторов SQL.

Чтобы очистить вашу локальную базу данных (и заменить ее свежими данными):

git submodule init
git submodule update

1010 * тогда *

rake dev_db:update ......... (or something like that!)

Answer 7

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

, поскольку у нас была эта информация в кодесамо по себе, и поскольку у нас были подключаемые адаптеры SQL, было тривиально заставить этот код работать с базой данных в памяти (мы использовали HSQL).Следовательно, мы выполнили большую часть нашей реальной работы по разработке и тестированию производительности на «реальных» локальных серверах (Oracle или SQL Server), но все модульное тестирование и другие автоматизированные задачи выполнялись для баз данных в памяти для конкретных процессов.

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

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

Answer 8

Если вы используете ORM, такой как nHibernate, создайте сценарий, который генерирует как схему, так и данные в локальной базе данных разработки ваших разработчиков.

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

Тестирование промежуточной базы данных перед развертыванием.

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

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

Если вы используете ORM, который генерирует схему, вам не нужно поддерживать сценарий создания.

Answer 9

У нас есть инструмент обслуживания базы данных, который мы используем для создания / обновления наших таблиц и наших процедур.у нас есть сервер с обновленной базой данных, заполненной данными.

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

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

Answer 10

В прошлом я имел дело с этим несколькими способами.

Одним из них является репозиторий SQL Script, который создает и заполняет базу данных. Это совсем не плохой вариант, и он может синхронизировать все (даже если вы не используете этот метод, вы все равно должны поддерживать эти сценарии, чтобы ваша БД находилась в Source Control).

Другой (который я предпочитаю) имел единственный экземпляр «чистой» базы данных dev на сервере, к которому никто не подключался. Когда разработчикам нужно было обновить свои базы данных dev, они запускали пакет служб SSIS, который копировал «чистую» базу данных в свою копию dev. Затем мы могли бы при необходимости изменить наши базы данных разработчиков, не наступая на ноги другим разработчикам.