Комментарии 66
А где вариант sshfs?
Видимо, в «другом» — к сожалению, сейчас уже не добавлю в опрос. Я еще думаю, не будет ли сколько-нибудь большого числа ответов типа «использую виртуальную ФС-схему в KDE», «использую виртуальную ФС-схему в Gnome», «использую виртуальную ФС-схему в Midnight Commander» и т.д. — это все в принципе те же варианты монтирования.
Вот что характерно — сейчас уже явно заметен количественный перевес FTP (47%) над всеми другими вариантами — но никто из ответивших так в комментариях не отметился. Может кто-нибудь из тех, кто использует FTP, пролить свет на то, почему именно FTP?
Потому что поддерживается моим любимым FAR-ом, в котором я одновременно могу поправить код с подсветкой синтаксиса. Также куча народу пользуется Total Commander-ом. Все так привыкли.
Хотя, я, например временами пользуюсь SFTP-соединением.
Хотя, я, например временами пользуюсь SFTP-соединением.
Поставьте WinSCP-плагин
Он не работает в Far2 (x64).
Есть плагин NetBox, который работает и во втором — github.com/michaellukashov/Far-NetBox
Поддерживает SFTP, SCP, FTP, FTPS и WebDAV.
Поддерживает SFTP, SCP, FTP, FTPS и WebDAV.
Это тот же sftp, только в виде виртуальной FS.
Как правило scp, но в некоторых случаях git.
svn, git
Тут больше подошли бы чекбоксы.
Интересно узнать наиболее предпочтительный, первичный вариант. Например, приходит хороший знакомый и слезно просит «исправить файл у него на сайте, логины-пароли дам» — что скорее всего будет использоваться на его хостинге?
Тут уж что будет у знакомого. Как бы ты не любил свою систему деплоймента — у знакомого может оказаться только банальный FTP и никуда не деться.
Вот примерно об этом и опрос: я до недавних пор много лет как уже FTP в глаза не видел, везде SSH/SFTP/SCP — а недавно один товарищ мне заявил, что у него кроме FTP на хостинге ничего нет, а другой товарищ — что кроме FTP ничем не умеет пользоваться. При том, что товарищи — весьма уважаемые мной и компетентные в своих областях люди — я был сильно ошарашен и решил узнать — так ли это на самом деле.
А где вариант «систему деплоймента, встроенную в инструментальные средства, но я точно знаю, как она работает»?
Ну, можно же «точно знать, как она работает», но при этом «не задумываться» каждый раз, когда используешь — вроде бы одно другому не противоречит?
Я не очень понимаю, зачем вообще это уточнение про «не задумываюсь».
Перед тем, как проводить опрос на хабре, я провел мини-опрос среди своих знакомых. Среди полученных вариантов ответа, кроме остальных, вырисовывались 2 кластера: «использую систему деплоймента, которую написал сам / принята в компании / т.п.» (в этом случае человек, как правило, хорошо знает, какая комбинация ssh / vcs / rsync каких-то еще действий там используется) и «использую систему деплоймента в моей IDE» (и при этом человек, как правило, затрудняется ответить на вопрос, какие именно там протоколы — но смысл в том, что ему действительно не обязательно это знать — он нажимает кнопку — у него все работает).
Вам не приходило в голову, что когда люди используют систему, принятую в компании, они точно так же не знают, как она работает, как если бы она была включена в IDE?
Согласен, что понятия весьма размытые: если работаешь, скажем, в Microsoft или каком-нибудь JetBrains — «включена в IDE» будет равняться «своя собственная».
Ответ, который хотелось получить, лежит в плоскости альтернатив сложившейся ситуации. Скажем, если огромная туча народа действительно сознательно использует FTP — то FTP-сервер обязан быть, тучу народа переучить сложно. Если туча народа использует IDE — то переучивать народ не нужно, можно договориться с авторами IDE о поддержке на той или другой стороне и решить вопрос радикальнее.
Ответ, который хотелось получить, лежит в плоскости альтернатив сложившейся ситуации. Скажем, если огромная туча народа действительно сознательно использует FTP — то FTP-сервер обязан быть, тучу народа переучить сложно. Если туча народа использует IDE — то переучивать народ не нужно, можно договориться с авторами IDE о поддержке на той или другой стороне и решить вопрос радикальнее.
А вы не думали, что у вас распределение ответов сильно зависит от характера деятельности?
Любой опрос и статистика в любом случае будет biased. Можно вспомнить про региональные отличия, про то, что на Хабрахабре все-таки довольно специфическая тусовка IT-шников и т.д.
Вас что именно не устраивает: конкретные формулировки, в целом выбор кластеров ответов или вся идея такого опроса кажется бесполезной?
Вас что именно не устраивает: конкретные формулировки, в целом выбор кластеров ответов или вся идея такого опроса кажется бесполезной?
Вся идея этого опроса.
Потому что мы, например, принципиально не обновляем «файлик на сервере», мы деплоим приложение целиком, и у нас под это заточен специальный агент. А люди, которые поддерживают простенький сайт-визитку, могут работать с файлами поодиночке.
Принципиально разные сценарии использования — и оба из них совершенно допустимы в рамках хабра.
Потому что мы, например, принципиально не обновляем «файлик на сервере», мы деплоим приложение целиком, и у нас под это заточен специальный агент. А люди, которые поддерживают простенький сайт-визитку, могут работать с файлами поодиночке.
Принципиально разные сценарии использования — и оба из них совершенно допустимы в рамках хабра.
git
Прямо вот git push напрямую или все-таки через какую-то систему деплоймента?
Через github.com, что-то делаю на локальной машине, потом делаю push на github, а потом, в случае необходимости, делаю pull на сервере. Мне очень удобно.
А как решаете проблему с .git в htdocs? Или просто делаете так, чтобы .git не попадал в htdocs?
Я не совсем понял что такое htdocs, но если Вы имеете ввиду корневую папку сервера для доступа извне, то у меня практически всегда front-end'ом стоит Apache и с помощью .htaccess можно сделать эту папку недоступной.
А я практически не видел фреймворков, в которых в docroot было что-то кроме статики и фронтэнда — поэтому я даже не закрываю. .git все равно недоступен так как на один уровень выше, а svn — ну да, тут надо — вспоминается эпичное расскрытие исходников через .svn вроде года два — три назад
Вообще очень неоднозначный вопрос
Какой именно файл?
Если это код, то он выгрузится из git/svn.
Если это конфиг, то его можно править прямо на сервере.
Если большой файл типа дампа, или куча больших файлов то rsync.
Если сервер особо упоротый, то остается только FTP или SMB — в зависимости от того что там есть.
Если нужно что-то обновить/выполнить перестроить, то систему деплоймента потому что как всегда нужно будет еще и кеши например почистить или миграции выполнить.
Какой именно файл?
Если это код, то он выгрузится из git/svn.
Если это конфиг, то его можно править прямо на сервере.
Если большой файл типа дампа, или куча больших файлов то rsync.
Если сервер особо упоротый, то остается только FTP или SMB — в зависимости от того что там есть.
Если нужно что-то обновить/выполнить перестроить, то систему деплоймента потому что как всегда нужно будет еще и кеши например почистить или миграции выполнить.
Ключевая фраза — «скорее всего». Что из указанных выше действий происходит чаще всего, например, у вас лично?
На первом месте git, на втором ручная правка конфигов.
На одном сервере пришлось юзать ftp — было много мата, потом lftp с mirror и потом git-ftp.
Сейчас потихоньку начинаю использовать phing.
Я вообще в шоке от популярности FTP
На одном сервере пришлось юзать ftp — было много мата, потом lftp с mirror и потом git-ftp.
Сейчас потихоньку начинаю использовать phing.
Я вообще в шоке от популярности FTP
А git — прямо напрямую git push / pull, без какой-то системы деплоймента?
Насчет FTP — что характерно — при таком значительном перевесе в рейтинге в комментариях пока еще никто не признался в том, что его использует.
Насчет FTP — что характерно — при таком значительном перевесе в рейтинге в комментариях пока еще никто не признался в том, что его использует.
Пока напрямую, но перехожу на phing, потому что пишу на symfony а там и кеш почистить и композер запустить и миграции и еще куча всякого добра, только писать это все надо.
Блин, он похоже как IE6 :) Когда было >50% и думаешь — кто эти люди…
Блин, он похоже как IE6 :) Когда было >50% и думаешь — кто эти люди…
А .git прячете какими-то настройками веб-сервера?
неа — habrahabr.ru/post/155739/#comment_5318639
выше все равно nginx или апач не пустит
выше все равно nginx или апач не пустит
НЛО прилетело и опубликовало эту надпись здесь
Вот и я тоже, на самом деле.
А в чем неудобство, если нужно быстро поправить какой-то файлик-два, то вполне подходит FTP, тем более, если ты не только своими сайтами занимаешься. Тем более, что FTP-клиенты давно научились автоматом заливать изменения редактируемого файла, т.е. открыл в любимом редакторе, нажал Ctrl+S и изменения мгновенно сохранились на серваке. SFTP и SCP особого удобства не добавляют, и уже больше зависит от того есть ли они на серваке и знает ли о них клиент.
Лично я в основном использую Remote Desktop. Просто и удобно, со сервером почти постоянно соединен.
А если обновить сайт клиента то FTP. У них сайты не большие максимум 30МБ. Могу и все файлы обновить.
А если обновить сайт клиента то FTP. У них сайты не большие максимум 30МБ. Могу и все файлы обновить.
Если это конфиг, то ssh + vi. Если надо просто залить какой-то файл, то то scp или wget. Что касается обновления кода, то чаще всего git.
А ещё встречал такие способы:
— аплоад файла через админку сайта.
— remote project в eclipse-подобных ide, открытие и сохранение файла прямо на сервере через ftp/sftp.
— особый хардкор на закуску: отправка файла на сервер через служебный email, вложением. :)
А ещё встречал такие способы:
— аплоад файла через админку сайта.
— remote project в eclipse-подобных ide, открытие и сохранение файла прямо на сервере через ftp/sftp.
— особый хардкор на закуску: отправка файла на сервер через служебный email, вложением. :)
cap deploy
svn/git
Весь деплой происходит через Springloops, то бишь встроенными возможностями, однако они используют SCP.
Если брать типичный веб-хостинг за 5$, то git-over-ftp. Если нормальный, то capistrano + git.
git-over-ftp — это что-то типа этого скрипта или вот этого?
Вот этот использовал на практике. Достаточно удобно.
hg push на dev-сервер, где работает hg serve, спрятанный за nginx с авторизацией. Потом hg pull на продакшн или тест сервере. Все каталоги репозиториев вне рута веб сервера.
По возможности ssh/rsync.Тупо потому что быстрее, да и заскриптовать по быстрому могу.
Но не редко есть возможность только с ФТП работать. Т.к. я ленивый иногда, юзаю curlftpfs. Так же использую, если по быстрому надо залить файлик. Бэкапы не редкие, поэтому откатить не трудно.
Вообще, если ситуация что только FTP доступен, то нет никаких преград использовать и другие программы для деплоя(опять же юзая curlftpfs).
Главное чтобы частых IO не было.
Но не редко есть возможность только с ФТП работать. Т.к. я ленивый иногда, юзаю curlftpfs. Так же использую, если по быстрому надо залить файлик. Бэкапы не редкие, поэтому откатить не трудно.
Вообще, если ситуация что только FTP доступен, то нет никаких преград использовать и другие программы для деплоя(опять же юзая curlftpfs).
Главное чтобы частых IO не было.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Если нужно обновить файл на веб-хостинге, я скорее всего использую