В этой заметке я хочу показать несложный пример использования 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” не является внутренней или внешней командой …

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

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

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

В общем-то, особых секретов нет. Скачать дистрибутив WordPress можно как в виде zip архива, так и с помощью Subversion.

Преимущества второго метода очевидны. Вы сможете с помощью всего одной команды переустановить движок. Причем установить можно как новую версию, так и предыдущую.

Обычным способом вам бы пришлось качать архив, удалять файлы старой версии (не всегда), распаковывать архив, проверять, что находится в wp-content (там могут быть более ранние версии плагинов).

Т.е. используя Subversion вы однозначно сэкономите время, и кроме того, будете уверены, что никакие ваши файлы не будут случайно перезаписаны.

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

Теперь рассмотрим процесс получения дистрибутива.

1) Создаем папку, в которую будем устанавливать WordPress. Открываем консоль и переходим в эту папку.

Примечание. Я буду рассказывать на примере консоли. Но, естественно, вы можете воспользоваться SVN клиентом.

2) Определяем, какая версия WordPress вам нужна.

Здесь все просто. Заходим на страницу http://trac.wordpress.org/browser/ и изучаем структуру репозитория.

Основная ветка разработки называется trunk. Это самая последняя версия плюс новые исправления. Кстати, когда я последний раз смотрел, ее возраст был 17 часов.

Ветки, которые распространяются (или распространялись) в виде архивов, находятся в папке tags.

Теперь определяем адрес выбранной ветки. Первая часть адреса для всех веток одинакова – http://svn.automattic.com/wordpress/. К ней добавляем путь в репозитории.

Т.е. основная ветка имеет адрес http://svn.automattic.com/wordpress/trunk
Версия 2.6 доступна по адресу http://svn.automattic.com/wordpress/tags/2.6 и т.д.

3) Загружаем выбранную версию

Для этого выполняем команду
svn checkout адрес_версии .

Например,
svn checkout http://svn.automattic.com/wordpress/trunk .

Обратите внимание. После слова trunk стоит пробел и точка. Это означает, что загружать содержимое trunk нужно в текущую папку.

4) Настраиваем WordPress. Тут все, как и при обычной установке из архива. Нужно переименовать файл wp-config-sample.php в wp-config.php и указать в нем параметры подключения к базе данных. И после этого зайти на страницу sitename.com/wp-admin/install.php

На этом этапе нужно учесть два нюанса.
Первый. В дистрибутивы WordPress файл wp-config.php не входит, поэтому он останется неизменным при обновлении. Но wp-config-sample.php меняется от версии к версии, поэтому для нормальной работы движка, возможно, потребуется вручную обновить wp-config.php.

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

4) Обновление дистрибутива. Выполняется командой svn update .... Например:
svn update http://svn.automattic.com/wordpress/trunk .

5) Переключение между версиями. Команда svn switch .... Например, для перехода на версию 2.3 выполняем команду:
svn switch http://svn.automattic.com/wordpress/tags/2.3 .

Как видите, большинство действий выполняются всего одной коммандой.

Теперь пару замечаний об обновлении движка на сервере хостера.

Все приведенные в этой статье советы и рекомендации можно использовать для обновления WordPress на «боевом» сервере.

Естественно у вас должна быть возможность запускать svn. Т.е. нужен SSH-доступ, а на многих shared хостингах его нет.

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

В общем, если нужно администрировать один блог, то выигрыш от использования Subversion незначительный. Но если вам приходится обновлять десятки дистрибутивов WordPress, размещенных на VPS или выделенном сервере, то вариант с Subversion выглядит интереснее загрузки кучи файлов по FTP или распаковки архива на сервере.

Удачного апгрейда!

В этот раз речь пойдет об использовании нескольких веток разработки.

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

Допустим, вы закончили разработку первой версии web приложения (или просто сайта). Теперь нужно перенести его на сервер хостера. В большинстве случаев при этом придется изменить параметры подключения к базе данных, отключить вывод подробного описания ошибок, profiling и т.п. Скорее всего, эти изменения затронут несколько файлов.

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

Как раз в этом случае нам и пригодится возможность Subversion создавать параллельные ветки разработки.

Идея простая. Создаем ветку для серверной версии проекта. Вносим в нее необходимые изменения и «заливаем» файлы на сервер. После этого переключаемся на основную ветку (файлы с настройками возвращаются в исходное состояние) и продолжаем разработку.

