Механизмы отслеживания изменений схемы БД
Каковы лучшие методы отслеживания и / или автоматизации изменений схемы БД? Наша команда использует Subversion для контроля версий, и мы смогли автоматизировать некоторые из наших задач таким образом (отправка сборок на промежуточный сервер, развертывание проверенного кода на производственном сервере), но мы все еще выполняем обновления базы данных вручную. Я хотел бы найти или создать решение, которое позволит нам эффективно работать на серверах с разными средами, продолжая использовать Subversion в качестве бэкэнда, через который обновления кода и БД передаются на разные серверы.
Многие популярные программные пакеты включают скрипты автоматического обновления, которые определяют версию БД и вносят необходимые изменения. Это лучший способ сделать это даже в большем масштабе (в нескольких проектах, а иногда и в нескольких средах и языках)? Если да, то есть ли какой-нибудь код, упрощающий процесс, или лучше просто развернуть собственное решение? Кто-нибудь реализовал что-то подобное раньше и интегрировал это в обработчики Subversion после фиксации, или это плохая идея?
Хотя решение, поддерживающее несколько платформ, было бы предпочтительнее, нам определенно необходимо поддерживать стек Linux / Apache / MySQL / PHP, поскольку большая часть нашей работы выполняется на этой платформе.
Ответы 20
Это довольно низкотехнологично, и может быть лучшее решение, но вы можете просто сохранить свою схему в сценарии SQL, который можно запустить для создания базы данных. Я думаю, вы можете выполнить команду для создания этого сценария, но, к сожалению, я не знаю эту команду.
Затем зафиксируйте сценарий в системе управления версиями вместе с кодом, который с ним работает. Когда вам нужно изменить схему вместе с кодом, сценарий можно зарегистрировать вместе с кодом, для которого требуется измененная схема. Затем различия в скрипте будут указывать на различия при изменении схемы.
С помощью этого сценария вы можете интегрировать его с DBUnit или каким-либо другим сценарием сборки, поэтому кажется, что он может вписаться в ваши уже автоматизированные процессы.
В мире Rails существует концепция миграций, сценариев, в которых изменения в базе данных выполняются на Ruby, а не на специфической для базы данных разновидности SQL. Ваш код миграции Ruby в конечном итоге преобразуется в DDL, специфичный для вашей текущей базы данных; это упрощает переключение платформ баз данных.
Для каждого изменения, которое вы вносите в базу данных, вы пишете новую миграцию. Миграции обычно имеют два метода: метод «вверх», в котором применяются изменения, и метод «вниз», при котором изменения отменяются. Одна команда обновляет базу данных, а также может использоваться для приведения базы данных к определенной версии схемы. В Rails миграции хранятся в собственном каталоге в каталоге проекта и проверяются в системе контроля версий, как и любой другой код проекта.
Это руководство Oracle по миграции на Rails довольно хорошо покрывает миграции.
Разработчики, использующие другие языки, рассмотрели миграции и реализовали свои собственные версии для конкретных языков. Я знаю Ruckusing, систему миграции PHP, которая смоделирована после миграции Rails; это может быть то, что вы ищете.
Ruckusing FTW - мы адаптировали его к нашей системе db и вполне им довольны.
Теперь он находится на github: github.com/ruckus/ruckusing-migrations
Если вы используете C#, обратите внимание на Subsonic, очень полезный инструмент ORM, который также генерирует sql-скрипт для воссоздания вашей схемы и \ или данных. Затем эти сценарии можно поместить в систему управления версиями.
Похоже, что на данный момент URL-адрес мертв.
Я создаю папки, названные в честь версий сборки, и помещаю туда скрипты обновления и понижения. Например, у вас могут быть следующие папки: 1.0.0, 1.0.1 и 1.0.2. Каждый из них содержит сценарий, позволяющий обновлять или понижать версию базы данных между версиями.
Если клиент или заказчик позвонит вам по поводу проблемы с версией 1.0.1, а вы используете 1.0.2, возврат базы данных к его версии не будет проблемой.
В своей базе данных создайте таблицу под названием «схема», в которую вы поместите текущую версию базы данных. Тогда легко написать программу, которая может обновить или понизить вашу базу данных.
Как и сказал Джоуи, если вы находитесь в мире Rails, используйте Migrations. :)
Моя команда записывает все изменения базы данных и фиксирует эти сценарии в SVN вместе с каждым выпуском приложения. Это позволяет вносить инкрементальные изменения в базу данных без потери данных.
Чтобы перейти от одного выпуска к другому, вам просто нужно запустить набор сценариев изменений, и ваша база данных будет актуальной, и у вас все еще есть все ваши данные. Возможно, это не самый простой метод, но он определенно эффективен.
как вы записываете все изменения?
Выгрузите свою схему в файл и добавьте ее в систему управления версиями. Тогда простой diff покажет вам, что изменилось.
Дамп должен быть в SQL, как и mysqldump, дампы Oracle бинарные.
Существует также более фундаментальная проблема с различием схем. Как отличить опускание + добавление столбца от переименования столбца. Ответ прост: нельзя. Это причина, по которой вам необходимо записывать фактические операции изменения схемы.
Разница покажет, что один столбец исчез, а другой появился (если у них нет того же имени), и в большинстве случаев этого достаточно. Конечно, неплохо написать сценарий для каждого изменения схемы: в Drupal это, например, обрабатывается с помощью специального крючка.
Мы используем очень простое, но эффективное решение.
Для новых установок у нас есть файл metadata.sql в репозитории, который содержит всю схему БД, а затем в процессе сборки мы используем этот файл для создания базы данных.
Для обновлений мы добавляем обновления в жестко запрограммированное программное обеспечение. Мы сохраняем его жестко запрограммированным, потому что нам не нравится решать проблемы до того, как они действительно станут проблемой, и до сих пор подобные вещи не были проблемой.
Итак, в нашем программном обеспечении есть что-то вроде этого:
RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');
Этот код проверяет, находится ли база данных в версии 1 (которая хранится в таблице, созданной автоматически), если она устарела, команда выполняется.
Чтобы обновить файл metadata.sql в репозитории, мы запускаем это обновление локально, а затем извлекаем полные метаданные базы данных.
Единственное, что происходит время от времени, - это забыть о фиксации metadata.sql, но это не серьезная проблема, потому что его легко протестировать в процессе сборки, а также единственное, что может произойти, - это выполнить новую установку с помощью устаревшая база данных и обновила ее при первом использовании.
Мы также не поддерживаем более ранние версии, но это сделано намеренно: если что-то ломается при обновлении, мы восстанавливаем предыдущую версию и исправляем обновление перед повторной попыткой.
Я использовал следующую структуру проекта базы данных в Visual Studio для нескольких проектов, и она работала очень хорошо:
База данных
Change Scripts
0.PreDeploy.sql
1.SchemaChanges.sql
2.DataChanges.sql
3.Permissions.sql
Create Scripts
Sprocs
Functions
Views
Наша система сборки затем обновляет базу данных от одной версии к другой, выполняя сценарии в следующем порядке:
1.PreDeploy.sql
2.SchemaChanges.sql
Contents of Create Scripts folder
2.DataChanges.sql
3.Permissions.sql
Каждый разработчик проверяет свои изменения на наличие определенной ошибки / функции, добавляя свой код в конец каждого файла. Когда основная версия завершена и разветвлена в системе управления версиями, содержимое файлов .sql в папке Change Scripts удаляется.
Мы используем что-то похожее на bcwoord, чтобы синхронизировать схемы нашей базы данных в 5 различных установках (производственная, промежуточная и несколько установок для разработки), а также выполнять резервное копирование в системе контроля версий, и это работает очень хорошо. Я немного уточню:
Для синхронизации структуры базы данных у нас есть один скрипт update.php и несколько файлов с номерами 1.sql, 2.sql, 3.sql и т. д. В скрипте используется одна дополнительная таблица для хранения номера текущей версии файла. база данных. Файлы N.sql создаются вручную для перехода от версии (N-1) к версии N базы данных.
Их можно использовать для добавления таблиц, столбцов, переноса данных из старого в новый формат столбца, затем отбрасывания столбца, вставки «основных» строк данных, таких как типы пользователей и т. д. По сути, он может делать все, что угодно, и с правильными данными сценарии миграции вы никогда не потеряете данные.
Скрипт обновления работает так:
- Connect to the database.
- Make a backup of the current database (because stuff will go wrong) [mysqldump].
- Create bookkeeping table (called _meta) if it doesn't exist.
- Read current VERSION from _meta table. Assume 0 if not found.
- For all .sql files numbered higher than VERSION, execute them in order
- If one of the files produced an error: roll back to the backup
- Otherwise, update the version in the bookkeeping table to the highest .sql file executed.
Все идет в систему контроля версий, и в каждой установке есть сценарий для обновления до последней версии с помощью одного выполнения сценария (вызов update.php с правильным паролем базы данных и т. д.). Мы, SVN, обновляем промежуточные и производственные среды с помощью сценария, который автоматически вызывает сценарий обновления базы данных, поэтому обновление кода сопровождается необходимыми обновлениями базы данных.
Мы также можем использовать тот же сценарий для воссоздания всей базы данных с нуля; мы просто отбрасываем и воссоздаем базу данных, а затем запускаем сценарий, который полностью заполнит базу данных. Мы также можем использовать сценарий для заполнения пустой базы данных для автоматического тестирования.
На настройку этой системы ушло всего несколько часов, она концептуально проста, и каждый получает схему нумерации версий, и она была бесценной, поскольку имела возможность двигаться вперед и развивать дизайн базы данных без необходимости общаться или вручную выполнять модификации. по всем базам данных.
Однако будьте осторожны при вставке запросов из phpMyAdmin! Эти сгенерированные запросы обычно включают имя базы данных, которое вам определенно не нужно, поскольку оно нарушит ваши скрипты! Что-то вроде CREATE TABLE mydb.newtable (...) завершится ошибкой, если база данных в системе не называется mydb. Мы создали хук SVN перед комментарием, который запрещает файлы .sql, содержащие строку mydb, что является верным признаком того, что кто-то скопировал / вставил из phpMyAdmin без надлежащей проверки.
Как вы справлялись с столкновениями? Несколько разработчиков меняют один и тот же элемент в БД, например хранимую процедуру? Это может произойти, если вы работаете в одной и той же ветке или у вас есть две линии разработки (две ветки).
Столкновения были очень редкими; единственное, что действительно произошло, это то, что два человека попытались создать один и тот же файл N.sql. Конечно, первый выигрывает, а второй вынужден переименовать его на следующий по величине номер и попробовать еще раз. Однако у нас не было управления версиями базы данных в ветке.
В моем текущем проекте PHP мы используем идею миграции rails, и у нас есть каталог миграции, в котором мы храним заголовок файлов «migration_XX.sql», где XX - номер миграции. В настоящее время эти файлы создаются вручную по мере внесения обновлений, но их создание можно легко изменить.
Затем у нас есть сценарий под названием «Migration_watcher», который, поскольку мы находимся в предварительной альфа-версии, в настоящее время запускается при каждой загрузке страницы и проверяет, есть ли новый файл migration_XX.sql, где XX больше, чем текущая версия миграции. Если это так, он запускает все файлы migration_XX.sql до максимального числа в базе данных и вуаля! изменения схемы автоматизированы.
Если вам требуется возможность вернуть систему в исходное состояние, потребуется большая настройка, но она проста и до сих пор работает очень хорошо для нашей довольно небольшой команды.
Скотт Амблер написал большую серию статей (и был соавтором книга) по рефакторингу базы данных, с идеей о том, что вы должны по существу применять принципы и методы TDD для поддержания вашей схемы. Вы настраиваете серию модульных тестов структуры и исходных данных для базы данных. Затем, прежде чем что-либо менять, вы изменяете / пишете тесты, чтобы отразить это изменение.
Мы занимаемся этим уже некоторое время, и, похоже, это работает. Мы написали код для генерации базовых проверок имен столбцов и типов данных в наборе модульного тестирования. Мы можем повторно запустить эти тесты в любое время, чтобы убедиться, что база данных в проверке SVN соответствует реальной базе данных, на которой действительно работает приложение.
Как оказалось, разработчики также иногда настраивают свою базу данных песочницы и пренебрегают обновлением файла схемы в SVN. Затем код зависит от изменения базы данных, которое не было зарегистрировано. Этот тип ошибки может быть безумно трудным, но набор тестов сразу же обнаружит ее. Это особенно удобно, если вы встроили его в более крупный план непрерывной интеграции.
У К. Скотта Аллена есть приличная статья или две по управлению версиями схемы, в которых используется концепция сценариев / миграций инкрементного обновления, упоминаемая в других ответах здесь; см. http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx.
Я бы порекомендовал использовать Ant (кросс-платформенный) для "сценариев" (поскольку он может практически взаимодействовать с любой базой данных через jdbc) и Subversion для исходного репозитория. Ant позволит вам "скопировать" вашу базу данных в локальные файлы перед внесением изменений. 1. резервное копирование существующей схемы базы данных в файл через Ant 2. Контроль версий в репозиторий Subversion через Ant 3. отправить новые операторы sql в базу данных через Ant
Проблема здесь действительно в том, чтобы разработчикам было легко записать собственные локальные изменения в систему управления версиями, чтобы поделиться ими с командой. Я сталкивался с этой проблемой много лет и был вдохновлен функциональностью Visual Studio для профессионалов в области баз данных. Если вам нужен инструмент с открытым исходным кодом с такими же функциями, попробуйте это: http://dbsourcetools.codeplex.com/ Радоваться, веселиться, - Натан.
Существует инструмент командной строки mysql-diff, который сравнивает схемы базы данных, где схемой может быть действующая база данных или сценарий SQL на диске. Он подходит для большинства задач миграции схемы.
Если вы все еще ищете решения: мы предлагаем инструмент под названием neXtep designer. Это среда разработки баз данных, с помощью которой вы можете поставить всю свою базу данных под контроль версий. Вы работаете в репозитории с контролируемой версией, где можно отслеживать каждое изменение.
Когда вам нужно выпустить обновление, вы можете зафиксировать свои компоненты, и продукт автоматически сгенерирует сценарий обновления SQL из предыдущей версии. Конечно, вы можете сгенерировать этот SQL из любых двух версий.
Тогда у вас есть много вариантов: вы можете взять эти сценарии и поместить их в свой SVN вместе с кодом вашего приложения, чтобы он был развернут с помощью вашего существующего механизма. Другой вариант - использовать механизм доставки neXtep: сценарии экспортируются в так называемый «пакет доставки» (сценарии SQL + дескриптор XML), и установщик может понять этот пакет и развернуть его на целевом сервере, обеспечивая при этом структурную согласованность и зависимость. проверка, регистрация установленной версии и т. д.
Продукт распространяется под лицензией GPL и основан на Eclipse, поэтому он работает в Linux, Mac и Windows. В настоящее время он также поддерживает Oracle, Mysql и Postgresql (поддержка DB2 уже в пути). Взгляните на вики, где вы найдете более подробную информацию: http://www.nextep-softwares.com/wiki
Выглядит интересно. Есть ли у него интерфейс командной строки или он планируется?
В Toad для MySQL есть функция, называемая сравнением схемы, которая позволяет синхронизировать 2 базы данных. Это лучший инструмент, который я когда-либо использовал.
ИМХО миграции имеют огромную проблему:
Обновление с одной версии до другой работает нормально, но выполнение новой установки данной версии может занять вечность, если у вас есть сотни таблиц и длинная история изменений (как у нас).
Выполнение всей истории дельт от базовой до текущей версии (для сотен клиентских баз данных) может занять очень много времени.
Мне нравится, как Yii обрабатывает миграции базы данных. Миграция - это в основном сценарий PHP, реализующий CDbMigration. CDbMigration определяет метод up, содержащий логику миграции. Также возможно реализовать метод down для поддержки отмены миграции. В качестве альтернативы можно использовать safeUp или safeDown, чтобы убедиться, что миграция выполняется в контексте транзакции.
Инструмент командной строки Yii yiic поддерживает создание и выполнение миграций. Миграции могут применяться или отменяться по одному или в пакетном режиме. Создание миграции приводит к созданию кода для класса PHP, реализующего CDbMigration, с уникальным именем на основе метки времени и имени миграции, указанного пользователем. Все миграции, которые ранее были применены к базе данных, хранятся в таблице миграции.
Для получения дополнительной информации см. Статью Перенос базы данных в руководстве.
Попробуйте db-deploy - в основном инструмент Java, но работает и с php.
Да, это почти то, что у нас есть прямо сейчас. К сожалению, это не дает нам простого способа изменить существующие базы данных - сценарий SQL, созданный mysqldump, предполагает, что вы создаете таблицу с нуля (или перезаписываете таблицу, если она существует). Нам нужно что-то более высокотехнологичное, потому что оно должно применять к базе данных последовательность операторов ALTER TABLE, а для того, чтобы делать это должным образом, ему необходимо знать текущее состояние базы данных.