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

Question

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

Вот наши настройки. У каждого разработчика есть виртуальная машина с нашим приложением и база данных MySQL. Это их личная песочница, чтобы делать все, что они хотят. В настоящее время разработчики вносят изменения в схему SQL и делают дамп базы данных в текстовый файл, который они фиксируют в SVN.

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

У нас есть тестовый (виртуальный) сервер, который запускает «кандидатов на выпуск». Развертывание на тестовом сервере в настоящее время является очень ручным процессом и обычно включает в себя загрузку последней версии SQL из SVN и ее настройку. Кроме того, данные на тестовом сервере противоречивы. В результате вы получите все тестовые данные, которые последний разработчик зафиксировал на своем сервере-песочнице.

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

Если бы проблема была только в схеме, это была бы более простая проблема, но в базе данных есть «базовые» данные, которые также обновляются во время разработки, например метаданные в таблицах безопасности и разрешений. *

Это самый большой барьер, который я вижу при переходе к непрерывной интеграции и пошаговой сборке. Как вы решаете это?

---

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

---

Спасибо за ссылку на Тарантино. Я не нахожусь в среде .NET, но нашел их DataBaseChangeMangement wiki page очень полезными. Особенно это PowerPoint Presentation (.ppt)

Я собираюсь написать сценарий Python, который проверяет имена *.sql сценариев в заданном каталоге по таблице в базе данных и запускает те, которых там нет, по порядку на основе целого числа, которое формирует первое часть имени файла. Если это довольно простое решение, как я подозреваю, оно будет опубликовано здесь.

---

У меня есть рабочий скрипт для этого. Он обрабатывает инициализацию БД, если она не существует, и запускает сценарии обновления по мере необходимости. Есть также переключатели для очистки существующей базы данных и импорта тестовых данных из файла. В нем около 200 строк, поэтому я не буду его публиковать (хотя, если есть интерес, я могу поместить его в pastebin).

Answer 1

Есть несколько хороших вариантов. Я бы не стал использовать стратегию восстановления резервной копии.

1. Сценарий всех изменений схемы, и ваш сервер CI запускает эти сценарии в базе данных. Иметь таблицу версий для отслеживания текущей версии базы данных и выполнять сценарии только в том случае, если они предназначены для более новой версии.

2. Используйте решение для миграции. Эти решения различаются в зависимости от языка, но для .NET я использую Migrator.NET. Это позволяет вам создавать версии вашей базы данных и перемещаться вверх и вниз между версиями. Ваша схема указана в коде C #.

Answer 2

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

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

Answer 3

Посмотрите, как Ruby on Rails делает это.

Сначала существуют так называемые файлы миграции, которые в основном преобразуют схему базы данных и данные из версии N в версию N + 1 (или в случае перехода с версии N + 1 на N). База данных имеет таблицу, которая сообщает текущую версию.

Тестовые базы данных всегда очищаются перед юнит-тестами и заполняются фиксированными данными из файлов.

Answer 4

Книга Рефакторинг баз данных: эволюционный дизайн баз данных может дать вам несколько советов о том, как управлять базой данных. Короткая версия также доступна для чтения http://martinfowler.com/articles/evodb.html

В одном проекте PHP + MySQL у меня был номер ревизии базы данных, сохраненный в базе данных, и когда программа подключается к базе данных, она сначала проверит ревизию. Если программа требует другой ревизии, она откроет страницу для обновления базы данных. Каждое обновление указывается в коде PHP, который изменит схему базы данных и перенесет все существующие данные.

Answer 5