Одно из основных достоинств веток Subversion в том, что можно «сливать» любые изменения из одной ветки в другую. Таким образом, мы можем внести в ветку для сервера изменения из основной ветки так, что параметры подключения к БД останутся неизменными.

После переноса изменений нам останется только скопировать обновленные файлы на сервер.

Теперь рассмотрим конкретный пример.

Допустим, в репозитории проекта мы создали две папки:
trunk – для основной ветки разработки;
branches – для дополнительных веток.

Примечание. О том, как это сделать можно прочитать в статье «Эффективное управление проектами (Subversion)».

На данный момент проект в рабочем состоянии и находится в папке trunk.

Как мы и говорили, создаем новую ветку, в папке branches. В прошлой статье я немного рассказывал о ветках и переключении между ними, поэтому сейчас напомню только основные моменты.

Команда

svn copy file:///path_to_project/trunk
file:///path_to_project/brunches/web
-m “Ветка для размещения проекта на сервере”

создаст новую ветку разработки, которая будет размещена в папке brunches/web репозитория.

Примечание. При создании новой ветки настоящего копирования файлов не происходит. Это предотвращает черезмерное увеличение репозитория. Тем не менее, с точки зрения пользователя работа с веткой ничем не отличается от работы с настоящей копией.

Переключаемся на созданную ветку

svn switch file:///path_to_project/brunches/web

Эта команда создаст рабочую копию ветки.
Вносим в нее любые изменения (например, меняем параметры подключения к базе данных) и выполняем команду commit (т.е. сохраняем изменения в репозитории).

Очень важно писать осмысленные комментарии при сохранении данных, т.к. по ним придется ориентироваться в различиях между ветками. Фразы вроде «Все пофиксил» или «Куча мелких исправлений» не говорят ни о чем.

Теперь переключаемся на trunk

svn switch file:///path_to_project/trunk

И продолжаем работу.

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

Т.е. нам нужно «слить» часть изменений из одной ветки в другую.

Прежде всего, нужно четко знать номера ревизий, которые содержат нужные изменения. Тут как раз и пригодятся созданные комментарии.

Посмотреть историю изменений можно с помощью команды

svn log

Она выведет список ревизий с комментариями. С помощью дополнительных параметров этой команды можно ограничить список:

svn log --stop-on-copy – выводит перечень ревизий между последней и ближайшей, в которой была выполнена операция копирования (создания ветки)
svn log -r 100:200 – список изменений между ревизиями 100 и 200
svn log -r 100:HEAD – между ревизией 100 и последней ревизией проекта.

Допустим, мы выяснили, что нужные нам изменения сделаны в ревизиях 205 и 206 основной ветки проекта.

Теперь переключаемся на ветку brunches/web

svn switch file:///path_to_project/brunches/web

И выполняем слияние

svn merge -r 205:206 file:///path_to_project/trunk

Эта команда выполнит слияние изменений из ревизий 205 и 206 ветки trunc в текущую папку (на данный момент в этой папке находится рабочая копия ветки brunches/web).

Теперь можно зафиксировать изменения ветки brunches/web в репозитории с помощью команды commit и скопировать исправленную версию приложения на сервер.

Очень важно. При выполнении команды commit обязательно в комментарии укажите номера ревизий, из которых взяты изменения (например, «изменения из trunk -r 205:206»). Это позволит избежать повторного копирования этих изменений в дальнейшем.

После этого, можно опять переключаться на основную ветку (trunk) и продолжать разработку.

Как видите, все довольно просто, а главное – удобно.

Примечание. Вам не обязательно использовать командную строку. Существует множество графических клиентов для Subversion, которые предоставляют удобный доступ к командам. Например, TortoiseSVN или Subclipse.

Заключение

Эта статья не является руководством по использованию веток, я просто привел пример их использования, который, на мой взгляд, удачно отражает их преимущества. Причем пример ориентирован на индивидуальных разработчиков или команды из двух-трех человек. Если вы хотите серьезно использовать Subversion при разработке, советую почитать книгу Управление версиями в Subversion. Это полное руководство об этой замечательной системе управления версиями.

Удачи!

Напомню, для нашего проекта в хранилище создано две папки:
trunk – в ней будет находится основная ветка проекта;
и branches – для экспериментальных веток.

Теперь нужно создать рабочую копию. Для этого переходим в папку, которую будем использовать для работы с проектом, и выполняем команду:
svn checkout file:///e:/docs/svn/my_project/trunk

