Как стать автором
Обновить

Комментарии 27

НЛО прилетело и опубликовало эту надпись здесь
Принципиально — ничего, но если честно — многое: не хочется ставить ruby, не хочется писать рецепты. Да и вопрос по прожорливости — композер, например, на моей скромной VDS-ке отпадает из-за нехватки оперативной памяти.

Я худо-бедно могу разобраться и поправить чужой рецепт, но свои писать не хочется.

А тут красота — скрипт делает ровно то, что я хотел (даже немного больше) и мало требует для работы.
Здорово придумано и сделано хорошо!

А нельзя такое сделать с помощью gulp?
Мне тоже понравилось. Думаю на досуге посмотреть, какие еще утилиты есть в репозитории автора.

А gulp умеет заливать на удаленный сервер? По-моему, нет.
Да, я даже нашел какие-то варианты.
Но, по-моему, всё-таки это разные инструменты, хотя и совместить сборку с деплоем — звучит соблазнительно.
Можно. Пример https://gist.github.com/akalongman/5c9f7049ad7c534b057b
Все мы любим классные и удобные методы деплоя с помощью… git pull

Что? Что-что-что? )))

Реальные пацаны делают так:

  1. Teamcity. До 20 сборочных конфигураций бесплатно.
  2. Teamcity видит изменения в Git. В нужной ветке, конечно же.
  3. Запускает "от бедра" rsync файлов в темповую директорию на целевом сервере
  4. В этой директории удаленно по ssh запускает сборочный скрипт на phing
  5. Скрипт делает всё остальное — раскладывает файлы по местам, накладывает конфиги с параметрами, миграции запускает, прокидывает симлинки и даже перезапускает php-fpm

  • бесплатно
  • удобно
  • один раз настроил и забыл
  • легко создавать тестовые стенды
  • phing умеет всё

А вы велосипед изобретаете, уважаемый. Не-нуж-ный. Ну зачем в 2016 году что-то заливать по FTP?
Мы на работе используем Git + Bamboo + Capistrano + Phing + Puppet, например, и тоже считаем себя реальными пацанами. Да, небесплатно, но зато отлично интегрируется друг с другом.

А почему вы обвиняете меня в изобретении велосипеда, поясните?
Как бы вам объяснить.

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

Во-вторых решения для деплоя и сборки давно уже есть. И вы не добавили к ним ничего нового. Просто повторили, но при этом гораздо хуже. Зачем? Хотите принести пользу — добавьте новый task в phing, который будет делать что-то полезное. Вам только спасибо все скажут.
Хостинги без ssh есть. Но проблемы нет — не надо просто ими пользоваться. Почти никто уже это не делает.

Угу, прекрасно жить в идеальном мире. В реальном же хостинг уже выбран и не вами, и php там 5.2 может быть. И прочее, прочее...
Зачем вы работаете с хостингами без ssh и PHP 5.2?
Какой в этом смысл?

Я живу не в идеальном мире. Но недавно закончил перевод довольно большого проекта на PHP 7. Что удивительно — "перевод" занял от силы пару человеко-дней. Что я делаю не так? Где я упустил тот момент, когда надо рыдать о несовершенстве мира и злой судьбе?
Что я делаю не так?

Работаете с большими проектами.
Описанные проблемы больше характерны для маленьких проектов и связаны с маленькими же бюджетами.
Да ладно.
И с маленькими вижу ту же картину. Объясните, зачем мне "хостинг", если я беру облачный инстанс "с рутом" за 250 рублей в месяц и сам себе хозяин — хочу PHP 7 поставлю, хочу — composer system-wide, хочу — сборочного агента TeamCity накачу?
"Хостинг"-то зачем?
Вы можете брать себе, что вам нравится. Но у заказчиков могут быть свои предпочтения и они, как правило есть. /Какими бы странными они не казались, чаще всего они легко объясняются простотой и стоимостью эксплуатации (для заказчика, не для вас).
Например, их проект, для которого вы делаете только один модуль, написан на PHP4 (у меня был такой случай в конце 2015).
Есть масса проектов, где вы не хозяин. Примите на веру, если у вас такого опыта еще не было.
у заказчиков могут быть свои предпочтения