• Назовите ваши базы данных следующим образом - db_dev, db_test, db_qa, db_prod (Очевидно, вы никогда не должны жестко кодировать имена БД
• Таким образом, вы сможете развернуть даже разные типы БД на одном физическом сервере (я не рекомендую этого, но вам, возможно, придется ... если ресурсы ограничены)
• Убедитесь, что вы сможете перемещать данные между ними автоматически
• Отделение сценариев создания БД от совокупности = всегда должна быть возможность воссоздать БД с нуля и заполнить ее (из старой версии БД или из внешнего источника данных
• не использовать строки кода с жестким кодом в коде (даже не в файлах конфигурации) - использовать в шаблонах строк подключения файлов конфигурации, которые вы заполняете динамически, каждая реконфигурация application_layer, которая требует перекомпиляции, имеет BAD
• используйте версионность базы данных и версионность объектов БД - если вы можете себе это позволить, используйте готовые продукты, если не разрабатываете что-то самостоятельно
• отслеживает каждое изменение DDL и сохраняет его в некоторой таблице истории ( пример здесь )
• ЕЖЕДНЕВНЫЕ резервные копии! Проверьте, насколько быстро вы сможете восстановить что-то потерянное из резервной копии (используйте сценарии автоматического восстановления
• даже ваша база данных DEV и PROD имеют точно такой же сценарий создания, что у вас будут проблемы с данными, поэтому позвольте разработчикам создать точную копию prod и поиграть с ней (я знаю, что получу минусы за этот, но изменение мышления и бизнес-процесс обойдутся вам гораздо дешевле, когда дерьмо попадет в фанат, поэтому заставьте кодеров легально подписывать все, что он делает, но убедитесь, что это

Answer 6

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

Answer 7

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

• dbChanges_1.sql
• dbChanges_2.sql
• ...
• dbChanges_n.sql

Это работало достаточно хорошо, пока мы не начали поддерживать две линии разработки: магистраль / магистраль для новой разработки и ветку обслуживания для исправления ошибок, краткосрочных улучшений и т. Д. Неизбежно, возникла необходимость вносить изменения в схему в ветка. На данный момент у нас уже есть dbChanges_n + 1.sql в магистрали, поэтому мы в итоге пошли по схеме, подобной следующей:

• dbChanges_n.1.sql
• dbChanges_n.2.sql
• ...
• dbChanges_n.3.sql

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

В наши дни мы просто поддерживаем один дельта-скрипт и позволяем SVN его версии - т.е. мы перезаписываем скрипт с каждым выпуском. И мы уклоняемся от внесения изменений в схемы в ветвях.

Итак, меня это тоже не устраивает. Мне очень нравится концепция миграции с Rails. Я очень увлекся LiquiBase . Он поддерживает концепцию инкрементного рефакторинга базы данных. Это стоит посмотреть, и я скоро рассмотрим это подробно. У кого-нибудь есть опыт работы с этим? Мне было бы очень любопытно услышать о ваших результатах.

Answer 8

У нас очень похожая настройка на ОП.

Разработчики разрабатывают в виртуальных машинах с частными БД.

[Разработчики скоро перейдут в частные ветки]

Тестирование выполняется на разных машинах (фактически в виртуальных машинах, размещенных на сервере) [Скоро будет запущен сервером Hudson CI]

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

Затем запустите модульные и системные тесты.

Производство развертывается для клиентов в качестве установщиков.

Что мы делаем:

Мы берем дамп схемы нашей БД песочницы. Затем дамп данных SQL. Различаем это до предыдущего базового уровня. эта пара дельт должна обновить n-1 до n.

настраиваем дампы и дельты.

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

(Юха упомянул, что идея Rail о наличии таблицы, записывающей текущую версию БД, хороша и должна сделать установку обновлений менее сложной.)

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

Answer 9

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

Во многих случаях простой ALTER TABLE не сработает, вам также нужно изменить существующие данные - разработчикам нужно подумать о том, какие миграции требуются, и убедиться, что они написаны правильно (конечно, вы должны тщательно проверить какой-то момент в цикле выпуска).

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

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

Answer 10

Проверьте dbdeploy , инструменты Java и .net уже доступны, вы можете следовать их стандартам для макетов файлов SQL и таблицы версий схемы и написать свою версию Python.