Обратите внимание, что к пути, указывающему размещение хранилища, мы добавили /trunk. Это означает, что мы создаем рабочую копию основной ветки проекта.

Т.к. на данном этапе проект пуст, то в папке с рабочей копией будет размещена только папка ".svn" (скрытая) со служебными файлами Subversion.

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

Добавляем файл в проект

Допустим, мы создали (в папке с рабочей копией) файл index.php и хотим добавить его в хранилище. Для этого выполняем команды:
svn add index.php
svn commit index.php -m "добавлен новый файл index.php"

Примечание. Если вы используете программы вроде TortoiseSVN, ищите в их меню команды Add и Commit. Обычно после выполнения Add на иконке файла появляется значок "+", а после выполнения Commit – галочка зеленого цвета (или что-то в этом духе). При этом открывается текстовый редактор для ввода комментария.

Еще одно примечание. Subversion не заставляет вас писать комментарии. Но если они хорошо составлены, то вы сможете легко ориентироваться в версиях ваших файлов. Поэтому не советую писать фразы вроде "Мелкие исправления" и т.п.

Предположим, вы написали в этом файле какой-то код, и хотите сохранить его в хранилище. Просто выполните команду:
svn commit index.php -m "написан заголовок страницы"

Subversion присваивает версиям файлов номера после каждого обновления хранилища. Используя эти номера можно возвращаться к любому сохраненному состоянию файлов или просматривать различия между ними.

Для обновления файлов используется команда:
svn update index.php – обновляет до последней версии в хранилище (т.н. HEAD версия)
Можно задать номер версии явно:
svn update index.php –r 1
Эта команда позволяет вернуться к любой предыдущей версии файла (т.н. "машина времени").

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

Примечание. Если вы работаете сами, то, скорее всего, использовать команду update будете довольно редко. Но если в разработке участвует несколько человек, то вам придется постоянно использовать эту команду для всего проекта, чтобы получить изменения, сделанные вашими коллегами.

Создание новой ветки

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

Естественно вы можете добавить эти функции в основную ветку (trunk), а при необходимости возвращаться к нужной версии проекта. Но представьте, что вы захотели сделать мелкие изменения на сайте. Если вы внесете эти изменения в хранилище, то они будут иметь более поздний номер версии, чем экспериментальные изменения.

Именно для таких ситуаций предусмотрена возможность создания дополнительных веток.
По-сути, создание новой ветки – это просто копирование существующей в новую папку (имеется в виду папка в хранилище, а не рабочей копии).
Сделать это не сложно:
svn copy file:///e:/docs/svn/my_project/trunk
file:///e:/docs/svn/my_project/brunches/experimental
-m “Экспериментальная ветка”
Эта команда создает внутри папки brunches папку experimental и копирует в нее все содержимое trunk.

Примечание. На самом деле файлы не копируются. Subversion сохраняет только исходное состояние файла и внесенные изменения. Таким образом, можно не беспокоиться, что хранилище станет слишком большим.

Теперь мы можем создать рабочую копию новой ветки
svn checkout file:///e:/docs/svn/my_project/brunches/experimental
спокойно вносить в нее изменения и сохранять их в хранилище.

Если вам понадобится вернуться к основной ветке проекта, выполните команду
svn switch file:///e:/docs/svn/my_project/trunk

Заключение

В этой статье описаны далеко не все возможности систем управления версиями. Для этого нужна целая книга (которая, кстати, входит в дистрибутив). Я просто хотел рассказать об основных возможностях этой системы.

Самое главное. Все данные находятся в хранилище. Поэтому регулярное создание его резервных копий не роскошь, а жизненная необходимость.

Если у вас возникли вопросы, замечания или вы хотите поделиться своим опытом работы с такими системами. Не стесняйтесь, комментарии открыты .

Интересно почитать

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

Но, прежде всего несколько слов о самих системах управления версиями. Это программное обеспечение предназначено для облегчения работы с постоянно изменяющимися файлами. Оно обеспечивает возможность сохранения промежуточных состояний файлов, создания нескольких версий одного файла (или их набора), позволяет переносить изменения между различными версиями файлов, просматривать внесенные изменения и многое другое.

Самое главное достоинство таких систем состоит в том, что из них не может исчезнуть информация. Т.е. всегда можно вернуться к однажды сохраненной версии файла, независимо от того, какие изменения были в него внесены.