А) Я не работаю с такими заказчиками. Просто не стану. Зачем?
и Б) Я не верю, что заказчик может выбирать, к примеру, версию PHP. Ему пофигу на версию. Ему нужно, чтобы задачи решались.
А опыт в PHP у меня с 2004 года, уважаемый коллега. И я не припомню случаев, чтобы заказчик, обратившись ко мне и платя мне деньги, вдруг бы стал навязывать свои технические решения.
Я за вас рад. И ни в коем разе не агитирую за тот или иной способ деплоя.
Вы выразили сомнение в разумности и адекватности описанной автором методики. Я лишь подтверждаю — да, действительно, в этом году еще есть ситуации, когда используется FTP и ничего кроме.
У меня большинство заказчиков именно такие. Вы правы, они чаще всего не навязывают технические требования. Они сами просто не могут на них влиять. Чаще всего не имея полномочий в рамках своей организации или будучи посредниками.
То, что у вас все не так, это очень хорошо. Либо вам везет, либо вы как-то особенно ведете дела (поиск заказов, пресейл,… ).
Если второе, то расскажите об этом… может вы уже где-то писали или можете написать пост-другой?
Да нет, никакого везения. Просто четкая жизненная позиция — "Вы платите мне деньги за то, чтобы я определял, как сделать правильно". Если заказчик не согласен с этой максимой, он свободен в выборе другого подрядчика.
Я искренне не понимаю, что тут еще сказать? Хотите работать с PHP 7? Ну так начните это делать сейчас. Не хотите использовать FTP? Не используйте. Зачем из сугубо технических вопросов, решение которых входит в вашу зону ответственности, делать какую-то вселенскую трагедию?
Похоже, вы прочитали только краткую версию, "для тех, кто спешит", и сделали неверный вывод, что я — автор этой утилиты.

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

Поэтому я нашел еще одно решение для деплоя, которое умеет не так много, но зато и требует элементарного ini-конфига для работы. Зачем для простой задачи использовать сложные решения?
На любом сколько-нибудь терпимом хостинге есть SSH. Если SSH отсутствует, хостинг должен идти лесом, ибо с FTP вечно какие-то проблемы.
Имея SSH на хостинге, мы можем монтировать его диск к себе, используя SSHFS. Отсюда вытекает много плюсов, основные из которых:

  1. Возможность работать с удалённым сервером так, словно это делается локально.
  2. Возможность использовать любые инструменты, включая VCS (вытекает из предыдущего пункта).
Но я вижу и некоторые минусы, например:

  1. Ошибки сразу же оказываются на удаленном сервере
  2. Надо использовать обходные маневры для конфигов БД

Похоже, вы активно используете sshfs. Как там со скоростью? С большими файлами? С множеством мелких?
Ошибки сразу же оказываются на удаленном сервере
Я ж не призываю сразу на продакшоне разрабатывать. Это может быть dev-сервер. Ссылку на который можно в любой момент дать кому-либо. Плюс разрабатывать откуда угодно без лишних синхронизаций.

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

Похоже, вы активно используете sshfs. Как там со скоростью? С большими файлами? С множеством мелких?
Откровенно говоря, никогда не занимался замерами. Скорости всегда хватало.
Большое количество файлов, навскидку, проще сначала завернуть в архив, залить на сервер, а уже с сервера распаковать. Но это очень субъективно, с заливанием по FTP было резонно, а тут без замеров точно не сказать.
Присоединюсь к коменту выше. Нужно объяснять таким людям с хостингом без ssh и современного интерпритатора, что они делают неправильно.

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

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

Вообще, я, конечно, согласен, что нужно объяснять людям всё мракобесие хостингов без ssh, со старой версией пхп и т.п. Однако большинство людей по природе консерваторы, не любят перемен.

Для юридического лица, к тому же, смена хостинга сопряжена с бумажной работой. Особенно если он оплачен авансом на несколько лет, например.
Ого, какое ретро — шаред хостинг — как в 90х прямо ))
Кому хи-хи, а кто прошёл путь от техподдержки хостера до хостмастера.
И по итогам партии блекджека длиною в несколько лет пишет свою админ панель для вот этого всего.
И да, шаред хостинг очень популярная штука, но в реалиях СНГ рынок регистраторов доменов и хостингов адски, чертовски адски перегружен, даже не смотря на то что 90% сайтов на одном из серверов шареда раз в неделю заходят только гугль боты и раз в месяц пару живых людей — оно востребовано, да. Но прибыли приносит только у очень раскрученных крупных хостеров со своими цодами.
Но и стоит оно обычно копейки...
У PHPStorm хорошо это сделано. Можно указать, что деплоить а что нет. И самая полезная для меня фича — это показать, что сейчас отличается на сервере от локальной копии.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации