Phing: backup и сохранение в Subversion базы данных

Владимир | | MySQL, Phing, Subversion.

phing mysql subversion

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

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

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

Возвращаемся к нашей задаче.

Для создания резервной копии базы можно использовать утилиту mysqldump. В её параметрах нужно указать имя пользователя базы, его пароль и название базы. Дополнительно нужно задать имя файла в который мы сохраняем дамп.

Например, так

mysqldump -uпользователь -pпароль название_базы > dump.sql

Для сохранения файла в Subversion используется команда commit.

svn.exe commit -m “db_backup” --username имя --password пароль имя_файла

Здесь мы указываем текст сообщения (после параметра -m), имя пользователя Subversion, его пароль и имя файла, который нужно сохранить.

Примечание. Подробнее об этой системе контроля версий можно почитать в разделе Subversion.

Теперь рассмотрим build-файл.

<?xml version="1.0" encoding="UTF-8"?>
<project name="DbBackup" default="commit" basedir=".">

	<property name="DUMP_FILE" value="dump.sql" />
	<property name="MYSQL_PATH" value="путь_к_mysql" />
	<property name="DB_NAME" value="имя_базы_данных" />
	<property name="DB_HOST" value="localhost" />
	<property name="DB_USER" value="имя_пользователя_mysql" />
	<property name="DB_PASS" value="пароль_mysql" />
	
	<property name="SVN_USER" value="имя_пользователя_subversion" />
	<property name="SVN_PASS" value="пароль_subversion" />
	
	<target name="backup">
		<exec command="${MYSQL_PATH}mysqldump -u${DB_USER} -p${DB_PASS} ${DB_NAME} > ${DUMP_FILE}" dir="." />
	</target>
	
	<target name="commit" depends="backup">
		<exec command="svn.exe commit -m "db_backup" --username ${SVN_USER} --password ${SVN_PASS} ${DUMP_FILE}" dir="." />
	</target>
</project>

Как видите, большую часть файла занимают свойства (имена, пароли, адрес сервера, размещение mysqldump).

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

Для выполнение наших команд мы использовали стандартную задачу exec. Как несложно догадаться она просто выполняет указанную команду.

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

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

Конечно, создание самого build-файла отнимает немного времени, но вы быстро его вернете и, кроме того, будете делать меньше ошибок (особенно если нужно выполнять длинные последовательности операций).

И в заключение, небольшой совет. По-умолчанию Phing не выводит результат выполнения команды. Т.е. вы не знаете выполнилась на самом деле команда или нет.

Например, если в данном примере написать sbn.exe вместо svn.exe и запустить этот build-файл, то в результате вы увидите обычное сообщение BUILD FINISHED. Естественно, новая версия файла в репозитории сохранена не будет.

Поэтому на этапе тестирования очень полезно запускать phing с параметром -verbose.

phing -verbose

В этом случае вы увидите множество интересных сообщений и в том числе

“sbn.exe” не является внутренней или внешней командой …

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