Рассмотрим простой пример. Допустим, вы делаете web страницу. Проект состоит из трех файлов (с разметкой, таблицей стилей и скриптами). На каком-то этапе вы получили приемлемый внешний вид, но решили немного поэкспериментировать. Естественно эти эксперименты затронут все три файла, причем изменения будут внесены в различные их части.

Чтобы сохранить текущую версию проекта, вы делаете копию его файлов и экспериментируете уже с ними. Через некоторое время у вас накапливается десяток таких копий. И тут… вы находите ошибку в скриптах. Естественно, исправить ее нужно во всех копиях. И начинается карусель: "открыть" – "найти" – "вставить" – "сохранить" – "закрыть" – "перейти в следующую папку" – "повтор".

Если вы работаете в команде (даже из двух человек), то количество таких ситуаций растет как снежный ком. Потому что сюда добавляются исправления, сделанные вашим напарником.

Именно для таких ситуаций и разработаны системы управления версиями. Принцип их работы довольно простой. Для хранения информации создается специальное хранилище (что-то вроде базы данных), в котором сохраняются все внесенные в файлы изменения. Естественно, сохранение происходит исключительно по вашему желанию, и возвращаться вы сможете только к сохраненным состояниям.

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

Но эта статья об использовании систем управления версий при индивидуальной разработке, поэтому проблемы команд мы здесь рассматривать не будем.

Думаю, теории достаточно, переходим к реализации.

Выбор системы контроля версий

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

Установка и настройка Subversion

Здесь все предельно просто. Качаете с официального сайта дистрибутив и запускаете инсталлятор.

После установки вы сможете работать… но только через консоль. Естественно, это позволяет детально изучить работу системы, но вводить каждый раз имена файлов… мягко говоря, не очень удобно .

Поэтому советую сразу скачать какой-нибудь графический клиент для Subversion. Полный их список находится здесь.

Я пользовался двумя:
1) Subclipse – это плагин для Eclipse(http://www.eclipse.org/), т.е. для его использования нужна эта IDE.
2) TortoiseSVN – это более универсальная оболочка. Она встраивается в "Проводник" Windows. При этом к иконкам файлов добавляются значки, отображающие текущее состояние файла, а команды можно выполнять из контекстного меню.

Теперь нужно создать хранилище

Для этого создаем новую папку, например, e:\docs\svn.
И, находясь в этой папке, выполняем команду:
svnadmin create my_project
Эта операция создаст папку "e:\docs\svn\my_project" со служебными файлами хранилища.

Примечание. Если вы используете какой-нибудь клиент, ищите пункт Create Repository.

Перед отправкой файлов в хранилище очень желательно определиться со структурой проекта

Это, наверное, самый сложный этап для новичков (по себе знаю ).

Чтобы не морочить вам голову теорией приведу пару примеров, которые должны подойти для небольших проектов.

Первый пример. Используем две папки:
trunk/ – для размещения законченной (стабильной) версии (ветки) проекта;
branches/ – эта папка будут использоваться для экспериментов, т.е. в ней вы будете создавать папки с экспериментальными версиями проекта. Если вы решите, что какая-нибудь из этих версий должна заменить основную, то просто перенесете ее в trunk.

Второй пример удобно использовать, если нужны две версии проекта, различающиеся только несколькими файлами. Например, вы создаете web сайт, использующий базу данных. Параметры подключения к этой базе на вашем компьютере и на сервере будут отличаться, но не изменять же их каждый раз вручную.
Тут удобно использовать три папки:
trunk/
branches/
trunk_for_server/ – копия папки trunk для сервера (отличаются только файлы с параметрами подключения).
Перед закачкой файлов на сервер вы просто "сливаете" нужные изменения из trunk в trunk_for_server.

Примечание. Оба приведенных примера это только возможные варианты. Вы можете придумать свою структуру.

Переходим к созданию выбранной структуры в хранилище

Для этого создаем временную папку, например, e:\temp, а в ней пустые папки, соответствующие выбранной структуре.
Например, если вы остановились на первом варианте:

e:\temp\trunk
	\branches

Теперь, находясь в папке "e:", выполняем импорт этих папок в хранилище.
svn import temp file:///e:/docs/svn/my_project -m "Начальный импорт"

Удаляем e:\temp.

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

Интересное

Панорамные лифты otis удобное средство передвижения и украшение современного здания.