Комментарии 36
Очень интересно, спасибо
Это пока единственный автоматизированный вариант решения проблемы который я нашел, до этого приходилось все делать вручную, что было достаточно накладно.
Надо попробовать поюзать, чтобы оценить все преимущества. Но то, что вручную делать лень — это, конечно, правда.
на хабре ведь уже обсуждали LiquiBase
Поиск находит только 1 топик с поверхностным упоминанием.
мир ведь не сошелся на LiquiBase, больше выбор — больше возможностей. Спасибо что упомянули LiquiBase, теперь можно почитать и про него и выбрать что лучше(раньше не слышал о LiquiBase).
Простите если ошибусь о сути поста, но это как было сказано ниже описание «Контроль версий для структуры баз данных». В нашей фирме мы пробовали Phing как средство автоматизации сборок билдов и проверки качества кода. Но на тот момент он был довольно сырой и поддерживал довольно мало плагинов.
Остановились на CruiseControl cruisecontrol.sourceforge.net/ и на него сверху интерфейс
phpundercontrol phpundercontrol.org/about.html. Преимущества в том что проект развивается довольно давно, имеет оч. много обзоров по настройке cruise (будет не лишне упаминуть что с непривычки много времени ушло на первоначальную настройку билдов). В том числе есть плагин для работы с базой. А именно после любого изменения в базе, девелопер который его сделал, создает дамп базы и кладет этот файл в свн. Круиз забирает все из СВН разворачивает каждый раз по новой базу и потом на этой базе выполняет все тесты. Таким образом мы каждый день имеем отчет все ли изменения были сделаны корректны и не внесли ли они проблемы в работы других узлов приложения.
P.S. Если Вы имели ввиду не такого рода свойства Phing, звеняйте ):
Остановились на CruiseControl cruisecontrol.sourceforge.net/ и на него сверху интерфейс
phpundercontrol phpundercontrol.org/about.html. Преимущества в том что проект развивается довольно давно, имеет оч. много обзоров по настройке cruise (будет не лишне упаминуть что с непривычки много времени ушло на первоначальную настройку билдов). В том числе есть плагин для работы с базой. А именно после любого изменения в базе, девелопер который его сделал, создает дамп базы и кладет этот файл в свн. Круиз забирает все из СВН разворачивает каждый раз по новой базу и потом на этой базе выполняет все тесты. Таким образом мы каждый день имеем отчет все ли изменения были сделаны корректны и не внесли ли они проблемы в работы других узлов приложения.
P.S. Если Вы имели ввиду не такого рода свойства Phing, звеняйте ):
Забыл дописать, этого решения нам достаточно чтоб не делать уйму файлов апдейтов базы. Так как каждый разработчик утром апдейтит СВН и разворачивает у себя базу, которая у нас готова к работе с необходимым набором данных.
А если вам необходимо вычленить необходимые апдэйты для патча на рабочую базу, то для этих целей опять же можно написать скрипт-плагин(на том же PHP) который будет сверять рабочую базу и базу из SVN, генерируя код патча автоматом.
А если вам необходимо вычленить необходимые апдэйты для патча на рабочую базу, то для этих целей опять же можно написать скрипт-плагин(на том же PHP) который будет сверять рабочую базу и базу из SVN, генерируя код патча автоматом.
У СС есть несколько типов плагинов: паблишеры, билдеры и т. п. phing — один из возможных билдеров. Насчет сырости — слышал тожесамое про phpundercontrol, к тому же он отностительно староват: «Revision 94 by mapi at Sun, 21 Sep 2008 00:16:19 +0200»
phpundercontrol действительно давно не обновлялся, но он в данной связке выступает лишь как интерфейс к CC (на любителя).
Просто он больше заточен под проекты на PHP с выносом в отдельные вкладки результатов выполнения unittests, codesnifer, codecoverage, etc. Впринципе ничего не мешает самому написать интерфейс, для нас это было излишне.
по поводу билдеров, где-то видел в английском сегменте, что народ подключал phing к CC, но меня не хватило разобраться в теме.
Преимущество phing (на мой взгляд) значительно более простая установка и настройка конфигов. Плюс большой плюс для написания своих дополнений пхп-программистам.
CruiseControl муторен в первоначальном развертывании, особенно новичку, но зато большое сообщество и уже довольно много всяких плагинов на все случаи жизни.
Просто он больше заточен под проекты на PHP с выносом в отдельные вкладки результатов выполнения unittests, codesnifer, codecoverage, etc. Впринципе ничего не мешает самому написать интерфейс, для нас это было излишне.
по поводу билдеров, где-то видел в английском сегменте, что народ подключал phing к CC, но меня не хватило разобраться в теме.
Преимущество phing (на мой взгляд) значительно более простая установка и настройка конфигов. Плюс большой плюс для написания своих дополнений пхп-программистам.
CruiseControl муторен в первоначальном развертывании, особенно новичку, но зато большое сообщество и уже довольно много всяких плагинов на все случаи жизни.
Я бы предложил переименовать статью в «Контроль версий для структуры баз данных», будет сразу понятно, что речь идет не о бэкапе данных или чем-то подобном.
А за статью спасибо, весьма пригодится — а то тяжко постоянно вручную патчи c SQL делать :(
А за статью спасибо, весьма пригодится — а то тяжко постоянно вручную патчи c SQL делать :(
у нас в JAVA проекте senior написала что то похожее сама — используем. В личных нуждах надо попробовать ваш пример.
В свое время искали как такое можно сделать отдельными утилитами, нашли EMS Database Compare.
Позволяет по двум базам построить файл-мердж.
Конечно не то, что описано в статье, но лично нам этой утилиты хватило более чем.
Позволяет по двум базам построить файл-мердж.
Конечно не то, что описано в статье, но лично нам этой утилиты хватило более чем.
habrahabr.ru/blogs/php/63585/#comment_1767601
;-)
ps: EMS и то, что описано в статье, вполне можно использовать в гармоничном тандеме :-)
;-)
ps: EMS и то, что описано в статье, вполне можно использовать в гармоничном тандеме :-)
Имхо некрасивый синтаксис в build.xml, и неудобно то что само приложение надо поместить в папку library и public, что ставит под вопрос использование миграции в фреймворке. А так немного напоминает миграцию рельс кроме генерации через консоль и своего синтаксиса определения стуктуры бд. И всё же наличие миграций лучше чем её отсутствие :)
Мы уже давно пришли к следующей структуре:
Есть файл database.sql, который создаёт базу с нуля — там всегда самая свежая структура.
Есть каталог alters, в котором лежат файлы поименованные как:
001_2008_05_15.sql
002_2008_06_18.sql
003_2008_06_19.sql
…
Преимущество такого подхода — три позиции под номер дают возможность всегда выстраивать альтреры в хронологическом порядке. Дата позволяет примерно увидеть, насколько обновлялась база. Да и вообще не люблю давать осмысленные названия подобным файлам.
В конце каждого альтера стоит
update zp_maintenance set file='121_2009-04-13.sql', modiftime=now();
Благодаря этому мы всегда знаем какой альтер был применён последним в текущей копии базы данных и можем дотащить новые альтеры, если они появятся.
Ещё один немаловажный аспект — дисциплина разработчиков. При изменении структуры базы данных разработчики должны _сначала_ писать альтер, а потом применять его на свою копию. Никаких добавлений колонок в phpmyadmin и прочих.
Есть файл database.sql, который создаёт базу с нуля — там всегда самая свежая структура.
Есть каталог alters, в котором лежат файлы поименованные как:
001_2008_05_15.sql
002_2008_06_18.sql
003_2008_06_19.sql
…
Преимущество такого подхода — три позиции под номер дают возможность всегда выстраивать альтреры в хронологическом порядке. Дата позволяет примерно увидеть, насколько обновлялась база. Да и вообще не люблю давать осмысленные названия подобным файлам.
В конце каждого альтера стоит
update zp_maintenance set file='121_2009-04-13.sql', modiftime=now();
Благодаря этому мы всегда знаем какой альтер был применён последним в текущей копии базы данных и можем дотащить новые альтеры, если они появятся.
Ещё один немаловажный аспект — дисциплина разработчиков. При изменении структуры базы данных разработчики должны _сначала_ писать альтер, а потом применять его на свою копию. Никаких добавлений колонок в phpmyadmin и прочих.
Способ описанный в статье по факту от вашего не отличается, единственное — автоматизировано накатывание обновлений и их откат.
следует заметить, что «откат» на самом деле здесь полурешение.
попробуйте откатить удаление таблицы или столбца.
попробуйте откатить удаление таблицы или столбца.
Ну в принципе автонакатывание альтеров и есть основная фишка, которая сильно раздражает при ежедневной работе. Плюс после автонаката можно делать деплой дев-версии приложения по крону хоть каждый час.
откатить изменение на самом деле не так просто — для этого придётся для каждого альтера писать антиальтер.
Но в принципе — за все годы не возникало такой необходимости ни разу.
Ещё одно важдное правило — альтер должен быть целиком заключён в транзакцию — чтоб при провале одной строки весь альтер не применялся и деплой скрипт должен это учитывать и не применять остальные альтеры при провале одного из них.
откатить изменение на самом деле не так просто — для этого придётся для каждого альтера писать антиальтер.
Но в принципе — за все годы не возникало такой необходимости ни разу.
Ещё одно важдное правило — альтер должен быть целиком заключён в транзакцию — чтоб при провале одной строки весь альтер не применялся и деплой скрипт должен это учитывать и не применять остальные альтеры при провале одного из них.
может кому-то пригодится.
это я делал когда-то для синхронизации структуры бд.
без контроля версий, конечно, но умеет добавлять/изменять таблицы и поля.
в принципе, никто не мешает прикрутить туда логи, бекапы, создание альтеров/диффов в виде отдельных файлов и прочие вкусности, но на момент написания это было не нужно.
удаление таблиц и полей отсутствует намеренно, а не от лени, написано левой задней ногой в лучших традициях пхп-лапши :).
да, я на скорую руку убрал оттуда зависимости, а протестировать сейчас негде, потому мог слегка поломать.
это я делал когда-то для синхронизации структуры бд.
без контроля версий, конечно, но умеет добавлять/изменять таблицы и поля.
в принципе, никто не мешает прикрутить туда логи, бекапы, создание альтеров/диффов в виде отдельных файлов и прочие вкусности, но на момент написания это было не нужно.
удаление таблиц и полей отсутствует намеренно, а не от лени, написано левой задней ногой в лучших традициях пхп-лапши :).
да, я на скорую руку убрал оттуда зависимости, а протестировать сейчас негде, потому мог слегка поломать.
Вопрос автору, Вы пытались провести сравнительный анализ данных php инструментов с компонентой фреймворка Rails — db:migration? cуществуют ли преимущества на решением в рельсах?
Материал статьи — по сути портирование концепта с rails, от этом есть в оригинале в первых строках, я сначала перевел и это, но потом убрал.
Ruby on Rails is a popular web application framework, that provides a method of migrating (upgrading) the applications database programatically, keeping the database schema essentially version controlled. This allows individual developers to update their working databases and the databases on testing, staging or production machines to be updated with new versions of applications. The CakePHP framework has recently developed a migrations library simliar to rails, but this article focuses on using seperate tools to run database migrations, a build tool called Phing, along with a method for creating database migrations, dbdeploy.
Если не хочется писать миграции руками и нужна конретно MySQL, то я делаю вот такой проект: code.google.com/p/mygrate/. Вы вносите изменения в БД через любой инструмент, и потом можете сделать коммит, который автоматически создает миграцию. Миграции можно просматривать («mygrate log»), откатывать («mygrate up», «revert») и т.п. В ситуациях синхронизации локальной дев-БД и продакшн-сервера работает замечательно. Если кого-то заинтересует, напишите, я постараюсь дать более подробный хелп.
Уже несколько часов изучаю тему.
Как ваш проект, забросили?
Идея очень интересная, как раз то, что надо.
Как ваш проект, забросили?
Идея очень интересная, как раз то, что надо.
о, вовсе нет, не забросил. просто у меня самого для разработки работает более-менее стабильно, и поэтому сразу меньше мотивации писать документации или какие-то новые фичи делать. поэтому если вы пользуетесь и вам нравится, я буду рад багрепортам (видел, что один уже пришел) или предложениям по тому, чего не хватает.
хм, это конечно вариант, но очень хотелось бы какую то автоматическую связку git — mysql, где в mysql необходим только версионность структуры БД. На самом деле это достаточно элементарно было бы и самому написать, но на все нужно время… а компания время потраченное на такие вещи к сожалению не оплачивает… Может быть кто-то сталкивался с подобными проектами?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Контроль версий структуры базы данных