Время – деньги. Цените его! 🙂

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

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

  • Согласен с Олегом что на кроне будет и проще и удобней реализовать.

  • Согласен с Олегом что на кроне будет и проще и удобней реализовать.

  • Олег, а при чем тут крон к системе деплоймента?

    • Я не понимаю зачем при деплое делать дамп и класть его в SVN. Вот с обратной операцией я еще могу согласиться: извлечь из SVN дамп (читай «весь проект») и миграционный скрипт накатить на базу.

      Вот с таким примером я спорить не стал бы. Просто из моего опыта я не помню ни одного случая, когда можно автоматически дампить девелоперскую базу и класть её в SVN. Вот, собственно, суть моей притензии.

      • зачем при деплое делать дамп и класть его в SVN

        Здесь не идет речь о деплое. Это просто пример использования.
        Я иногда использую SVN для синхронизации между компьютером и ноутбуком.

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

        • Здесь не идет речь о деплое.

          Я ответил на комментарий aleks_raiden.

          Я иногда использую SVN для синхронизации между компьютером и ноутбуком.

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

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

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

        • Контроль версий — само собой. Просто если нужно работать на 2-х компьютерах, можно параллельно использовать SVN для синхронизации.

        • Просто если нужно работать на 2-х компьютерах, можно параллельно использовать SVN для синхронизации.

          Синхронизации чего?

        • Базы данных и остальных файлов.

        • Класть БД (я имею в виду вместе с данными) в SVN не кажется мне хорошей идеей. Если уж нет возможности синхронизировать две базы напрямую, то можно придумать более прямые решения.

        • Как правило эта БД очень маленькая (настройки + тестовые данные). Но очень часто между коммитами изменяется её структура (количество, тип полей в таблицах и т.п.), поэтому обновлять её нужно целиком.

          Хотя признаюсь честно, вопросом синхронизации я практически не занимался. А SVN использую из-за удобной возможности откатов. Если есть идеи и предложения, с удовольствием выслушаю.

        • Но очень часто между коммитами изменяется её структура (количество, тип полей в таблицах и т.п.), поэтому обновлять её нужно целиком.

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

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

          Кроме того, мне нужна синхронизация в обе стороны, а не только на продакшн сервер. Т.е. что-то типа AllwaySync, но только для БД.

        • Phing вполне может выполнять теже операции, что и миграционные скрипты.

          э… я могу согласиться с тем, что Phing может выполнить миграционные скрипты, но вот заменить их — это как?

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

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

          Doctrine, например, поддерживает миграции и реализованы они именно через скрипты модификации.

          Я сейчас не смог придумать ни одной причины для хранения всей БД (вместе с данными) в SVN. А уж как продакшн обновлять с помощью полного дампа — это я вообще не могу представить.

        • Никаких обновлений всех данных на продакшн сервере. Я не удачно объяснил. Мне не нужна двусторонняя синхронизация с продакшн сервером. Синхронизировать нужно базы на двух (или более) девелоперских машинах. А в этих базах — настройки CMS, немного тестовых данных и т.п. В общем дамп редко бывает больше пары сотен КБ.

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

  • Олег, а при чем тут крон к системе деплоймента?

    • Я не понимаю зачем при деплое делать дамп и класть его в SVN. Вот с обратной операцией я еще могу согласиться: извлечь из SVN дамп (читай «весь проект») и миграционный скрипт накатить на базу.

      Вот с таким примером я спорить не стал бы. Просто из моего опыта я не помню ни одного случая, когда можно автоматически дампить девелоперскую базу и класть её в SVN. Вот, собственно, суть моей притензии.

      • зачем при деплое делать дамп и класть его в SVN

        Здесь не идет речь о деплое. Это просто пример использования.
        Я иногда использую SVN для синхронизации между компьютером и ноутбуком.

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

        • Здесь не идет речь о деплое.

          Я ответил на комментарий aleks_raiden.

          Я иногда использую SVN для синхронизации между компьютером и ноутбуком.

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

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

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

        • Контроль версий — само собой. Просто если нужно работать на 2-х компьютерах, можно параллельно использовать SVN для синхронизации.

        • Просто если нужно работать на 2-х компьютерах, можно параллельно использовать SVN для синхронизации.

          Синхронизации чего?

        • Базы данных и остальных файлов.

        • Класть БД (я имею в виду вместе с данными) в SVN не кажется мне хорошей идеей. Если уж нет возможности синхронизировать две базы напрямую, то можно придумать более прямые решения.

        • Как правило эта БД очень маленькая (настройки + тестовые данные). Но очень часто между коммитами изменяется её структура (количество, тип полей в таблицах и т.п.), поэтому обновлять её нужно целиком.

          Хотя признаюсь честно, вопросом синхронизации я практически не занимался. А SVN использую из-за удобной возможности откатов. Если есть идеи и предложения, с удовольствием выслушаю.

        • Но очень часто между коммитами изменяется её структура (количество, тип полей в таблицах и т.п.), поэтому обновлять её нужно целиком.

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

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

          Кроме того, мне нужна синхронизация в обе стороны, а не только на продакшн сервер. Т.е. что-то типа AllwaySync, но только для БД.

        • Phing вполне может выполнять теже операции, что и миграционные скрипты.

          э… я могу согласиться с тем, что Phing может выполнить миграционные скрипты, но вот заменить их — это как?

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

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

          Doctrine, например, поддерживает миграции и реализованы они именно через скрипты модификации.

          Я сейчас не смог придумать ни одной причины для хранения всей БД (вместе с данными) в SVN. А уж как продакшн обновлять с помощью полного дампа — это я вообще не могу представить.

        • Никаких обновлений всех данных на продакшн сервере. Я не удачно объяснил. Мне не нужна двусторонняя синхронизация с продакшн сервером. Синхронизировать нужно базы на двух (или более) девелоперских машинах. А в этих базах — настройки CMS, немного тестовых данных и т.п. В общем дамп редко бывает больше пары сотен КБ.

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

  • Присоединяюсь к aleks_raiden. Cron это ведь планировщик, он должен что-то запускать, например, скрипт какой-нибудь.

    Конечно, обе команды из этого примера можно напрямую вызвать с помощью Cron. Но ведь Phing позволяет выполнить цепочку команд. Даже в этом примере нужно создать 2 задания Cron чтобы выполнить обе команды, а если их будет 10?

    • По поводу крона ответил выше.

      Даже в этом примере нужно создать 2 задания Cron чтобы выполнить обе команды, а если их будет 10?

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

      • Честно говоря, плохо представляю как это будет выглядеть. Можно пример?

        • Я не гуру командной строки, поэтому вижу всего два варианта:

          1) непосредственно прописать команды в задачу крона (это только пример, показывающий принцип, для реальной задачи надо прописать все параметры)

          mysqldump > dump.sql && svn ci dump.sql

          2) написать шел-скрипт, в котором можно все настройки вынести в переменные (да и вообще много чего можно сделать), а уже его запускать кроном. Именно этот вариант я использую для создания бэкапов базы своего блога.

        • В том-то и дело, что такими длинными командами пользоваться не очень удобно.

          шел-скрипт

          А чем в данном случае шел-скрипт будет отличаться от build-файла phing? Его ведь тоже можно запускать Cron'ом.

  • Присоединяюсь к aleks_raiden. Cron это ведь планировщик, он должен что-то запускать, например, скрипт какой-нибудь.

    Конечно, обе команды из этого примера можно напрямую вызвать с помощью Cron. Но ведь Phing позволяет выполнить цепочку команд. Даже в этом примере нужно создать 2 задания Cron чтобы выполнить обе команды, а если их будет 10?

    • По поводу крона ответил выше.

      Даже в этом примере нужно создать 2 задания Cron чтобы выполнить обе команды, а если их будет 10?

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

      • Честно говоря, плохо представляю как это будет выглядеть. Можно пример?

        • Я не гуру командной строки, поэтому вижу всего два варианта:

          1) непосредственно прописать команды в задачу крона (это только пример, показывающий принцип, для реальной задачи надо прописать все параметры)

          mysqldump > dump.sql && svn ci dump.sql

          2) написать шел-скрипт, в котором можно все настройки вынести в переменные (да и вообще много чего можно сделать), а уже его запускать кроном. Именно этот вариант я использую для создания бэкапов базы своего блога.

        • В том-то и дело, что такими длинными командами пользоваться не очень удобно.

          шел-скрипт

          А чем в данном случае шел-скрипт будет отличаться от build-файла phing? Его ведь тоже можно запускать Cron'ом.

  • А чем в данном случае шел-скрипт будет отличаться от build-файла phing? Его ведь тоже можно запускать Cron'ом.

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

    В этом состоит моя точка зрения. Я не спорю с тем, что выполнение никсовых команд в проекте Phing в некоторых (именно в некоторых) случаях оправдано. Но конкретные примеры в этом посте в моей голове не укладываются — они не логичны и скорее даже вредны.

    • Я соглашусь, что примеры можно было подобрать более интересные и полезные.

      Но вот на счет микроскопа поспорю. Назначение Phing (и других подобных систем) — упростить жизнь разработчику. В принципе он не содержит никаких уникальных возможностей. Тоже самое можно сделать с помощью shell-скрипта. Основное преимущество phing — удобство определения длинных цепочек действий. И на мой взгляд phing больше похож на молотк, чем shell-скрипты 🙂

      А cron'у по-моему без разницы что запускать. Кстати, я не пойму какой смысл использовать cron для коммитов? Что если разработчик хочет сделать коммит позже или раньше?

      • И на мой взгляд phing больше похож на молотк, чем shell-скрипты

        Ты просто не умеешь их готовить 😉

        Кстати, я не пойму какой смысл использовать cron для коммитов?

        Ну хорошо, с кроном я погорячился. А вот в данном случае использовать вместо Phing shell-скрипт — самое оно. Гораздо проще, быстрее и надежнее.

        Я считаю, что Phing предназначен все же для узкой задачи — автоматизации процедуры деплоя. Вот там его место. А другие задачи удобнее решать более другими инструментами.

        • Ты просто не умеешь их готовить

          Вынужден согласиться 🙂

          Phing предназначен все же для узкой задачи

          Тут я сошлюсь на разработчиков apache ant (Phing — по-сути портированный ant под PHP).
          Они ставили целью расширить возможности shell-based инструментов вроде make и gnumake.

          А на мой взгляд узкие и широкие задачи — это очень относительные понятия. Задачи всегда конкретные. И если у меня есть build-файл для phing, который можно за 10-20 мин подправить и он будет решать нужную мне задачу, то с какой стати я буду писать shell-скрипт?
          У вас, как я так понял, ситуация обратная 🙂

  • А чем в данном случае шел-скрипт будет отличаться от build-файла phing? Его ведь тоже можно запускать Cron'ом.

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

    В этом состоит моя точка зрения. Я не спорю с тем, что выполнение никсовых команд в проекте Phing в некоторых (именно в некоторых) случаях оправдано. Но конкретные примеры в этом посте в моей голове не укладываются — они не логичны и скорее даже вредны.

    • Я соглашусь, что примеры можно было подобрать более интересные и полезные.

      Но вот на счет микроскопа поспорю. Назначение Phing (и других подобных систем) — упростить жизнь разработчику. В принципе он не содержит никаких уникальных возможностей. Тоже самое можно сделать с помощью shell-скрипта. Основное преимущество phing — удобство определения длинных цепочек действий. И на мой взгляд phing больше похож на молотк, чем shell-скрипты 🙂

      А cron'у по-моему без разницы что запускать. Кстати, я не пойму какой смысл использовать cron для коммитов? Что если разработчик хочет сделать коммит позже или раньше?

      • И на мой взгляд phing больше похож на молотк, чем shell-скрипты

        Ты просто не умеешь их готовить 😉

        Кстати, я не пойму какой смысл использовать cron для коммитов?

        Ну хорошо, с кроном я погорячился. А вот в данном случае использовать вместо Phing shell-скрипт — самое оно. Гораздо проще, быстрее и надежнее.

        Я считаю, что Phing предназначен все же для узкой задачи — автоматизации процедуры деплоя. Вот там его место. А другие задачи удобнее решать более другими инструментами.

        • Ты просто не умеешь их готовить

          Вынужден согласиться 🙂

          Phing предназначен все же для узкой задачи

          Тут я сошлюсь на разработчиков apache ant (Phing — по-сути портированный ant под PHP).
          Они ставили целью расширить возможности shell-based инструментов вроде make и gnumake.

          А на мой взгляд узкие и широкие задачи — это очень относительные понятия. Задачи всегда конкретные. И если у меня есть build-файл для phing, который можно за 10-20 мин подправить и он будет решать нужную мне задачу, то с какой стати я буду писать shell-скрипт?
          У вас, как я так понял, ситуация обратная 🙂

  • мне нравится !!!не очень удобно тоже будет,но ничего!

  • мне нравится !!!не очень удобно тоже будет,но ничего!

  • Горячии финские парни ))) «надо … не надо»
    Помоему скрипт очень даже интересный. Пусть не надо, зато интересно.

  • Горячии финские парни ))) «надо … не надо»
    Помоему скрипт очень даже интересный. Пусть не надо, зато интересно.

  • Финские парни рулят)))

  • Финские парни рулят)))

  • довольно просто в phing!!

  • довольно просто в phing!!

  • Пусть не надо, зато интересно.

    Странная логика…

  • Пусть не надо, зато интересно.

    Странная логика…

  • Согласна с вирой . Странная логика. Мне непонятно.

  • Согласна с вирой . Странная логика. Мне непонятно.

  • А что тут непонятного?

  • А что тут непонятного?

  • У меня есть вопрос по Phing. Долго читал комментарии, он так и не понял одной вещи. Мне сейчас надо вести организовать разработку достаточно сложного проекта на Drupal (если знакомы с этой CMS, то наверняка знаете про, то что почти каждый новый блок, модуль и вообще все хранится в БД). Сайт уже работает… Но осталось много всяческих доработок. Поэтому и вопрос: как синхронизировать БД для всех разработчиков с актуальной БД на продакшн. И чтобы при обновлении базы не возникло конфликтов. Спасибо.

  • Боюсь, что за счет только phing вы этого сделать не сможете.
    Т.е. phing содержит задачи вроде DbDeployTask, но гарантировать отсутствие конфликтов они не могут.

    Может стоит попробовать написать тесты, которые будут выполняться автоматически перед деплоем?