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

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

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

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

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

Например, так
Читать дальше »

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

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

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

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

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

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

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

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

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

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

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

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

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

В прошлой статье мы начали знакомство с одной из самых популярных на сегодняшний день систем управления версиями – 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"
Читать дальше »

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

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

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

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

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