Сразу хочу сказать, что я не претендую на описание идеального окружения для Web-разработки. С удовольствием послушаю критику, приглашаю всех поделиться своими подходами в комментариях. В общем, поехали.
Подождите, а чем плох денвер?
Основной недостаток денвера состоит в том, что проекты в production не работают на денвере. А значит мы не можем гарантировать, что тщательно отлаженные на компьютере разработчика скрипты не начнут «чудить», когда попадут в production. В production проекты обычно работают в Linux (в нашем случае это CentOS или Amazon Linux). Кроме того, работая на денвере, мы не сможем использовать различные утилиты и средства, которые нам нужны в проекте (например, catdoc, поиск sphinx и многое другое).
Ок, но ведь не все готовы работать в Linux!
Разрабатывать прямо в Linux, конечно круто, но правда жизни такова, что большинство разработчиков пользуются Windows в качестве основной OC на компьютере. Поэтому дальше я опишу наш рецепт, как работая в Windows, разрабатывать сайты в Linux.
Мы используем CentOS 7, но думаю, без существенных изменений все будет работать и на других дистрибутивах.
Создаем образ виртуальной машины
Ок. Первое, что нужно сделать — это поставить на компьютер гипервизор (VmWare Workstation, Oracle VirtualBox или может какой-то другой по вкусу). Мы используем VmWare. После этого создаем виртуальную машину и разворачиваем в ней тот образ Linux, на котором будут работать наши проекты в production. Устанавливаем Web-сервер, СУБД, в общем все, что нам нужно для запуска проекта. Кстати, если есть образ виртуалки для production, то еще лучше — можно его и взять за основу.
Виртуалку удобнее всего подключить через bridged-сетевой интерфейс. Так она будет полноценным участником сети и можно будет легко показывать результаты коллегам или заказчикам, если пробросить порт из внешнего мира.
Сетевая папка
Первый вопрос, который у нас встал на этом этапе. Нам теперь что, скрипты проекта через putty редактировать?! И очевидное решение, которое мы нашли, было удивительно простым. В Windows-машине нужно завести отдельную папку, в которой будут лежать все наши проекты. Эту папку нужно расшарить для доступа по сети и примонтировать в корневую директорию, с которой работает Web-сервер.
Чтобы все это работало надежнее, я написал скриптик cifs_mount.sh, буквально из 2 строчек кода, который поставил в виртуалке на запуск раз в 5 минут.
#!/bin/sh
if ! mount -t cifs | grep -q `cat /root/file_server`
then mount -t cifs -o uid=apache,gid=apache,iocharset=utf8,noserverino,credentials=/root/.cifscreds `cat /root/file_server` /var/www
fi
Скрипт проверяет, не отвалилась ли шара (простите мой французский). И если отвалилась, обратно ее монтирует.
Файл /root/file_server
//192.168.0.2/Projects
Файл /root/.cifscreds
username=developvm
password=secretpass
В целом, это решение работает надежно, как утюг.
Также бывает наблюдаются периодические проблемы с неполной загрузкой страниц (не подгружаются CSS или вообще ошибки при попытке Apache прочитать файл). Причем это возникает время от времени без какой-либо системы.
При этом в логе ошибок Apache следующие ошибки:
[Tue Oct 20 10:44:28.417589 2015] [core:crit] [pid 9632] (5)Input/output error: [client 192.168.1.5:60666] AH00529: /var/www/project/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/var/www/project/' is executable, referer: http://192.168.1.102/script.php
[Tue Oct 20 10:44:28.418762 2015] [core:error] [pid 9555] (5)Input/output error: [client 192.168.1.5:60670] AH00132: file permissions deny server access: /var/www/project/css/main/layout-main.css, referer: http://192.168.1.102/script.php
Чтобы ликвидировать все эти проблемы разом, нужно подредактировать реестр Win7, а именно:
1. У HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache установить значение 1
2. У HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\size установить значение 3
После этого перезапустить LanmanServer. “net stop srv”/“net start srv”. На виртуалке перемонтировать шару.
Не стоит пугаться этих нюансов! Они накопились у нас почти за 10 лет разработки с использованием этого подхода.
Итак, что мы имеем. Теперь мы можем работать со скриптами в привычном нам редакторе кода в Windows. А результаты смотреть в браузере, заходя на нашу виртуальную машину. Идем дальше.
Подпапки для проектов.
А что если у нас больше 1 проекта. Каждый раз поднимать новую виртуалку!? Нам на помощь приходят виртуальные хосты. Придется опять написать небольшой скриптик flush_vhosts.sh (сугубо для удобства работы).
#!/bin/sh
rm /etc/httpd/conf.d/vhosts/*
rm /etc/hosts
echo '127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4' >> /etc/hosts
echo '::1 localhost localhost.localdomain localhost6 localhost6.localdomain6' >> /etc/hosts
for D in `find /var/www -maxdepth 1 -mindepth 1 -type d -printf '%f\n'`
do
echo '<VirtualHost *:80>' >> /etc/httpd/conf.d/vhosts/$D.conf
echo "ServerName $D.wde" >> /etc/httpd/conf.d/vhosts/$D.conf
echo "ServerAlias *.$D.wde" >> /etc/httpd/conf.d/vhosts/$D.conf
echo "DocumentRoot /var/www/$D" >> /etc/httpd/conf.d/vhosts/$D.conf
if [[ $D == *"bitrix"* ]]
then
echo 'php_admin_value mbstring.func_overload 2' >> /etc/httpd/conf.d/vhosts/$D.conf
echo 'php_admin_value mbstring.internal_encoding UTF-8' >> /etc/httpd/conf.d/vhosts/$D.conf
echo 'php_admin_value max_input_vars 10001' >> /etc/httpd/conf.d/vhosts/$D.conf
echo 'php_admin_value pcre.recursion_limit 1000' >> /etc/httpd/conf.d/vhosts/$D.conf
fi
echo "</VirtualHost>" >> /etc/httpd/conf.d/vhosts/$D.conf
echo "127.0.0.1 $D.wde" >> /etc/hosts
done
systemctl restart httpd.service
Вот что он делает:
1. Очищает конфигурацию виртуальных хостов.
2. Очищает /etc/hosts.
3. Дальше он проходится по всем подкаталогам нашей примонтированной папки и создает для каждого каталога новый виртуальный хост Apache. Если в названии каталога находится страшное слово bitrix, то он добавляет в конфиг виртуального хоста несколько специфических настроек для этой замечательной CMS. Добавляет в /etc/hosts новые записи для созданных виртуальных хостов.
4. Перезапускает Apache.
Мы использует в адресах проектов для разработки условный домен первого уровня wde (web developer environment). Можно использовать local или кому что нравится. У нас разрабатываемые проекты доступны по адресам project1.wde, project2.wde и так далее. При этом виртуальные хосты создаются с директивой ServerAlias *.your-folder-name.wde, то есть все поддомены будут также обрабатываться созданным для папки виртуальным хостом.
Таким образом, если нам нужно начать работу над новым проектом, достаточно создать новую папку в общей папке проектов. Выполнить скрипт flush_vhosts.sh. А в Windows прописать адрес для нового проекта в файле C:\Windows\System32\drivers\etc\host.
192.168.1.166 wde
192.168.1.166 site1.wde
192.168.1.166 site2.wde
...и т.д.
Звездочки файл hosts к великому сожалению, не поддерживает. Надо прописывать каждый адрес, с которым будем работать. Вместо 192.168.1.166 нужно указать ip, который вы присвоили виртуальной машине. После этого соответствующий проект будет открываться в браузере по адресам site1.wde или site2.wde и так далее.
Для удобства, если вы пользуетесь, phpMyAdmin, его можно настроить дефолтным хостом. Тогда при обращении по любому адресу, когда Apache не будет находить соответствующую папку проекта, он будет открывать phpMyAdmin. Главное не забыть прописать этот адрес (например, просто wde) в файле hosts в Windows.
Организация загрузочного меню
Чтобы было совсем удобно. И не приходилось новым членам команды объяснять, как обновить конфигурацию виртуальных хостов, настроить сетевую папку и т.д. Я написал еще несколько скриптов для вывода и запуска частых действий через меню. В них нет ничего сверхестественного, прикладываю — может быть кому-то тоже пригодятся.
Собственно скрипт, выводящий меню. Его нужно прописать в файле .bash_profile домашней директории пользователя, под которым мы входим на виртуалку. Для виртуалки, на которой ведется разработка, я считаю можно входить под root, соответственно добавляем в файл /root/.bash_profile строчку ./menu.sh. Теперь сразу после входа в систему будет запускаться наше меню. При необходимости из него всего можно выйти, нажав Ctrl+C.
#!/bin/sh
SCRIPT_DIR=`dirname $0`
source $SCRIPT_DIR/utils.sh
#menu actions
act_net () {
nmtui ;
}
act_folder () {
$SCRIPT_DIR/mount_cfg.sh ;
}
act_flushvhosts () {
$SCRIPT_DIR/flush_vhosts.sh ;
}
act_reboot () {
read -p "System is going to reboot, are u sure? (y/N) " key ;
if [ $key = "y" ]; then
systemctl reboot ;
exit
fi
key=
}
act_shutdown () {
read -p "System is going down, are u sure? (y/N) " key ;
if [ $key = "y" ]; then
systemctl halt ;
exit
fi
key=
}
themenu () {
clear
server_uptime
mnt_detect
echo "===================================================================="
echo "======================= WELCOME to CENTOS WDE!!! ==================="
echo "===================================================================="
echo "======================== wish you happy coding ====================="
echo "===================================================================="
echo -e "System time: "$curtime"\tUptime:"$uptime;
echo ;
echo -e "Mounted folder: "$MNT;
echo ;
echo "=========================== network info ==========================="
echo "`ifconfig -a`"
echo ;
echo `grep nameserver /etc/resolv.conf`
echo ;
echo "`route -n`"
echo ;
echo "====================== current vhosts configs ======================"
echo "`ls -1 /etc/httpd/conf.d/vhosts/`"
echo ;
echo "===================================================================="
echo "========================= Available actions: ======================="
echo -e "\t\tConfigure ${FG_UN}net${NORM}"
echo -e "\t\tConfigure mounted ${FG_UN}folder${NORM}";
echo -e "\t\t${FG_UN}Flush${NORM} virtual hosts";
echo -e "\t\t${FG_UN}Reboot${NORM}";
echo -e "\t\t${FG_UN}Shutdown${NORM}";
echo
echo "Type underlined chars(lowercase) and press ENTER or just ENTER to refresh";
echo "Type Ctrl+C to exit to shell";
echo "====================================================================";
}
while true
do
themenu
read answer
case $answer in
"net") act_net;;
"folder") act_folder;;
"flush") act_flushvhosts;;
"reboot") act_reboot;;
"shutdown") act_shutdown;;
*) echo 'No action found! Refreshing...'; sleep 1; continue;;
esac
done
#!/bin/sh
set -o pipefail
mnt_dir="/var/www"
if [ "$interactive" != 'no' ]; then
#cursor movements
CU_RIGHT=$(tput hpa $(tput cols))$(tput cub 7)
#background colors
BG_BLACK=$(tput setab 1)
BG_RED=$(tput setab 1)
BG_GREEN=$(tput setab 2)
BG_YELLOW=$(tput setab 3)
BG_BLUE=$(tput setab 4)
BG_PURPLE=$(tput setab 5)
BG_CYAN=$(tput setab 6)
BG_WHITE=$(tput setab 7)
#foreground colors
FG_RED=$(tput setaf 1)
FG_GREEN=$(tput setaf 2)
FG_YELLOW=$(tput setaf 3)
FG_BLUE=$(tput setaf 4)
FG_PURPLE=$(tput setaf 5)
FG_CYAN=$(tput setaf 6)
FG_WHITE=$(tput setaf 7)
#text-decoration
FG_BOLD=$(tput bold)
FG_HB=$(tput dim)
FG_UN=$(tput smul)
FG_REVERSE=$(tput rev)
#back to defaults
NORM=$(tput sgr0)
fi
#functions to display progress
dots () {
if [ "$interactive" != 'no' ]; then
while true; do
echo -n "."; sleep 0.5
done
fi
}
estart(){
if [ "$interactive" != 'no' ]; then
echo -n "$1"
dots &
dots_pid=$!
fi
}
efinish(){
estatus=$?
if [ "$interactive" != 'no' ]; then
if [ "$estatus" -eq 0 ];then
echo "[ ${FG_GREEN}OK${NORM} ]"
else
echo "[ ${FG_RED}FAIL${NORM} ]"
fi
kill $dots_pid
wait $dots_pid 2>/dev/null
fi
}
#detect server uptime
server_uptime () {
uptime=$(</proc/uptime)
uptime=${uptime%%.*}
s=$(( uptime%60 ))
m=$(( uptime/60%60 ))
h=$(( uptime/60/60%24 ))
d=$(( uptime/60/60/24 ))
uptime=$d'd '$h'h '$m'm '$s's '
curtime=$(date +'%Y-%m-%d %H:%M:%S')
}
#detect cifs mount
mnt_detect () {
MNT=$(mount -l | grep $mnt_dir)
if [ ! -z "$MNT" ]; then
MNT=$FG_GREEN$MNT$NORM
else
MNT=$FG_RED"error(not found)"$NORM
fi
}
#!/bin/sh
SCRIPT_DIR=`dirname $0`
source $SCRIPT_DIR/utils.sh
clear
echo "========================================="
echo " Mounted folder configuration"
echo " (/var/www)"
echo "========================================="
echo
old_address=$(cat /root/file_server)
old_username=$(grep 'username=' /root/.cifscreds | awk -F '=' '{ print $2 }')
old_password=$(grep 'password=' /root/.cifscreds | awk -F '=' '{ print $2 }')
echo "Type new value and press ENTER or just press ENTER to leave current value.";
echo ;
read -p "Address of fileserver, type like //ip/folder (current value $FG_YELLOW$old_address$NORM): " address ;
read -p "Username (current value $FG_YELLOW$old_username$NORM): " username ;
read -p "Password (current value $FG_YELLOW$old_password$NORM): " password ;
if [ -z "$address" ]; then
address=$old_address; fi
if [ -z "$username" ]; then
username=$old_username; fi
if [ -z "$password" ]; then
password=$old_password; fi
echo "======================================="
echo " New parameters"
echo "======================================="
echo -e "IP address of fileserver: "$address
echo -e "Username: "$username
echo -e "Password: "$password
echo "======================================="
echo
read -p "Save changes? (y/N) " key ;
if [ $key == "Y" -o $key == "y" ]; then
echo "username=$username
password=$password" > /root/.cifscreds
echo "$address" > /root/file_server
estart "Unmounting..."
umount /var/www
efinish
estart "Mounting..."
/root/cifs_mount.sh
efinish
echo ;
read -p "Done. Press any key" key ;
else
echo ;
read -p "Nothing was changed. Press any key" key ;
fi
Система контроля версий
Дальше остается настроить любимую систему контроля версий. Можно пользоваться desktop-приложением для Windows, можно работать через командную строку в putty прямо на нашей виртуальной машине. Кому, как удобнее.
PS. Кстати, одно из величайших открытий для меня было, что можно поставить git или svn непосредственно на production сервере. Когда я в свое время это понял, это ощущение было сравнимо, наверное, с тем чувством, которое испытал Архимед, когда сел в ванную. Ведь больше не надо мучиться с синхронизацией файлов по ftp\sftp, достаточно ввести svn up или git pull origin master!
Комментарии (86)
NeoCode
05.05.2016 20:40+1Для обычной разработки есть нормальные готовые решения под Windows, давно уже ушедшие вперед по сравнению с денвером.
Пожалуй самое лучшее из того что я знаю — OpenServer. Еще очень неплох AppServ, я его даже использовал в реальном проекте, где нужен был локальный web-сервер в сетке из десятка windows-машин.
Ну а для окончательного тестирования в продакшене все равно придется на реальный хостинг закачивать:)
funnybanana
06.05.2016 07:24есть ещё Vertrigo (куда уж лучше денвера будет), сам им пользовался до того как перенес всю разработку на ноут с установленной ubuntu.
istui
06.05.2016 11:39+1Еще есть вариант не полениться и собрать сервер самому. Когда-то так перешел с денвера, в итоге — если грамотно все сделать — получаем значительный рост скорости по сравнению с денвером. Плюс конфигурация максимально приближена к той, что используется на продакшене.
iSage
05.05.2016 20:47+6>скриптик
https://www.ansible.com/
gnemtsov
05.05.2016 22:09-3Не совсем понял, для чего вы привели ansible. Речь в статье вроде бы совершенно не об этом. А о том, как построить окружение на локальном компьютере разработчика.
Проекты в production у нас работают или на одном сервере, или если серверов несколько, в Amazon Beanstalk, который берет управление развертыванием на себя.iSage
05.05.2016 22:12+1Очевидно для того, чтобы «построить окружение на локальном компьютере разработчика» (а по факту, в виртуалке, запущеной на компьютере разработчика).
misato
05.05.2016 20:59-3Самый хороший вариант — удалённый сервер разработки, где все настроено максимально близко к продакшену.
А на локальных компах огород городить — это как-то несовременно.
alexkunin
05.05.2016 21:10+3А как же по боксу каждому девелоперу? Вася поломал админку и ушел в отпуск — вся команда или курит, или чинит. Плюс удаленный сервер дает задержку (загрузка на сервер отдельных файлов или результата билда, обновление, очистка кеша или форсированное обновление), и каждая ее секунда в edit-run-fix выливается сначала в минуты, а потом — при увеличении сложности проекта — в десятки минут ожидания каждый день.
Лучше вагрант-докер какой-нибудь. Только первые десять сред трудно, потом все эти docker-compose.yml как от зубов отскакивают.misato
06.05.2016 07:09-1Каждому по песочнице, а что такого? Это же не квартиру подарить, не так уж и дорого стоит. Про первые десять сред в докере посмеялся :)
lair
06.05.2016 11:07+2Каждому по песочнице, а что такого?
А то, что тогда дешевле эти песочницы держать на разработческом компе — и с точки зрения ресурсов, и с точки зрения доступности, и с точки зрения скорости работы.
misato
06.05.2016 12:24Чем же дешевле?
Каждый разработчик должен тратить время на настройку всей инфраструктуры, тогда как на сервере разработки всё можно сделать централизовано: быстро и правильно, силами самого квалифицированного в администрировании инженера. Особенно актуально, например, если в проекте есть какая-то непривычная инфраструктура. Ты либо отправляешь разработчика целый день возиться с настройкой и запуском того, с чем он раньше не имел дела, либо копируешь ему ещё одну песочницу и ставишь боевые задачи.
И не забываем, что всё-таки так мы избавляемся от возможных эффектов несовместимости в реализации технологий под разные платформы, которые всё-таки есть.
Есть ещё отличный эффект — тонкий клиент проще настраивать. Разработчик поставил путти, какой-то IDE и побежал работать. Купил новый ноут, установил ось и через полчаса снова работает в привычном окружении с любыми своими проектами. Сломался ноут — временно взял другой и снова может работать.
Так что здесь отнюдь не так очевидно, что выходит дешевле.
mpakep
06.05.2016 12:33+1Тут вопрос привычки и личных ценностей. Кто-то ценит время потраченное на настройку инфраструктуры, а кто то личную свободу и независисмость. Для каждого свое решение.
lair
06.05.2016 13:23+1Чем же дешевле?
А давайте мы сначала определимся, что с чем мы сравниваем. У вас, внезапно, разработческий сервер эквивалентен тонким клиентам, хотя это не одно и то же. Если вы хотите пообсуждать, удобно ли разработчику работать на тонком клиенте — то так и напишите; я же пока буду обсуждать то, что я изначально имел в виду: ситуацию, когда разработчик ведет разработку локально (т.е., исходники и IDE стоят на его компьютере), а вот разворачивает он это для проверки — куда-то еще.
Каждый разработчик должен тратить время на настройку всей инфраструктуры, тогда как на сервере разработки всё можно сделать централизовано: быстро и правильно, силами самого квалифицированного в администрировании инженера.
Если у вас сервер разработки один, то у вас будут проблемы из-за взаимного влияния разработчиков. Если же у вас каждому разработчику выдается свой "сервер разработки", то нет никакой разницы, порождаются они централизованно, или локально — все равно они разворачиваются из шаблона или скриптом, и человек в этом участвует минимально.
Ты либо отправляешь разработчика целый день возиться с настройкой и запуском того, с чем он раньше не имел дела, либо копируешь ему ещё одну песочницу и ставишь боевые задачи.
Что мешает скопировать песочницу на рабочий компьютер разработчика?
И не забываем, что всё-таки так мы избавляемся от возможных эффектов несовместимости в реализации технологий под разные платформы, которые всё-таки есть.
… это если у вас строго одна целевая платформа в продакшне. Как только это меняется (их становится больше), ваша задача — не избавится от эффектов несовместимости, а поймать их как можно раньше.
Так вот, мы уже выяснили, что у каждого разработчика есть своя "песочница" (не важно, виртуалка, контейнер), стоимость развертывания которой, выраженная в человеческих силах, пренебрежима и не отличается между централизованным развертыванием и локальным. А дальше все сводится к банальной задаче нахождения компромиса, где с одной стороны — удобство разработчика (чем ближе к нему песочница, тем быстрее у него будет проходить цикл внесения изменений и тем меньше он зависит от централизованной инфраструктуры) и уменьшение стоимости владения (не надо иметь мощную централизованную инфраструктуру для развертывания множества песочниц), а с другой стороны — увеличение нагрузки на локальный компьютер разработчика (и, таким образом, увеличение расходов на каждый такой компьютер).
misato
06.05.2016 13:39Нет, слова «тонкий клиент» были не в самом буквальном смысле. Под тонким клиентом я как раз подразумеваю, что у разработчика на компе установлен IDE для разработки, терминал и по желанию какой-то GUI для баз данных, без каких-либо серверов. Рабочая копия проекта, рабочая копия базы и прочее такое — все это лежит на сервере/серверах разработки. Работа, таким образом, включая редактирование файлов, ведётся через интернет.
Плюсы, как я их вижу, я уже описывал. Забыл только упомянуть о том, что благодаря такому решению вся работа доступна в любой момент для демонстрации или для быстрой консультации с коллегами. Недостатки я тоже понимаю — есть некоторые неудобства связанные с не мгновенным сохранением файла, и с тем, что многие популярные IDE не умеют работать с удалёнными файлами через нормальные протоколы.
Если вы всё сделаете в кроссплатформенных контейнерах, которые неважно где раскладывать — это отлично, почти все плюсы удалённого сервера будут соблюдены, кроме возможности мгновенной демонстрации. Ну и требования к локальной инфраструктуре разработчика всё равно будут выше — надо будет развернуть весь этот зоопарк с докерами и вагрантами. (Я понимаю, с определённого уровня квалификации кажется, что это естественно, нормально и просто, но дать всё это стажёру или джуниору — и он наверняка потеряет день-другой, и будет терять его всякий раз, когда дашь ему проект.)
Если же вы работаете стабильным-квалифицированным составом над одним большим проектом, то вполне допускаю, что плюсы удалённого сервера разработки могут потерять актуальность.oxidmod
06.05.2016 13:55>> Недостатки я тоже понимаю — есть некоторые неудобства связанные с не мгновенным сохранением файла
у меня файлик успевает залиться пока я альтабаюсь в браузер и жму ф5 Оо
lair
06.05.2016 13:55Рабочая копия проекта, рабочая копия базы и прочее такое — все это лежит на сервере/серверах разработки. Работа, таким образом, включая редактирование файлов, ведётся через интернет.
Прежде чем обсуждать что-либо далее, давайте уточним: что такое "рабочая копия проекта"? Та, над которой ведется работа? Или стабильная?
misato
06.05.2016 14:09Рабочая копия — это та, в которой ведётся работа. В соответствии с терминологией VCS.
lair
06.05.2016 14:10То есть вы — совершенно серьезно — предлагаете разработчику работать не с локальной файловой системой, а с произвольно удаленной?
misato
06.05.2016 14:27Я сам так и работаю. А что такого?
lair
06.05.2016 14:40+2Окей, тезис понятен.
Во-первых, "что такого". Знаете, мы тут (уже давно, правда) перешли с HDD на SSD для исходников — и это дало ощутимый прирост в комфорте работы. А вы предлагаете унести файлы за удаленное (и негарантированное) соединение — тем самым радикально понизив тот самый комфорт. А если я в самолете хочу поработать? В поезде? Ну или хотя бы в кафе?
Во-вторых, просто представьте себе, что изменения файла в файловой системе недостаточно для запуска приложения. Ну знаете, не все работают в директории веб-сервера, да и бывает такая ересь как компилируемые языки. Теперь после сохранения нужно еще запустить процесс запуска — в лучшем случае сразу на удаленном сервере на этот же сервер, в среднем — забрав обратно исходники и запустив локально, и в худшем — забрав исходники, собрав результат, и положив его обратно на удаленный сервер.
Во-третьих, вернемся к вашим тезисам из коммента повыше.
Забыл только упомянуть о том, что благодаря такому решению вся работа доступна в любой момент для демонстрации или для быстрой консультации с коллегами.
Если у вас есть стабильный сценарий развертывания любой версии из версионника — а он должен быть — то у вас и так вся работа доступна.
Ну и требования к локальной инфраструктуре разработчика всё равно будут выше — надо будет развернуть весь этот зоопарк с докерами и вагрантами. (Я понимаю, с определённого уровня квалификации кажется, что это естественно, нормально и просто, но дать всё это стажёру или джуниору — и он наверняка потеряет день-другой, и будет терять его всякий раз, когда дашь ему проект.)
Не всякий раз, а первый раз. А потом научится. А если не давать, то не научится никогда. И да, это тоже автоматизируется.
misato
06.05.2016 14:55А что если я хочу с другого ноута поработать? Или с компа своей жены? По-моему, аргументы не хуже ваших — такая же странная ситуация.
Что касается компилируемых языков. Вообще изначально обсуждение идёт о lamp-стеке, но даже если уйти от этого, если честно, то я не вижу разницы с тем случаем, когда все файлы лежат локально. Какая разница, где запускать компиляцию — здесь или там?
Развёртывание любой версии из VCS — не решает задачу быстрой демонстрации. Слишком много хлопот для короткого обсуждения — быстренько отгрузить на какой-то показной сервер (который, получается, должен быть готов к этому в плане прочей инфраструктуры, и не должен быть занят никаким другим показом и т.д.)
Научится — это конечно хорошо. Только у вас получается, что нижняя граница даже самой простой работы поднимается до уровня владения нетривиальными инструментами. Это удорожание разработки в чистом виде.lair
06.05.2016 15:01+1А что если я хочу с другого ноута поработать? Или с компа своей жены?
То вам ничто не поможет, кроме тонкого клиента.
И нет, в этой ситуации нет ничего странного: я регулярно работал в кафе, я много раз видел людей, работающих в поезде, и даже в самолете — встречал (хотя, будем честными, в самолете без интернета вообще я бы работать не стал). И таких людей намного больше, чем людей, которые хотят поработать с ноута своей жены.
Что касается компилируемых языков. Вообще изначально обсуждение идёт о lamp-стеке, но даже если уйти от этого, если честно, то я не вижу разницы с тем случаем, когда все файлы лежат локально. Какая разница, где запускать компиляцию — здесь или там?
Принципиальная: вам нужно сначала дотащить "туда" команду на исполнение, а потом "обратно" — результат ее выполнения. Это все увеличивает накладные расходы (и, заодно, сложность ПО).
Развёртывание любой версии из VCS — не решает задачу быстрой демонстрации. Слишком много хлопот для короткого обсуждения
Задачу "короткого обсуждения" уже давно успешно решает "подойди посмотреть", если в офисе, и "пошарить скрин в скайпе", если удаленно.
Научится — это конечно хорошо. Только у вас получается, что нижняя граница даже самой простой работы поднимается до уровня владения нетривиальными инструментами. Это удорожание разработки в чистом виде.
Неа. Для "самой простой работы" вообще не нужен ни вагрант, ни докер — ничего. Просто поставьте инструментарий локально. Изолированные среды нужны тогда, когда сложность работы растет — а вместе с ней растут и требования к уровню разработчика.
И да, вы сейчас звучите так же, как дцать лет назад звучали люди, которые говорили, что VCS — нетривиальный инструмент, и они не хотят учиться им пользоваться.
misato
06.05.2016 15:19Нет, я не то чтобы не хочу учиться. В определённых условиях я просто не вижу никакой выгоды.
Взять вот ребят из начала поста. У них там, судя по всему, веб-проекты на битриксе, а это короткие по времени и объему работы проекты, более-менее типовые, и что греха таить, скучные для большинства разработчиков. Но это ниша и кому-то надо делать простые сайты, в которых нет смысла разносить микросервисы по контейнерам и обучать вагранту вчерашних студентов, с годом опыта работы на пхп.
Всему своё место, в общем.lair
06.05.2016 15:20+1Повторюсь, в этой нише нет смысла и вообще заморачиваться песочницами и выделенными рабочими окружениями.
oxidmod
06.05.2016 17:52компилируемые языки отдельная штука. но имхо, проще взять один очень мощный серв который будет компилить исходники скажем 15 минут и заморочится софтом для деплоя, чем каждому разрабу дать машину, которая будет компилить эти же исходники хотябы час.
в случае с вебом есть еще такая штука как кеши, менеджеры очередей, воркеры. чтобы локально поднять рабочую копию приложения нужно будет локально развернуть все бд с какимито тестовыми данными. Поднять всякие еластики, редисы, монги и прочие кролики. запустить все воркеры и кроны.
вот сейчас ТЕСТОВЫЕ бд на серверах разработки весят гдето пол терабайта у меня. а под еластик выделен отдельный небольшой кластерок. вы предлагаете это все добро поднимать локально каждому разработчику, за сомнительное удовольствие работать без сетевых задержек? на какой машине оно хотябы все поднимется?lair
06.05.2016 17:57компилируемые языки отдельная штука. но имхо, проще взять один очень мощный серв который будет компилить исходники скажем 15 минут и заморочится софтом для деплоя, чем каждому разрабу дать машину, которая будет компилить эти же исходники хотябы час.
С одной стороны да… а с другой — представьте, что у вас пять разработчиков, каждый закоммитил свой код, и каждый хочет посмотреть результат.
в случае с вебом есть еще такая штука как кеши, менеджеры очередей, воркеры. чтобы локально поднять рабочую копию приложения нужно будет локально развернуть все бд с какимито тестовыми данными. Поднять всякие еластики, редисы, монги и прочие кролики. запустить все воркеры и кроны.
Не совсем так. Во-первых, в ряде случаев можно банально упрощать и выкидывать (например, если приложение умеет работать на кластере, то это не означает, что надо локально кластер поднимать). А во-вторых, я не говорю, что все компоненты должны быть локальными — если мы зависим от чего-то тяжелого, то его придется шарить (и получать все побочные негативные эффекты этого шаринга).
oxidmod
06.05.2016 18:08>> представьте, что у вас пять разработчиков, каждый закоммитил свой код, и каждый хочет посмотреть результат.
вероятность того, что это событие произойдет одновременно — крайне мала. но всеже, я не зря написал про «софт для деплоя». Вполне можно сделать так, чтобы сервер ставил в очередь сортируя по приоритету тасок в баг трекере и на почту слал линку на бинарник по завершению. Вы же программисты. сделайте как удобно.
>> Не совсем так. Во-первых, в ряде случаев можно банально упрощать и выкидывать (например, если приложение умеет работать на кластере, то это не означает, что надо локально кластер поднимать).
безусловно, все что обязательно запущено. то что опционально запускается по факту необходимости. Если локально у вас не все, а только то что обязательно (даже в этом случае на нашем проекте я не представляю есть ли ноут, который все это вытянет), то всеравно возникнет ситуация, когда вам нужно чтото опциональное, которое на удаленном сервера, а доступа к сети нет.lair
06.05.2016 18:17вероятность того, что это событие произойдет одновременно — крайне мала.
Я вот это вижу несколько раз в день.
Вполне можно сделать так, чтобы сервер ставил в очередь сортируя по приоритету тасок в баг трекере и на почту слал линку на бинарник по завершению.
… вот только ждать придется дольше, чем если бы я собирал локально. И чем больше у вас программистов, тем сильнее это будет видно.
Впрочем, это, опять, вопрос баланса. Где-то выгоднее собирать централизованно, где-то выгоднее собирать локально.
Если локально у вас не все, а только то что обязательно
"Обязательно" в моем понимании только исходники. А дальше — от сложности проекта и скорости цикла, которую я хочу иметь.
oxidmod
10.05.2016 11:43+1>> … вот только ждать придется дольше, чем если бы я собирал локально. И чем больше у вас программистов, тем сильнее это будет видно.
бывают проекты, которые на типичном ноуте для разработки собираться будут часами. я же написал, что выгодней и дешевле куить один мощный сервер для всех, чем каждому дать чтото соизмеримое. Естественно если ваш проект собирается за минуту другую, то можно и локально собрать, но бывают проекты гораздо сложней.
>> «Обязательно» в моем понимании только исходники. А дальше — от сложности проекта и скорости цикла, которую я хочу иметь.
так тогда вы теряете тот единственный плюс о котором говорилось выше. Возможность работать без сети и в любое время когда нужно. Если у вас только исходники, но чтобы посмотреть на работу программы нужно обязательно подключиться к сети/ докачать, доустановить etc, то какой профит таскать на своем ноуте исходники проекта?lair
10.05.2016 11:46бывают проекты, которые на типичном ноуте для разработки собираться будут часами
Вы все увеличиваете и увеличиваете время...
так тогда вы теряете тот единственный плюс о котором говорилось выше.
Не единственный. Еще как минимум банальная скорость навигации.
Если у вас только исходники, но чтобы посмотреть на работу программы нужно обязательно подключиться к сети/ докачать, доустановить etc, то какой профит таскать на своем ноуте исходники проекта?
(а) возможность в любой момент посмотреть код (чтобы принять решение/подумать/ответить на вопрос)
(б) скорость работы в IDE
А главное — по моим представлениям, проектов, которые действительно нельзя запустить локально, не так уж и много (в процентном представлении), так что я бы не стал на них полагаться при построении общей парадигмы. Их надо учитывать, но не надо брать за норму.
oxidmod
10.05.2016 12:19преимущества а и б какбы никуда не деваются в моем варианте.
у вас все также локально есть репо с исходниками. но это только что исходники, которые можно, но не обязательно собирать локально. а в случае веба, о котором идет речь в статье, исполняться эти исходники будут на удаленом сервере, который максимально соотвествует продакшену
о какой скорости навигации идет речь? если по исходникам, то уже ответилlair
10.05.2016 12:19у вас все также локально есть репо с исходниками.
Тогда я не понимаю, что такое "ваш вариант", и чем он отличается от "моего".
oxidmod
10.05.2016 12:37тобишь вы комментировали абы комментировать, не глядя что написано? по какой причине у вас возникло желание оставить коммент к моему?
зы. если по делу. изначально речь шла о том, чтобы локально поднимать веб-окружение на машине каждого разработчика. А приверженцы данного подхода аргументировали его полезность тем, что можно иметь под рукой в любом месте, независимо от наличия доступа в сеть рабочую копию проекта, чтобы показать заказчику или просто поработать. А я написал, что как по мне, то лучше иметь сервер разработки с поднятыми необходимыми сервисами, а не разворачивать их на каждой машине, потому что:
а) каждому разработчкиу не нужно настраивать кучу вещей руками
б) не нужно каждому разработчику ставить мощную тачку, чтобы локально держать весь зоопарк (на примере моего текущего проекта, который локально ну никак не развернуть)
ну а потом набросили что не вебом единым, и есть еще компилируемые языки. и тут я добавил, что с компилируемыми немного по другому, но даже в случае таких языков, если для полноценной работы приложения нужно чтото еще, кроме как скомпилировать исходники, то централизированно будет еффективней, хотябы потому, что можно иметь один мощный сервер, который будет компилировать быстрей чем локальные тачки разработчиков.
да, я соглашусь, что в случае не слишком больших и сложных проектов вполне можно собирать исходники локально. Но всеже, иметь сервер «для деплоя» и софт который этот деплой исполняет мне кажется более еффективно. по крайней мере исключите человеческий фактор, что забыли/забили тесты прогнать после фикса, забыли/забили отключить какуюто дев-фичу и на прод окружении вылезет косяк. Единожды настроенный процес автоматического деплоя решит подобные пробелмы раз и навсегда.lair
10.05.2016 12:51А приверженцы данного подхода
Лично я приверженец того (простого, в общем-то) подхода, что чем больше можно поднять локально — тем лучше. Абсолютный минимум — локально лежащие исходники. Дальше — локальная сборка, локальный запуск, локальная БД, и вплоть до локальных сервисов.
Но всеже, иметь сервер «для деплоя» и софт который этот деплой исполняет мне кажется более еффективно.
А это не взаимоисключающие вещи. Можно иметь локальное окружение и сервер для деплоя (первое тестовое окружение и далее).
funnybanana
14.05.2016 11:52Вполне сносное решение, я как раз так и работаю.
IDE на одном ПК, сам проект на другом ПК, монтирую директорию с проектом как диск по ssh, чтение и запись без задержки… работать можно из любого места, демонстрировать проект тоже можно где угодно…
в общем то плюсов достаточно…lair
14.05.2016 13:59+2работать можно из любого места
Из любого, или все-таки из любого, где есть адекватный интернет?
(про "без задержки" я даже говорить не буду, тут все упирается в количество файлов, с которыми вам надо иметь дело одновременно)
NeoCode
05.05.2016 21:10Вообще правильно написанный код должен работать одинаково правильно и на локальных windows-машинах, и на реальном сервере. Так что локальная разработка — дополнительный способ проверить правильность кода (хотя конечно должна быть и постоянная проверка на реальном или максимально приближенном к реальному сервере).
Это как код на С++ собирать разными компиляторами: те баги что не видит msvc, видит gcc и наоборот.olku
05.05.2016 21:32+1Неа. dll не so, и окружение разное. А термин «правильно написанный код» еще дефинировать надо. Еще тут предлагается сразу в продакшен его, чтоб не мучался… проверим, ага :)
NeoCode
05.05.2016 21:37Ну вот правильный код ИМХО должен быть абстрагирован от конкретных расширений «dll» и «so», а оперировать просто понятиями «динамически загружаемый двоичный модуль». Это как с абсолютными путями, которые начинающие разработчики впихивают в код, а потом удивляются, чего их код на других машинах не собирается или не работает :)
misato
06.05.2016 07:16Ну в теории-то, если мы про чистый сферический код в вакууме говорим, то всё правильно.
На практике чаще надо ехать, а не чтобы шашечки. Поэтому какие-то фичи в проекте могут быть зависимыми от среды — это раз, какие-то баги могут просто не отлавливаться на другой среде (например, опечатки с регистром в названиях файлов под виндой).
И дальше-больше. Если в проекте есть какие-то интеграции и зависимости с различными внешними службами и сервисами, то гораздо проще и правильнее поддерживать доступ к ним с одного сервера разработки, чем открывать для бесконечного количества рабочих машин по всему миру. Там и другие нюансы могут быть, например большой объем данных, передаваемый к/от внешней службы, или нужна скорость.lair
06.05.2016 11:10Если в проекте есть какие-то интеграции и зависимости с различными внешними службами и сервисами, то гораздо проще и правильнее поддерживать доступ к ним с одного сервера разработки, чем открывать для бесконечного количества рабочих машин по всему миру.
Вы же в разработке наверное используете не боевые службы и сервисы, а тестовые? Будем честными, в половине случаев никаких проблем с доступом нет вообще (если это, скажем, публичный SaaS), во оставшейся четверти — это внутренний сервис компании, и при правильно организованной сети это тоже не проблема, в оставшейся восьмой части можно написать прокси (мы, кстати, так и сделали один раз, заодно и отладку себе радикально упростили), и только в оставшейся восьмой части надо хоть как-то об этом думать.
gnemtsov
05.05.2016 22:11+1Я думал на тему удаленного сервера. Не нравится, что все разработчики будут зависеть от его функционирования. Мне ближе идеология git, когда у каждого разработчика своя независимая инфраструктура для разработки.
misato
06.05.2016 08:43-1Каждому надо настроить всю инфраструктуру проекта. Если речь о простых сайтиках, то может быть и нормально. А когда есть что-то нестандартное — это серьёзное неудобство и поле для потенциальных ошибок.
lair
05.05.2016 21:11+4Кстати, одно из величайших открытий для меня было, что можно поставить git или svn непосредственно на production сервере.
Зачем?
Ведь больше не надо мучиться с синхронизацией файлов по ftp\sftp, достаточно ввести svn up или git pull origin master!
И для кого только системы автоматизированного развертывания пишут...
andrewnester
06.05.2016 09:45+1на собственных проектиках есть постоянно deploy.sh, который делает git pull, перезагружает php-fpm и ещё что-нибудь. Работаю и не обламываюсь :) а настраивать CD на маленьких проектах как мне кажется это лишний геморрой
lair
06.05.2016 11:06Работаю и не обламываюсь
А кто-то без версионника работает и не обламывается.
А кто-то прямо на продуктиве правит и не обламывается.
а настраивать CD на маленьких проектах как мне кажется это лишний геморрой
Ну да, писать собственный deploy.sh — конечно, меньший геморрой, чем взять готовое решение с тремя настроечными полями.
Но вообще, конечно, идея "давайте сделаем git pull" выглядит хорошей… пока вы выполняете несколько условий:
- содержимое версионника не требует обработки перед выкладкой (например, компиляции)
- все нужное для выкладки лежит в версионнике (бинарные зависимости, например, тоже)
- вы обновляете только одну точку развертывания (например, вам не надо обновлять БД вместе с сайтом)
- вам не нужно управлять конфигурацией продуктива
(и даже в этом случае могут быть проблемы класса "а как обеспечить бесперебойность работы во время обновления" и "как сделать так, чтобы на продуктив не утекло ничего опасного с точки зрения безопасности")
Но если вам надо забрать зависимости, скомпилировать бинарник, выложить его на продуктив, сконфигурить там очередь, мигрировать БД — и все это проделать на ферме, — то поддержка deploy.sh становится непозволительно дорогой.
PS а вы для каждого ландшафта свой deploy.sh пишете? а храните вы их где?
andrewnester
06.05.2016 21:05повторюсь, делаю это для своих проектов, они маленькие, на одном сервере в основном
языки в основном php, python, так что компиляция не нужна
в плане БД есть миграции, которые можно тоже запустить в deploy.sh
зависимости тянуться с помощью composer install для php, в git лежит composer.lock, так что версии зафиксированы и если ничего не изменилось то и ничего не устанавливается
как говорил, фермы серверов нет, для обновления и очистки кэша через скрипт обновляется fpm
Ну а на рабочих сложных проектах конечно CD естьlair
06.05.2016 22:42повторюсь, делаю это для своих проектов, они маленькие
Проблема в том, что этот опыт не масштабируется. Более того, он вырабатывает плохие привычки.
hudson
05.05.2016 21:43+4> Подождите, а чем плох денвер?
Сам по себе наверное ничем. Но сейчас есть Vagrant и Docker. С нативной поддержкой в IDE. Так что «король» давно умер, и после уже сменилось не одно поколение королей.
rozboris
05.05.2016 23:44+5Мне очень нравятся такие обобщения:
… правда жизни такова, что большинство разработчиков пользуются Windows в качестве основной OC на компьютере.
Miraage
06.05.2016 00:02+2В свое время ДНВР был очень хорош — спасибо, Дмитрий Котеров.
Однако время летит, появляются новые технологии, новые инструменты — и Вы, разработчик, должны идти в ногу со временем.
alexhemp
06.05.2016 00:17+1Деплой из git-а в принципе еще можно как-то понять, ну там деплой-скрипт запускать на push в релиз-ветк, в элементарных случаях это вполне может быть даже git pull.
Но samba на сервер разработки? Откройте для себя realsync того-же Дмитрия Котерова.gnemtsov
06.05.2016 19:06Устанавливать дополнительную утилиту, которая будет постоянно синхронизировать изменения в фоновом режиме… Явно ненужное усложнение. Шара и так прекрасно монтируется и устойчиво работает, как будто на сервере разработки локальный диск. Тут нет проблем с сетевым соединением, т.к. все происходит на одном и том же компьютере. Сервер samba ставить не нужно, в качестве сервера выступает Windows-машина. На сервере разработки нужен только mount.cifs, который может даже устанавливать не надо (не помню, кажется, входит в стандартный дистрибутив CentOS).
L0NGMAN
06.05.2016 00:50+2В почему не настрайвать на апаче динамичные виртуал хосты? Очен удобно: https://github.com/akalongman/ubuntu-configuration/blob/15.10/README.md#apache-configure-dynamic-virtualhosts
gnemtsov
06.05.2016 18:42Да, динамические хосты похоже тут будут лучше — хорошее замечание. Не уверен, можно ли в динамических хостах делать специфические настройки под разные папки, но думаю, это решаемо…
L0NGMAN
06.05.2016 19:49Да, с помошью .htaccess всё вазможно. К тому же, в линуксах даже .dev домены не нужно прописать в hosts, выходит просто создал папку проекта и всё, открываешь в браузер. Очен удобно
kloppspb
06.05.2016 01:51+1>правда жизни такова, что большинство разработчиков пользуются Windows в качестве основной OC на компьютере
Да ну :)
>И очевидное решение, которое мы нашли, было удивительно простым. В Windows-машине нужно завести отдельную папку, в которой будут лежать все наши проекты. Эту папку нужно расшарить для доступа по сети и примонтировать в корневую директорию, с которой работает Web-сервер.
IMHO, наикривейшее решение нашли… Не говоря уж том, что расшарить можно и средствами что VMWare, что VirtualBox, и незачем огород городить.
zenn
06.05.2016 07:38+1К сожалению, у вас действительно получилось решение уровня «костыли и велосипеды — разрабатываем как умеем». По факту уже несколько лет есть куда более гибкие и удобные решения: есть virtualbox и vmware, а для быстрой организации управляемых контейнеров есть vagrant и docker.
Вот вам пример поднятия «веб-сервера» в 3 команды: scotch box, кроме того для более «требовательных» есть puphpet и куча других готовых решений.gnemtsov
06.05.2016 18:57Я считаю, что все зависит от ситуации. Да, вы правы, решения с vagrant и docker безусловно лучше собственного велосипеда и мы на них перейдем. Это уже шаг в сторону масштабирования. Когда будет разрастаться команда, усложнятся конфигурации и будут разными для разных проектов. Пока мы реально не испытывали в этом необоходимости, т.к. состав команды постоянный, нас немного, конфигурация виртуалки примерно одна и та же для всех проектов. Вполне достаточно дать новому разработчку скопировать виртуалку и после несложных настроек он в строю.
zirf
06.05.2016 08:03-3Я малость офигеваю. Если это LAMP, то для LAMP куча PaaS существует с бэкджеком и фреймворками, настроенных 100 % от потребностей пляшите, git в помощь. Обкатать на халявных тарифах, а от то у них свои заморочки OpenShift явно тяготеет к JBoss, Heroku — к ROR. LAMP у всех есть, но иногда «чтобы был». Потом если ваш реальный продакшн — бэком имеет Percona (и ее бэкапер), а структура репликации — мама не горюй — как ни крути штучное решение. Просто у Вас велосипед, да колеса гнутые. Клиентский софт PaaS потребует от силы ruby или python поставить ( не изучать), ну саму его утилиту для работы с сервисами (не труднее AWS, потом вэб морда всегда есть). Но git является обязательным условием (заодно удобством, инструментом контроля версий и т д). Чем такие облака удобны — можно проимитиовать любой сервер от песочницы до продакшена. Некоторый запас наглости и умения позволяет первыми же халявами разместить систему управления проектами (у нас Redmine). А Denver — слово из прошлого — есть современные WAMP.
gvozd1989
06.05.2016 10:44Использую подход как у автора, за исключением того, что файлы загружаются по sftp при помощи IDE, так как с шарами есть проблемы со скоростью и правами доступа. Можете объяснить мне кто-нибудь, кто пользуется Vagrant, Docker и т.п. в чем их преимущество перед обычной виртуалкой, если работаю я один (нет команды с кем нужно делить конфигурацию)? И если я одновременно работаю над несколькими проектами, насколько быстро они запускаются, переключаются? Хостовая система Windows.
Fedcomp
06.05.2016 12:17Если docker, то преимущество в том что у вас будет идентичное окружение для разработки на локалке, и тоже самое окружение будет на продакшен сервере. Причем независимо от того какой там linux дистрибутив стоит (? по крайней мере независимо от centos/debian, другие не проверял).
Допустим вам нужна база данных postgresql. Вы просто берете готовый docker образ из его хаба, и юзаете туже самую базу данных для разработки локально и на продакшене. И окружение у этой базы будет точно такое же, то самое, что заложено в образ самого postgresql docker образа.
Грубо говоря вы строите контейнеры локально, и разворачиваете их же на продакшене с минимальным оверхедом (по сравнению с виртуалками).
Vagrant позволяет одному, допустим старшему разработчику написать Vagrantfile, а все остальные разработчики стянут его, и у всех будет одинаковая среда для разработки независимо на какой хостовой ОС они сидят. При желании можно даже собрать образ максимально приближенный к продакшену.
Что docker что vagrant позволяют вам писать код в среде приближенной к продакшену. Насколько приближенной вы можете решить сами, но как минимум и там и там linux например.gvozd1989
06.05.2016 13:29Спасибо, но я спрашивал применимо не к команде, а к одиночке. :) Например я делаю одному клиенту сайт на WordPress, другому магазин на OpenCart, для них не нужны хитрые конфиги, плюс в большинстве случае клиент использует шаред хостинг, зачастую без ssh. Как в таком случае удобно использовать виртуалку для разработки?
oxidmod
06.05.2016 14:00заводишь одну виртуалку с мускуль/веб сервер/пхп/редис/мемкеш и иже с ними
заводишь виртуальных хосты внутри виртуалкиgvozd1989
06.05.2016 15:21Так сейчас и есть, но автора же запинали, что это прошлый век.
Fedcomp
06.05.2016 19:21+1Потому что автор пишет велосипед. То что он разворачивает — быстро не сворачивается и много ручного труда, а еще очень много кривых вещей которые уже решены в нормальных инструментах (проброс фс)
MetaDone
06.05.2016 11:19+1if [[ $D == *"bitrix"* ]]
теперь все ясно )
по поводу flush_vhosts.sh — ересь, если мне понадобится проксировать веб-сокет на определенный порт в одном из виртуальных хостов, то после добавления еще одного мне все перетрет и придется делать заново, т.к. скрипт «Очищает конфигурацию виртуальных хостов.». Не лучше ли сделать чтоб хосты добавлялись, а не перетирались старые?gnemtsov
06.05.2016 18:46Выше предложили использовать динамические виртуальные хосты, может это самое правильное.
Перезаписываю, т.к. у нас не требуется каких-то особых настроек, веб-сокеты в проектах не используются. Какие-то мелкие настройки внести через .htaccess. Зато не остается мусора, если папку с проектом убрали или переименовали.
olku
VBoxLinuxAdditions из коробки
То есть, без версий продукта, тестов и миграции БД? Горячо любимая HHP методология :)
oxidmod
<< То есть, без версий продукта, тестов и миграции БД? Горячо любимая HHP методология :)
не гребите всех под одну гребенку. сам читаю, и волосы дыбом.
olku
Классика :) Статьи же не модерируются, чтобы молодежь плохому не учить. Как хоть компания и ERP называется, чтобы бояться?
Ch4r1k
«Лаборатория автоматизации бизнеса AB-LAB»
olku
Да прочитали мы профиль, прочитали… Акроним понравился, Business Automation Lab же.