Комментарии 45
Последнее время отказываюсь от Phing в сторону SymfonyConsole. Все таки написание сценариев в xml не самое приятное занятие, да простят меня поклонники Ant.
С Symfony, дела не имел, и сравнивать не могу, но верно говорят — на вкус все фломастеры разные) Мне наоборот понравилась структуризация xml. К слову, SymfonyConsole, возможно использовать отдельно от фреймворка? Интересно было бы посмотреть.
А как консоль symfony поможет css и js сжать? Вы специальные таски для этого пишете?
У Symfony есть интеграция с Assetic, соответсвенно в фреймворке из коробки работает сжатие. Подробнее не расскажу, мало практики, но народ использует и вроде работает. Гугл вот такую статью, например, предлагает.
В принципе, таски можно вытащить, если нужна независимость.
А в общем случае нужно писать таски под свои задачи, так же как и для Phing.
В принципе, таски можно вытащить, если нужна независимость.
А в общем случае нужно писать таски под свои задачи, так же как и для Phing.
Неплохо рассказали, спасибо. Судя по именам директорий, Вы используете Yii — приятно)
А не используете ли Вы Phing в Continous Integration? Просто есть идея сделать топик на тему Yii+Phing+Jenkins (раньше назывался Hudson), что было бы логичным продолжением этой статьи.
А не используете ли Вы Phing в Continous Integration? Просто есть идея сделать топик на тему Yii+Phing+Jenkins (раньше назывался Hudson), что было бы логичным продолжением этой статьи.
Насчет Yii — верно) систем для Continous Integration пока не используем, но вскоре скорее всего придется, и к Jenkins/Hudson я как раз присматривался, но в ближайшее время врядли смогу что то стоящее написать, касательно этих систем(конечно поставить для пробы не долго, но это будет все же не то, про сравнению с реальным использованием), хотя заметку, на будущее, оставлю, спасибо за идею.
Обеими руками за инициативу Yii+Phing+Jenkins.
Вообще, интересен любой опыт использования Yii в масштабных проектах.
Вообще, интересен любой опыт использования Yii в масштабных проектах.
Я в своём бложике описал реализацию схемы yii+jenkins, но без Phing.
Думаю стоит написать преимущества перед Ant'ом. Пока заметил только это:
вы можете создать свои типы задач, всё делается очень просто и для разработчика разбирающегося в PHP и XML не составит труда.
Сомневаюсь что тут можно назвать много преимуществ, субъективно, мне было проще освоить Phing. Я думаю, что человек разобравшийся в Ant`е едва ли найдет плюсы у Phing, все же Ant, как то масштабнее чтоли, а значит функциональнее и сложнее. Ну и конечно написание своих задач на PHP будет плюсом для PHP программистов)
JVM можно не заводить на боевом сервере.
Из подобных вещей пока что больше всего понравился rake. Увы, он тащит с собой руби, но гибкость и простота решения будет гораздо выше, чем писать сценарии на новом псевдоязыке в формате xml — я много сценариев для nant написал в свое время >_<
Для php есть порт github.com/indeyets/pake/wiki. Правда не знаю насколько юзабельный.
> Увы, он тащит с собой руби
Почему увы? ,-)
Почему увы? ,-)
Заставлять людей программировать на XML — это бесчеловечно. Если бы у программистов была своя женевская конвенция, то запрет на программирование на XML был бы на первом месте.
Ну о программировании речи и не было) хотя описание задач на xml тоже смотрятся несколько не естественно, но согласитесь если бы нам предложили ещё один псевдо–язык, было бы ещё хуже, а с xml пожалуй любой веб–разработчик худо–бедно знаком)
XML — это просто набор правил оформления текста (Markup Language).
По факту вы _уже_ используете псевдо-язык (phing), который оформлен по правилам XML. Так что хуже от использования любого другого языка не станет (конечно при условии, что язык будет не хуже XML).
По факту вы _уже_ используете псевдо-язык (phing), который оформлен по правилам XML. Так что хуже от использования любого другого языка не станет (конечно при условии, что язык будет не хуже XML).
То что XML — язык разметки, известно, но сейчас он используется чаще всего именно для хранения\обмена структурированных данных, что собственно тут и делается(хранятся правила конфигурации сборщика, а не пишется этот самый сборщик на XML).
Тем не менее:
Во первых — с XML разработчики по большей части знакомы(хотя не отрицаю, писать циклы или fileset`ы на XML — противоестественно)
Во вторых — сделать язык не хуже XML, а потом заставить разработчика его выучить, занятие весьма неблагодарное.
Преимущество rake в Ruby разработке в том, что он создан для Ruby, и писать rakefiles приходится используя синтаксис Ruby.
Я вот, выбирая между Phing и Rake, выбираю первый не потому, что мне нравится XML, а потому что я просто не знаю синтаксиса Ruby, и для его освоения нужно _время_, большее чем на освоения синтаксиса Phing.
А время — деньги. Которые мне никто не возместит.
Тем не менее:
Во первых — с XML разработчики по большей части знакомы(хотя не отрицаю, писать циклы или fileset`ы на XML — противоестественно)
Во вторых — сделать язык не хуже XML, а потом заставить разработчика его выучить, занятие весьма неблагодарное.
Преимущество rake в Ruby разработке в том, что он создан для Ruby, и писать rakefiles приходится используя синтаксис Ruby.
Я вот, выбирая между Phing и Rake, выбираю первый не потому, что мне нравится XML, а потому что я просто не знаю синтаксиса Ruby, и для его освоения нужно _время_, большее чем на освоения синтаксиса Phing.
А время — деньги. Которые мне никто не возместит.
Да, но пока вы не упретесь в набор стандартных действий. Т.е. если вдруг понадобиться сделать что-то, что не включено в стандартную библиотеку действий, придется изучать инструмент гораздо глубже, чтобы написать модуль, расширяющий функционал. С phing php-программисту конечно попроще, но вот с Ant/NAnt уже все не так просто.
А вот rake изначально обладает всей мощью языка. Да и не так уж он сложен для освоения.
А вот rake изначально обладает всей мощью языка. Да и не так уж он сложен для освоения.
для rake надо писать на Ruby, что не катит никак для разработчиков на РНР.
Да ну почему же не катит? Изучить необходимое подмножество языка не сложно, зато потом не упретесь в вышеописанное мной.
Посмотрите статьи, просто же все вроде:
habrahabr.ru/blogs/htranslations/111331/
martinfowler.com/articles/rake.html
Посмотрите статьи, просто же все вроде:
habrahabr.ru/blogs/htranslations/111331/
martinfowler.com/articles/rake.html
а зачем заставлять изучать еще один язык?
А например мне в задаче хочется (а иногда и нужно) использовать методы из основного приложения…
А если, к примеру, Ruby как язык и среда сама по себе неприятна и не вызывает никакого желания приближаться? ;)
А например мне в задаче хочется (а иногда и нужно) использовать методы из основного приложения…
А если, к примеру, Ruby как язык и среда сама по себе неприятна и не вызывает никакого желания приближаться? ;)
Ну со сборщиками в любом случае придется изучать некоторый квази-язык… В общем, как всегда, зависит от задачи.
Я собирал множество проектов на C++ при помощи Ant/NAnt. Как появлялось что-то сложнее «скопировать файл, запустить компилятор», порой приходилось писать расширения для них. Честно, лучше бы я тогда выбрал rake :)
Тут понятно дело проще, так как phing на PHP, который вы знаете.
Я собирал множество проектов на C++ при помощи Ant/NAnt. Как появлялось что-то сложнее «скопировать файл, запустить компилятор», порой приходилось писать расширения для них. Честно, лучше бы я тогда выбрал rake :)
Тут понятно дело проще, так как phing на PHP, который вы знаете.
Полностью согласен с первым абзацем =)
Всё зависит от задач, и если нет времени\желания на изучение rake, Phing поможет PHP программисту автоматизировать сборку.
Но для сложных сборок, выгоднее будет скорее rake, так как потратив время на его изучение, мы начинаем просто писать rakefiles, а не тратим время на борьбу с ограничениями описания задач на XML.
Всё зависит от задач, и если нет времени\желания на изучение rake, Phing поможет PHP программисту автоматизировать сборку.
Но для сложных сборок, выгоднее будет скорее rake, так как потратив время на его изучение, мы начинаем просто писать rakefiles, а не тратим время на борьбу с ограничениями описания задач на XML.
> То что XML — язык разметки, известно, но сейчас он используется чаще всего именно для хранения\обмена структурированных данных, что собственно тут и делается(хранятся правила конфигурации сборщика, а не пишется этот самый сборщик на XML).
Вы не описываете данные, вы описываете программу. Просто в силу того, что xml ограничивает вас в синтаксических конструкциях, ваша программа пишется в декларативном стиле ( en.wikipedia.org/wiki/Declarative_programming ).
Выучить подмножество ruby используемое в rake намнго легче, чем освоить подмножество xml используемое в Phing. Потом подозреваю, что PhingXML не является Тюринг полным в отличии от ruby, что еще больше ограничивает его использование.
Вы не описываете данные, вы описываете программу. Просто в силу того, что xml ограничивает вас в синтаксических конструкциях, ваша программа пишется в декларативном стиле ( en.wikipedia.org/wiki/Declarative_programming ).
Выучить подмножество ruby используемое в rake намнго легче, чем освоить подмножество xml используемое в Phing. Потом подозреваю, что PhingXML не является Тюринг полным в отличии от ruby, что еще больше ограничивает его использование.
Ну, скажем, XSLT очень даже ничего, если говорить о программировании на XML, но у него и специфика соответствующая (трансформация из XML в XML) и конструкций не так много.
А Phing этот и правда жутковат. Как-то приходилось с ним сталкиваться. Впечатление: «можно было бы и как-нибудь попроще». Может правда недостаточно внимательно смотрел…
А Phing этот и правда жутковат. Как-то приходилось с ним сталкиваться. Впечатление: «можно было бы и как-нибудь попроще». Может правда недостаточно внимательно смотрел…
А с чем вы сравнивали XSLT? Ну там Smarty, HAML, или простой .php?
p.s. Результатом работы XSLT может быть что угодно, а не только XML. В том числе и plain text.
p.s. Результатом работы XSLT может быть что угодно, а не только XML. В том числе и plain text.
Для начала, XSLT может быть и не только шаблонизатором, это не совсем то же что и Smarty/HAML. Ну да ладно.
Доводилось работать с Smarty, Django шаблонами, mako шаблонами, просто PHP тоже само собой… Из всего этого XSLT оставил наиболее приятные впечатления. Хотя Django и Mako тоже ничего, но Django слишком простой, приходится кастомные теги клепать а mako позволяет как PHP вставлять любой питоний код в шаблон, что опасно.
// да, можно и в plain text, но в большинстве случаев из XML в XML/HTML.
Честно говоря, хотелось бы это обсуждение закончить т.к. к единому мнению вряд-ли придем))
Доводилось работать с Smarty, Django шаблонами, mako шаблонами, просто PHP тоже само собой… Из всего этого XSLT оставил наиболее приятные впечатления. Хотя Django и Mako тоже ничего, но Django слишком простой, приходится кастомные теги клепать а mako позволяет как PHP вставлять любой питоний код в шаблон, что опасно.
// да, можно и в plain text, но в большинстве случаев из XML в XML/HTML.
Честно говоря, хотелось бы это обсуждение закончить т.к. к единому мнению вряд-ли придем))
я использую спец. скрипт развертывания
ни каких ошибок.
технология развертывания — это тема отдельной статьи,
можно как нибудь написать на досуге.
ни каких ошибок.
технология развертывания — это тема отдельной статьи,
можно как нибудь написать на досуге.
Forever makefile
ух, после Rake такие объемные xml файлы кажутся лишним возвратом назад и обратно, я лично свои php проекты собираю через него, всё равно у меня и ruby везде стоит.
Непонятно зачем нужно разбираться во всех этих xml-ых тегах когда можно написать скрипт выкладки на том же php
ну, я хотел бы представить как будет выглядеть такой PHP скрипт который:
1) развертывает систему на тестовом сервере из svn (git, mercurial, etc.);
2) запускает тесты;
3) в зависимости от результатов тестов:
— автоматически реасигнит проект на доработку с ошибками по тестам;
— делает апдейт/развертывание проекта на удаленном сервере(-рах);
— обновляет БД;
— снова таки тестирует на живом серевер;
— включает доступ пользователям к системе;
— ну и еще много всяких полезностей к этому всему;
1) развертывает систему на тестовом сервере из svn (git, mercurial, etc.);
2) запускает тесты;
3) в зависимости от результатов тестов:
— автоматически реасигнит проект на доработку с ошибками по тестам;
— делает апдейт/развертывание проекта на удаленном сервере(-рах);
— обновляет БД;
— снова таки тестирует на живом серевер;
— включает доступ пользователям к системе;
— ну и еще много всяких полезностей к этому всему;
А можно узнать, что имеется в виду под «подготовкой сборки к релизу»?
Вот есть каталог с рабочей сборкой, с которой работают программисты. Вы преобразуете этот каталог так, чтобы его можно было залить на рабочий сервер? Или вы из рабочего каталога создаете рядом «релизный» каталог, в котором собирается релизная версия?
По какому сценарию идет работа?
Вот есть каталог с рабочей сборкой, с которой работают программисты. Вы преобразуете этот каталог так, чтобы его можно было залить на рабочий сервер? Или вы из рабочего каталога создаете рядом «релизный» каталог, в котором собирается релизная версия?
По какому сценарию идет работа?
Ну прежде всего это важно для непрерывной интеграции, тоесть мы сделали версию 1, и начинаем выпускать Nigtly builds, в случае с Phing, мы можем автоматизировать минификацию и сборку в один файл CSS и сжатие JS. Далее можно очистить от комментов и зашифровать Ioncube\Zend`ом php файлы, и запустить тесты, а если все прошло успешно выполнить заливку изменений на тестовый сервер, иначе сообщить разработчикам. А запуск сценария мы можем повесить на cron или назначить запуск в какой то из систем непрерывной интеграции, а-ля Jenkins, phpUnderControl, и тд…
Я же начал разбираться в Phing когда стал использовать LessCss и перед заливкой на боевой сервер мне нужно было скомпилировать .less в .css
Я же начал разбираться в Phing когда стал использовать LessCss и перед заливкой на боевой сервер мне нужно было скомпилировать .less в .css
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Phing — сборка PHP проектов