Контроль версий структуры базы данных

Эта статья — How To, которое поможет вам легко обеспечить миграцию между версиями БД ваших PHP приложений с помощью Phing и dbdeploy.

Установка 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.