Общая или личная база данных при разработке?

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

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

Общая база данных.

Обычно разработчик, изменивший схему БД, кричит на весь офис: “обновитесь, я изменил базу!”

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

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

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

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

Всем разработчикам нет необходимости думать о том, как обновлять базу данных. С одной стороны это достоинство, но с другой очень часто и недостаток - в команде нет общего видения, какие шаги необходимо предпринять для обновления боевой базы и очень часто боевая и база разработчиков находятся в разном состоянии.

В моей практике очень часто случались ситуации “ой забыл”:

  • "поигрался" с базой данных и не откатил свои изменения;
  • забыл закоммитить скрипт обновелния в репозиторий;
  • закоммитил не тот, который выполнял на самом деле;
  • из-за гонок скрипт просто не выполняется на живой базе.

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

Применимость

Данный подход хорошо подходит для использования вместе с централизованными хранилищами исходного кода, такими как SVN или TFS, если все разработчики работают в одной ветке.

Если все находятся в одном офисе в приделах видимости и слышимости остальных членов команды. Либо разработчики разрабатывают разные модули системы, которые общаются с разными частями базы и никогда не пересекаются (что очень маловероятно). Либо если разработчик на проекте один.

Также такое решение применяется, если база данных очень требовательна к ресурсам или сложна в администрировании (например Oracle), либо взимается дополнительная плата за каждый копию (MS SQL Server*).

*конечно существует Oracle XE, но в силу своих ограничений его поведение и возможности значительно отличаются от старшего брата.

**для MS SQL Server в версии Express Edition в основном отличия только на размер базы и количество процессорных ядер, а ядро системы такое же как и у старшего брата.

Индивидуальная база данных для каждого разработчика.

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

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

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

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

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

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

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

Применимость

Данный подход идеален для варианта, работы с использованием децентрализованных систем контроля версия (Git, Mercurial, Bazaar). Либо для централизованных систем контроля версий, при активном использовании веток. Также идеально подходит для распределенных команд.

Заключение

В моем случае подход эволюционировал так:

  1. Общая база данных (MS SQL), Jedi VCS, модульная разработка, индивидуальные миграционные скрипты, написанные вручную (MySuperModule.sql), каждый разработчик свой модуль заливает на боевой сервер сам.

  2. Общая база данных (Oracle), SVN, генерация модели данных по схеме БД (LLBLGen Pro), общий миграционный скрипт на версию (v1.0.1.sql, v1.0.2.sql).

  3. Общая база данных (Оracle), mercurial, генерация схемы БД по модели (NHibernate), общий миграционный скрипт на версию.

  4. Индивидуальная база данных (MS SQL Server), mercurial, генерация схемы БД по модели (NHibernate), общий миграционный скрипт на версию.

  5. Индивидуальная база данных (MS SQL Server), mercurial/git, генерация схемы БД и вставка начальных значений через механизм миграций (FluentMigrator). Обновление через запуск файла migrate.bat, что в принципе может вызываться автоматически через post update hook.

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

comments powered by Disqus