Эта статья — How To, которое поможет вам легко обеспечить миграцию между версиями БД ваших PHP приложений с помощью Phing и dbdeploy.
Автор статьи признается в том что всегда пользуется бета и RC релизами Phing и если вы будете использовать материал статьи для совместимости поступайте так же. Самый простой способ установки phing — использование PEAR. Вы сможете сделать это на любой системе тремя командами:
В примере будет рассмотрено простое приложение со следующей структурой:
В этом разделе мы рассмотрим как разрабатывать скрипты сборщика которые будут инициализировать миграцию базы данных. Для начала нам потребуется создатьпростой конфигурационный (ini) файл, комментарии к которому будут излишне. Разместим его здесь: deploy/build.properties.
Второй файл который нам необходимо создать это deploy/build.xml. Из него Phing узнает что мы от него хотим. Автор снабдил пример некоторыми комментариями, но если у вас возникнут более детальные вопросы — обратитесь к документации Phing.
В принципе это все что требуется сделать, осталось создать саму базу данных.
Так как мы, в принципе, еще не создали нашу базу, так что вместо того чтобы сделать этого традиционным путем будем использовать миграции чтобы создать начальную структуру. Мы еще без понятия что будет делать наше приложение, но так как во многих примерах используют концепт блогов, то почему бы и нам не начать с этого же… начнем с одной таблицы «post», содержащей 3 поля:
Работа Dbdeploy основана на создании нумерованных файлов отличий, каждый файл содержит SQL чтобы применить изменения и откатить их, базовый файл имеет следующий вид:
Мы создаем нашу первоначальную структуру, поэтому положим дамп в db/deltas/1-create_initial_schema.sql
Мы в одном шаге от нашей первой миграции. Чтобы отслеживать текущую версию базы данных dbdeploy требует таблицу в БД для хранения служебной информации. Это единственный раз когда нам потребуется напрямую взаимодействовать с клиентом mysql напрямую.
Теперь мы готовы запустить нашу первую миграцию и создать первоначальную структуру для приложения
Теперь в нашей базе данных есть таблица с постами, но что насчет того чтобы добавить информацию об авторе? Нам потребуется создать еще одну таблицу и внешний ключ, чтобы это сделать создается еще один файл для dbdeploy и назовем его db/deltas/2-create_author_and_link_to_post.sql
Запустим миграцию повторно.
Вот и все, теперь мы знаем как можно легко и непринужденно обеспечивать миграцию между версиями БД. Если вы не хотите окнпастить код чтобы ознакомиться поближе, можете скачать архив приложения.
Есть множество моментов, когда речь заходит о контроле версий базы данных, особенно если вы ветвите и объединяете код вашего приложения, некоторые из них подробно описаны в документации dbdeploy.
Это руководство неполное и если вам кажется, есть что добавить, пожалуйста, оставьте свой комментарий ниже.
P. S.
Ознакомительная статья Phing Is Not GNU для получения общего представления о Phing.
Установка Phing
Автор статьи признается в том что всегда пользуется бета и RC релизами Phing и если вы будете использовать материал статьи для совместимости поступайте так же. Самый простой способ установки phing — использование PEAR. Вы сможете сделать это на любой системе тремя командами:
> pear channel-discover pear.phing.info > pear config-set preferred_state beta > pear install phing/phing
Пример структуры приложения
В примере будет рассмотрено простое приложение со следующей структурой:
example/ |-- db/ ← здесь хранятся sql файлы для управления БД | `-- deltas/ |-- deploy/ ← здесь хранятся скрипты обеспечивающие миграцию | `-- scripts/ |-- library/ ← здесь находится разрабатываемое приложение `-- public/ ← сюда указывает директива DOCUMENT ROOT
Скрипты сборщика
В этом разделе мы рассмотрим как разрабатывать скрипты сборщика которые будут инициализировать миграцию базы данных. Для начала нам потребуется создатьпростой конфигурационный (ini) файл, комментарии к которому будут излишне. Разместим его здесь: deploy/build.properties.
# Property files contain key/value pairs #key=value # This dir must contain the local application build.dir=../ # Credentials for the database migrations db.host=localhost db.user=user db.pass=password db.name=example # paths to programs progs.mysql=/usr/bin/mysql
Второй файл который нам необходимо создать это deploy/build.xml. Из него Phing узнает что мы от него хотим. Автор снабдил пример некоторыми комментариями, но если у вас возникнут более детальные вопросы — обратитесь к документации Phing.
<?xml version="1.0" ?>
<project name="PurpleMonkey" basedir="." default="build">
<!-- Sets the DSTAMP, TSTAMP and TODAY properties -->
<tstamp/>
<!-- Load our configuration -->
<property file="./build.properties" />
<!-- create our migration task -->
<target name="migrate" description="Database Migrations">
<!-- load the dbdeploy task -->
<taskdef
name="dbdeploy"
classname="phing.tasks.ext.dbdeploy.DbDeployTask"/>
<!--
these two filenames will contain the generated SQL
to do the deploy and roll it back
-->
<property
name="build.dbdeploy.deployfile"
value="deploy/scripts/deploy-${DSTAMP}${TSTAMP}.sql" />
<property
name="build.dbdeploy.undofile"
value="deploy/scripts/undo-${DSTAMP}${TSTAMP}.sql" />
<!-- generate the deployment scripts -->
<dbdeploy
url="mysql:host=${db.host};dbname=${db.name}"
userid="${db.user}"
password="${db.pass}"
dir="${build.dir}/db/deltas"
outputfile="${build.dir}/${build.dbdeploy.deployfile}"
undooutputfile="${build.dir}/${build.dbdeploy.undofile}" />
<!--
Execute the SQL
Use mysql command line to avoid trouble with large files
or many statements and PDO
-->
<exec
command="${progs.mysql} -h${db.host} -u${db.user} -p${db.pass} ${db.name} < ${build.dbdeploy.deployfile}"
dir="${build.dir}"
checkreturn="true" />
</target>
</project>
* This source code was highlighted with Source Code Highlighter.
В принципе это все что требуется сделать, осталось создать саму базу данных.
Работа с dbdeploy
Так как мы, в принципе, еще не создали нашу базу, так что вместо того чтобы сделать этого традиционным путем будем использовать миграции чтобы создать начальную структуру. Мы еще без понятия что будет делать наше приложение, но так как во многих примерах используют концепт блогов, то почему бы и нам не начать с этого же… начнем с одной таблицы «post», содержащей 3 поля:
Field | Type | Comment |
---|---|---|
title | VARCHAR(255) | The title of our post |
time_created | DATETIME | The time we created our post |
content | MEDIUMTEXT | The content of our post |
Работа Dbdeploy основана на создании нумерованных файлов отличий, каждый файл содержит SQL чтобы применить изменения и откатить их, базовый файл имеет следующий вид:
--//
-- Run SQL to do the changes
--//@UNDO
-- RUN SQL to undo the changes
--//
* This source code was highlighted with Source Code Highlighter.
Мы создаем нашу первоначальную структуру, поэтому положим дамп в db/deltas/1-create_initial_schema.sql
--//
CREATE TABLE `post` (
`title` VARCHAR(255),
`time_created` DATETIME,
`content` MEDIUMTEXT
);
--//@UNDO
DROP TABLE `post`;
--//
* This source code was highlighted with Source Code Highlighter.
Миграции
Мы в одном шаге от нашей первой миграции. Чтобы отслеживать текущую версию базы данных dbdeploy требует таблицу в БД для хранения служебной информации. Это единственный раз когда нам потребуется напрямую взаимодействовать с клиентом mysql напрямую.
> mysql -hlocalhost -uroot -ppassword example > CREATE TABLE changelog ( change_number BIGINT NOT NULL, delta_set VARCHAR(10) NOT NULL, start_dt TIMESTAMP NOT NULL, complete_dt TIMESTAMP NULL, applied_by VARCHAR(100) NOT NULL, description VARCHAR(500) NOT NULL ); > ALTER TABLE changelog ADD CONSTRAINT Pkchangelog PRIMARY KEY (change_number, delta_set);
Теперь мы готовы запустить нашу первую миграцию и создать первоначальную структуру для приложения
>cd deploy >phing migrate
Теперь в нашей базе данных есть таблица с постами, но что насчет того чтобы добавить информацию об авторе? Нам потребуется создать еще одну таблицу и внешний ключ, чтобы это сделать создается еще один файл для dbdeploy и назовем его db/deltas/2-create_author_and_link_to_post.sql
--//
CREATE TABLE `author` (
`author_id` INT(10) unsigned auto_increment,
`name` VARCHAR(255),
PRIMARY KEY (`author_id`)
);
ALTER TABLE `post` ADD `author_id` INT(10) unsigned NULL;
--//@UNDO
ALTER TABLE `post` DROP `author_id`;
DROP TABLE `author`;
--//
* This source code was highlighted with Source Code Highlighter.
Запустим миграцию повторно.
shell> cd deploy shell> phing migrate
Заключение
Вот и все, теперь мы знаем как можно легко и непринужденно обеспечивать миграцию между версиями БД. Если вы не хотите окнпастить код чтобы ознакомиться поближе, можете скачать архив приложения.
Есть множество моментов, когда речь заходит о контроле версий базы данных, особенно если вы ветвите и объединяете код вашего приложения, некоторые из них подробно описаны в документации dbdeploy.
Это руководство неполное и если вам кажется, есть что добавить, пожалуйста, оставьте свой комментарий ниже.
P. S.
Ознакомительная статья Phing Is Not GNU для получения общего представления о Phing.