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

17

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

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

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

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

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

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

    
задан user94154 28.06.2010 в 17:14
источник
  • Единственный способ, с помощью которого я когда-либо видел это, - это иметь 50+ программистов, делающих любые изменения, которые им нравятся в базе данных, а затем стонать в администраторе базы данных (по-настоящему), когда все перестает работать. Я не могу сказать, что рекомендую этот подход. –  Brian Hooper 28.06.2010 в 17:52
  • Идеальный смысл :) Это работает в основном отлично для команды из четырех человек. Поскольку наша команда растет (что очень вероятно), я хотел бы иметь более элегантное решение. –  user94154 28.06.2010 в 17:59

10 ответов

8

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

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

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

Вот некоторые идеи для вас:

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

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

    
ответ дан tvanfosson 28.06.2010 в 17:22
2

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

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

    
ответ дан bjorsig 29.06.2010 в 01:38
0

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

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

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

    
ответ дан Justin Niessner 28.06.2010 в 17:17
0

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

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

Если / когда мы добавляем столбцы / таблицы / procs, мы обновляем инструмент dbMaintenance, который хранится в исходном элементе управления.

иногда, его боль, но она работает достаточно хорошо.

    
ответ дан Muad'Dib 28.06.2010 в 17:19
0

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

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

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

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

Требуется меньше нескольких секунд, чтобы удалить все таблицы, создать их снова и ввести тестовые данные.

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

    
ответ дан user333306 28.06.2010 в 17:22
0

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

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

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

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

    
ответ дан Andrzej Doyle 28.06.2010 в 17:26
0

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

Поддерживайте отдельное репо для «чистого db». Репо будет представлять собой файл sql с таблицами create / inserts и т. Д.

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

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

git submodule init
git submodule update

затем

rake dev_db:update ......... (or something like that!)
    
ответ дан user94154 28.06.2010 в 18:11
0

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

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

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

ответ дан Dean J 28.06.2010 в 18:16
0

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

Ссылка

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

    
ответ дан David Atkinson 03.07.2010 в 13:14