Phing Is Not GNU

Таким образом программист может за три часа написать программу, которая сделает за пять минут то, что другой человек делал бы целый час…
© Кто-то

«Дорогая, а гладить ты умеешь?»

Много слышал и читал про phing, но пощупать досконально нехватало времени и желания. И вот наконец моё свободное время было потрачено (и не зря) на изучение сего монстра

“Монстром” я называю phing в “хорошем” смысле этого слова – это настоящий кухонный комбайн, СВЧ-печь и стиральная машина в одном флаконе архиве.

Что же это всё-таки такое?. Phing это Ant воссозданный на php. (Вопросы “Чё эта?” и “а нахер?” Вы можете задать непосредственно разработчикам того и другого, а я продолжу…).

 Тем кто знает что такое Ant вероятнее всего phing не нужен,тем кто не знает, но интересуется, могу посоветовать хорошую вводную статью, а остальным попытаюсь объяснить вкратце суть явления.

«Но есть способ лучше!»

В процессе разработки чего-либо возникают невероятное количество однообразных операций, которые порядком утомляют.
Как пример из  собственной практики – удаление «ненужных» файлов (очистка всемозможных кешей, временных файлов и т.п.), создание структуры директорий (расстановка необходимых прав доступа), удаление debug-кода из скриптов(массовый search-n-replace в определённом наборе файлов), компоновка кучи мелких «инклюдов» в общий файл  и много-много подобных мелочей…

Можно конечно всё сделать “вручную”.  А можно рутинную работу поручить машине. Одним из способов это сделать являются build-файлы для phing. build-файл представляет собой xml-ку в которой указан проект – совокупность задач (target-ов), которые следует выполнить, а так же последовательность (зависимость – depends в терминах phing) их выполения.

<project name=»make_release» basedir=»..» default=»build»>
    <taskdef classname=»phing.tasks.ext.PhpStripCommentsTask» name=»phpstripcomments» />
    <taskdef classname=»phing.tasks.ext.JsLintTask» name=»jslint» />
    <target name=»clear_cache_dir»>
        <delete>
          <fileset dir=»cache»>
            <include name=»*» />
          </fileset>       
        </delete>      
    </target>
    <target name=»lint_before_strip»>
          <jslint jslbinary=»/usr/bin/jslint» failonerror=»true»>
              <fileset dir=».»>
                <include name=»**/*.js»/>
                <exclude name=»**/.old_site/**» />                
              </fileset>
          </jslint>        
       <!– skip –>
    </target>
<!– ….skip –>
    <target name=»build» depends=»prepare,clear_cache_dir,lint_before_strip,dump_db,copy_src,cleanup_src,remove_debugging,lint_after_strip,simpletests»>
<!– skip –>
<mail to=»me@mydomain.tld» subject=»build complete»>The build process is a success…</mail> 
</target>
</project>

После запуска phing начнёт выполнять default task (в примере – build), и поскольку его выполнить нельзя пока не выполнены depends, то начнёт их делать по указанному порядку… ну и на радостях отправит мне письмо (что конечно лишнее)

«Но и это ещё не всё…»
Спектр задач которые в настоящий момент способен решать phing довольно широк (от файловых операций и строковых манипуляций, до работы с svn, simpletest и phpdoc). Для тех кому зазо исходного набора окажется недостаточно есть замечательная возможность плодить task-и самостоятельно – просто наследуйте новый класс от базового Task и вперёд.
Мне не хватило jslint, jscompress и zndenc – на создание коих было бесследно утрачено минут 15 драгоценного времени. В настоящий момент (ага вот прямо сейчас) обдумываю написание самого аццкого таска – ftpupload (или ftpsync).

Интересный момент – target-ы выполняются строго по порядку и если произойдёт некая непредвиденная ситуация(файл нельзя записать или например как в примере выше в проверяемом коде обнаружится синтаксическая ошибка) другие таргеты выполнятся не будут, выполнение будет прервано exception-ом. Собственно момент интересен тем что можно создавать собственный обработчик этих самых exception-ов, в которых делать «правильные выводы» о том стоит ли продолжать работу или смело «to die if necessary…».

Другая интересная возможность – делать собственные logger-ы – потому как наблюдать за бурной рабочей деятельностью phing-а в консоли не больно удобно. В  стандартной поставки для примера  есть AnsiColorLogger, который  слегка  «приукрашивает» серые терминальные будни. А можно пойти дальше – складывать логи в sqlite например.

«А вы поменяете две пачки обычного порошка на одну пачку необычного?»

Чем хорош именно phing – он написан на php5 – я могу исправить, дополнить и добавить недостающие фичи (Ant несомненно хорош, имеет кучу готовых плагинов, но написан на java, которую я совсем не знаю). Стандартный (g)make откровенно бесит синтаксисом makefile-ов, pake (идея видимо нагло стырена с rake)тоже ничего (хорошего), но уж слишком прост и расширять его возможности довольно муторно :).
Тонна мелких и крупных shell-perl-php-cmd скриптов, которые я ранее использовал для решения сиюминутных насущных проблем тоже порядком задолбали.
Чем плох – xml как формат build-файлов (хотя на вскидку лучшего предложить ничего не могу, но «аллергия» на xml ещё не прошла) и написан  на php5 ;o) – скорость работы оставляет желать лучшего (18 минут на сборку,проверку и упаковку 10-ти мегабайтного проекта на мой взгляд это много).
Но «удобность» всё-таки решает. Так что:

$> pear channel-discover pear.phing.info$> pear install phing/phing

И вперёд…

Technorati Tags: dev, build, phing, php