Мой опыт настройки окружения для Web-разработки

    Речь пойдет не о настройке денвера и не о том, как поставить LAMP-стек. Я решил рассказать о том, какое мы в своей команде используем окружение для разработки. Мы разрабатываем Web-сервисы и ERP-системы, но всё это, в сущности, ничто иное, как сайты. Просто сложные внутри и порой не такие красивые снаружи.

    Сразу хочу сказать, что я не претендую на описание идеального окружения для 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


    В целом, это решение работает надежно, как утюг.

    Но тем не менее есть один небольшой нюанс.
    Иногда бывает, что при копировании больших файлов, вылетает ошибка cifs. Как правило, это связано с тем, что в Windows не хватает выделенной памяти для шары. Вылеты происходят из-за того, что Win7 настроена по умолчанию на экономию памяти для сетевых подключений, в частности, размер выделяемого для этих целей пула памяти ограничен, и если для обработки файла требуется больше, то Win7 шлет Linux фатальную ошибку интерфейса и CIFS падает.

    Также бывает наблюдаются периодические проблемы с неполной загрузкой страниц (не подгружаются 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”. На виртуалке перемонтировать шару.


    И еще один нюанс касается опции noserverino
    В свое время он породил этот мой вопрос на stackoverflow. Если кратко, эта опция нужна. Подробнее можно почитать по ссылке.


    Не стоит пугаться этих нюансов! Они накопились у нас почти за 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.

    menu.sh
    #!/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
    


    utils.sh - содержит функции и переменные, используемые в других скриптах
    #!/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
    }
    


    mount_cfg.sh - настройка параметров сетевой папки
    #!/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!

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 86

      +2
      скриптик cifs_mount.sh

      VBoxLinuxAdditions из коробки

      ввести svn up или git pull origin master

      То есть, без версий продукта, тестов и миграции БД? Горячо любимая HHP методология :)
        0
        << То есть, без версий продукта, тестов и миграции БД? Горячо любимая HHP методология :)
        не гребите всех под одну гребенку. сам читаю, и волосы дыбом.
          +3
          Классика :) Статьи же не модерируются, чтобы молодежь плохому не учить. Как хоть компания и ERP называется, чтобы бояться?
            0
            «Лаборатория автоматизации бизнеса AB-LAB»
              0
              Да прочитали мы профиль, прочитали… Акроним понравился, Business Automation Lab же.
        +1
        Для обычной разработки есть нормальные готовые решения под Windows, давно уже ушедшие вперед по сравнению с денвером.
        Пожалуй самое лучшее из того что я знаю — OpenServer. Еще очень неплох AppServ, я его даже использовал в реальном проекте, где нужен был локальный web-сервер в сетке из десятка windows-машин.
        Ну а для окончательного тестирования в продакшене все равно придется на реальный хостинг закачивать:)
          0
          есть ещё Vertrigo (куда уж лучше денвера будет), сам им пользовался до того как перенес всю разработку на ноут с установленной ubuntu.
            +1
            Еще есть вариант не полениться и собрать сервер самому. Когда-то так перешел с денвера, в итоге — если грамотно все сделать — получаем значительный рост скорости по сравнению с денвером. Плюс конфигурация максимально приближена к той, что используется на продакшене.

            +6
            >скриптик
            https://www.ansible.com/
              +10
              А для виртуалок — vagrant.
                –3
                Не совсем понял, для чего вы привели ansible. Речь в статье вроде бы совершенно не об этом. А о том, как построить окружение на локальном компьютере разработчика.

                Проекты в production у нас работают или на одном сервере, или если серверов несколько, в Amazon Beanstalk, который берет управление развертыванием на себя.
                  +1
                  Очевидно для того, чтобы «построить окружение на локальном компьютере разработчика» (а по факту, в виртуалке, запущеной на компьютере разработчика).
                –3
                Самый хороший вариант — удалённый сервер разработки, где все настроено максимально близко к продакшену.
                А на локальных компах огород городить — это как-то несовременно.
                • UFO just landed and posted this here
                    –1
                    Каждому по песочнице, а что такого? Это же не квартиру подарить, не так уж и дорого стоит. Про первые десять сред в докере посмеялся :)
                      +2
                      Каждому по песочнице, а что такого?

                      А то, что тогда дешевле эти песочницы держать на разработческом компе — и с точки зрения ресурсов, и с точки зрения доступности, и с точки зрения скорости работы.

                        0
                        Чем же дешевле?

                        Каждый разработчик должен тратить время на настройку всей инфраструктуры, тогда как на сервере разработки всё можно сделать централизовано: быстро и правильно, силами самого квалифицированного в администрировании инженера. Особенно актуально, например, если в проекте есть какая-то непривычная инфраструктура. Ты либо отправляешь разработчика целый день возиться с настройкой и запуском того, с чем он раньше не имел дела, либо копируешь ему ещё одну песочницу и ставишь боевые задачи.
                        И не забываем, что всё-таки так мы избавляемся от возможных эффектов несовместимости в реализации технологий под разные платформы, которые всё-таки есть.

                        Есть ещё отличный эффект — тонкий клиент проще настраивать. Разработчик поставил путти, какой-то IDE и побежал работать. Купил новый ноут, установил ось и через полчаса снова работает в привычном окружении с любыми своими проектами. Сломался ноут — временно взял другой и снова может работать.

                        Так что здесь отнюдь не так очевидно, что выходит дешевле.
                          +1
                          Тут вопрос привычки и личных ценностей. Кто-то ценит время потраченное на настройку инфраструктуры, а кто то личную свободу и независисмость. Для каждого свое решение.
                            +1
                            Чем же дешевле?

                            А давайте мы сначала определимся, что с чем мы сравниваем. У вас, внезапно, разработческий сервер эквивалентен тонким клиентам, хотя это не одно и то же. Если вы хотите пообсуждать, удобно ли разработчику работать на тонком клиенте — то так и напишите; я же пока буду обсуждать то, что я изначально имел в виду: ситуацию, когда разработчик ведет разработку локально (т.е., исходники и IDE стоят на его компьютере), а вот разворачивает он это для проверки — куда-то еще.


                            Каждый разработчик должен тратить время на настройку всей инфраструктуры, тогда как на сервере разработки всё можно сделать централизовано: быстро и правильно, силами самого квалифицированного в администрировании инженера.

                            Если у вас сервер разработки один, то у вас будут проблемы из-за взаимного влияния разработчиков. Если же у вас каждому разработчику выдается свой "сервер разработки", то нет никакой разницы, порождаются они централизованно, или локально — все равно они разворачиваются из шаблона или скриптом, и человек в этом участвует минимально.


                            Ты либо отправляешь разработчика целый день возиться с настройкой и запуском того, с чем он раньше не имел дела, либо копируешь ему ещё одну песочницу и ставишь боевые задачи.

                            Что мешает скопировать песочницу на рабочий компьютер разработчика?


                            И не забываем, что всё-таки так мы избавляемся от возможных эффектов несовместимости в реализации технологий под разные платформы, которые всё-таки есть.

                            … это если у вас строго одна целевая платформа в продакшне. Как только это меняется (их становится больше), ваша задача — не избавится от эффектов несовместимости, а поймать их как можно раньше.


                            Так вот, мы уже выяснили, что у каждого разработчика есть своя "песочница" (не важно, виртуалка, контейнер), стоимость развертывания которой, выраженная в человеческих силах, пренебрежима и не отличается между централизованным развертыванием и локальным. А дальше все сводится к банальной задаче нахождения компромиса, где с одной стороны — удобство разработчика (чем ближе к нему песочница, тем быстрее у него будет проходить цикл внесения изменений и тем меньше он зависит от централизованной инфраструктуры) и уменьшение стоимости владения (не надо иметь мощную централизованную инфраструктуру для развертывания множества песочниц), а с другой стороны — увеличение нагрузки на локальный компьютер разработчика (и, таким образом, увеличение расходов на каждый такой компьютер).

                              0
                              Нет, слова «тонкий клиент» были не в самом буквальном смысле. Под тонким клиентом я как раз подразумеваю, что у разработчика на компе установлен IDE для разработки, терминал и по желанию какой-то GUI для баз данных, без каких-либо серверов. Рабочая копия проекта, рабочая копия базы и прочее такое — все это лежит на сервере/серверах разработки. Работа, таким образом, включая редактирование файлов, ведётся через интернет.

                              Плюсы, как я их вижу, я уже описывал. Забыл только упомянуть о том, что благодаря такому решению вся работа доступна в любой момент для демонстрации или для быстрой консультации с коллегами. Недостатки я тоже понимаю — есть некоторые неудобства связанные с не мгновенным сохранением файла, и с тем, что многие популярные IDE не умеют работать с удалёнными файлами через нормальные протоколы.

                              Если вы всё сделаете в кроссплатформенных контейнерах, которые неважно где раскладывать — это отлично, почти все плюсы удалённого сервера будут соблюдены, кроме возможности мгновенной демонстрации. Ну и требования к локальной инфраструктуре разработчика всё равно будут выше — надо будет развернуть весь этот зоопарк с докерами и вагрантами. (Я понимаю, с определённого уровня квалификации кажется, что это естественно, нормально и просто, но дать всё это стажёру или джуниору — и он наверняка потеряет день-другой, и будет терять его всякий раз, когда дашь ему проект.)

                              Если же вы работаете стабильным-квалифицированным составом над одним большим проектом, то вполне допускаю, что плюсы удалённого сервера разработки могут потерять актуальность.
                                0
                                >> Недостатки я тоже понимаю — есть некоторые неудобства связанные с не мгновенным сохранением файла
                                у меня файлик успевает залиться пока я альтабаюсь в браузер и жму ф5 Оо
                                  0
                                  Рабочая копия проекта, рабочая копия базы и прочее такое — все это лежит на сервере/серверах разработки. Работа, таким образом, включая редактирование файлов, ведётся через интернет.

                                  Прежде чем обсуждать что-либо далее, давайте уточним: что такое "рабочая копия проекта"? Та, над которой ведется работа? Или стабильная?

                                    0
                                    Рабочая копия — это та, в которой ведётся работа. В соответствии с терминологией VCS.
                                      0

                                      То есть вы — совершенно серьезно — предлагаете разработчику работать не с локальной файловой системой, а с произвольно удаленной?

                                        0
                                        я думаю, что само репо локально. но иДЕха синкает поменявшиеся файлы по ctrl+S на удаленный сервер гда собственно и стоит вебсервер
                                          0
                                          Кажется, так делает, например, sublime с популярным плагином для работы over ssh.
                                          0
                                          Я сам так и работаю. А что такого?
                                            +2

                                            Окей, тезис понятен.


                                            Во-первых, "что такого". Знаете, мы тут (уже давно, правда) перешли с HDD на SSD для исходников — и это дало ощутимый прирост в комфорте работы. А вы предлагаете унести файлы за удаленное (и негарантированное) соединение — тем самым радикально понизив тот самый комфорт. А если я в самолете хочу поработать? В поезде? Ну или хотя бы в кафе?


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


                                            Во-третьих, вернемся к вашим тезисам из коммента повыше.


                                            Забыл только упомянуть о том, что благодаря такому решению вся работа доступна в любой момент для демонстрации или для быстрой консультации с коллегами.

                                            Если у вас есть стабильный сценарий развертывания любой версии из версионника — а он должен быть — то у вас и так вся работа доступна.


                                            Ну и требования к локальной инфраструктуре разработчика всё равно будут выше — надо будет развернуть весь этот зоопарк с докерами и вагрантами. (Я понимаю, с определённого уровня квалификации кажется, что это естественно, нормально и просто, но дать всё это стажёру или джуниору — и он наверняка потеряет день-другой, и будет терять его всякий раз, когда дашь ему проект.)

                                            Не всякий раз, а первый раз. А потом научится. А если не давать, то не научится никогда. И да, это тоже автоматизируется.

                                              0
                                              А что если я хочу с другого ноута поработать? Или с компа своей жены? По-моему, аргументы не хуже ваших — такая же странная ситуация.

                                              Что касается компилируемых языков. Вообще изначально обсуждение идёт о lamp-стеке, но даже если уйти от этого, если честно, то я не вижу разницы с тем случаем, когда все файлы лежат локально. Какая разница, где запускать компиляцию — здесь или там?

                                              Развёртывание любой версии из VCS — не решает задачу быстрой демонстрации. Слишком много хлопот для короткого обсуждения — быстренько отгрузить на какой-то показной сервер (который, получается, должен быть готов к этому в плане прочей инфраструктуры, и не должен быть занят никаким другим показом и т.д.)

                                              Научится — это конечно хорошо. Только у вас получается, что нижняя граница даже самой простой работы поднимается до уровня владения нетривиальными инструментами. Это удорожание разработки в чистом виде.
                                                +1
                                                А что если я хочу с другого ноута поработать? Или с компа своей жены?

                                                То вам ничто не поможет, кроме тонкого клиента.


                                                И нет, в этой ситуации нет ничего странного: я регулярно работал в кафе, я много раз видел людей, работающих в поезде, и даже в самолете — встречал (хотя, будем честными, в самолете без интернета вообще я бы работать не стал). И таких людей намного больше, чем людей, которые хотят поработать с ноута своей жены.


                                                Что касается компилируемых языков. Вообще изначально обсуждение идёт о lamp-стеке, но даже если уйти от этого, если честно, то я не вижу разницы с тем случаем, когда все файлы лежат локально. Какая разница, где запускать компиляцию — здесь или там?

                                                Принципиальная: вам нужно сначала дотащить "туда" команду на исполнение, а потом "обратно" — результат ее выполнения. Это все увеличивает накладные расходы (и, заодно, сложность ПО).


                                                Развёртывание любой версии из VCS — не решает задачу быстрой демонстрации. Слишком много хлопот для короткого обсуждения

                                                Задачу "короткого обсуждения" уже давно успешно решает "подойди посмотреть", если в офисе, и "пошарить скрин в скайпе", если удаленно.


                                                Научится — это конечно хорошо. Только у вас получается, что нижняя граница даже самой простой работы поднимается до уровня владения нетривиальными инструментами. Это удорожание разработки в чистом виде.

                                                Неа. Для "самой простой работы" вообще не нужен ни вагрант, ни докер — ничего. Просто поставьте инструментарий локально. Изолированные среды нужны тогда, когда сложность работы растет — а вместе с ней растут и требования к уровню разработчика.


                                                И да, вы сейчас звучите так же, как дцать лет назад звучали люди, которые говорили, что VCS — нетривиальный инструмент, и они не хотят учиться им пользоваться.

                                                  0
                                                  Нет, я не то чтобы не хочу учиться. В определённых условиях я просто не вижу никакой выгоды.
                                                  Взять вот ребят из начала поста. У них там, судя по всему, веб-проекты на битриксе, а это короткие по времени и объему работы проекты, более-менее типовые, и что греха таить, скучные для большинства разработчиков. Но это ниша и кому-то надо делать простые сайты, в которых нет смысла разносить микросервисы по контейнерам и обучать вагранту вчерашних студентов, с годом опыта работы на пхп.
                                                  Всему своё место, в общем.
                                                    +1

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

                                                0
                                                компилируемые языки отдельная штука. но имхо, проще взять один очень мощный серв который будет компилить исходники скажем 15 минут и заморочится софтом для деплоя, чем каждому разрабу дать машину, которая будет компилить эти же исходники хотябы час.

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

                                                вот сейчас ТЕСТОВЫЕ бд на серверах разработки весят гдето пол терабайта у меня. а под еластик выделен отдельный небольшой кластерок. вы предлагаете это все добро поднимать локально каждому разработчику, за сомнительное удовольствие работать без сетевых задержек? на какой машине оно хотябы все поднимется?
                                                  0
                                                  компилируемые языки отдельная штука. но имхо, проще взять один очень мощный серв который будет компилить исходники скажем 15 минут и заморочится софтом для деплоя, чем каждому разрабу дать машину, которая будет компилить эти же исходники хотябы час.

                                                  С одной стороны да… а с другой — представьте, что у вас пять разработчиков, каждый закоммитил свой код, и каждый хочет посмотреть результат.


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

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

                                                    0
                                                    >> представьте, что у вас пять разработчиков, каждый закоммитил свой код, и каждый хочет посмотреть результат.
                                                    вероятность того, что это событие произойдет одновременно — крайне мала. но всеже, я не зря написал про «софт для деплоя». Вполне можно сделать так, чтобы сервер ставил в очередь сортируя по приоритету тасок в баг трекере и на почту слал линку на бинарник по завершению. Вы же программисты. сделайте как удобно.

                                                    >> Не совсем так. Во-первых, в ряде случаев можно банально упрощать и выкидывать (например, если приложение умеет работать на кластере, то это не означает, что надо локально кластер поднимать).

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

                                                      Я вот это вижу несколько раз в день.


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

                                                      … вот только ждать придется дольше, чем если бы я собирал локально. И чем больше у вас программистов, тем сильнее это будет видно.


                                                      Впрочем, это, опять, вопрос баланса. Где-то выгоднее собирать централизованно, где-то выгоднее собирать локально.


                                                      Если локально у вас не все, а только то что обязательно

                                                      "Обязательно" в моем понимании только исходники. А дальше — от сложности проекта и скорости цикла, которую я хочу иметь.

                                                        +1
                                                        >> … вот только ждать придется дольше, чем если бы я собирал локально. И чем больше у вас программистов, тем сильнее это будет видно.

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

                                                        >> «Обязательно» в моем понимании только исходники. А дальше — от сложности проекта и скорости цикла, которую я хочу иметь.
                                                        так тогда вы теряете тот единственный плюс о котором говорилось выше. Возможность работать без сети и в любое время когда нужно. Если у вас только исходники, но чтобы посмотреть на работу программы нужно обязательно подключиться к сети/ докачать, доустановить etc, то какой профит таскать на своем ноуте исходники проекта?
                                                          0
                                                          бывают проекты, которые на типичном ноуте для разработки собираться будут часами

                                                          Вы все увеличиваете и увеличиваете время...


                                                          так тогда вы теряете тот единственный плюс о котором говорилось выше.

                                                          Не единственный. Еще как минимум банальная скорость навигации.


                                                          Если у вас только исходники, но чтобы посмотреть на работу программы нужно обязательно подключиться к сети/ докачать, доустановить etc, то какой профит таскать на своем ноуте исходники проекта?

                                                          (а) возможность в любой момент посмотреть код (чтобы принять решение/подумать/ответить на вопрос)
                                                          (б) скорость работы в IDE


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

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

                                                              Тогда я не понимаю, что такое "ваш вариант", и чем он отличается от "моего".

                                                                0
                                                                тобишь вы комментировали абы комментировать, не глядя что написано? по какой причине у вас возникло желание оставить коммент к моему?

                                                                зы. если по делу. изначально речь шла о том, чтобы локально поднимать веб-окружение на машине каждого разработчика. А приверженцы данного подхода аргументировали его полезность тем, что можно иметь под рукой в любом месте, независимо от наличия доступа в сеть рабочую копию проекта, чтобы показать заказчику или просто поработать. А я написал, что как по мне, то лучше иметь сервер разработки с поднятыми необходимыми сервисами, а не разворачивать их на каждой машине, потому что:
                                                                а) каждому разработчкиу не нужно настраивать кучу вещей руками
                                                                б) не нужно каждому разработчику ставить мощную тачку, чтобы локально держать весь зоопарк (на примере моего текущего проекта, который локально ну никак не развернуть)

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

                                                                да, я соглашусь, что в случае не слишком больших и сложных проектов вполне можно собирать исходники локально. Но всеже, иметь сервер «для деплоя» и софт который этот деплой исполняет мне кажется более еффективно. по крайней мере исключите человеческий фактор, что забыли/забили тесты прогнать после фикса, забыли/забили отключить какуюто дев-фичу и на прод окружении вылезет косяк. Единожды настроенный процес автоматического деплоя решит подобные пробелмы раз и навсегда.
                                                                  0
                                                                  А приверженцы данного подхода

                                                                  Лично я приверженец того (простого, в общем-то) подхода, что чем больше можно поднять локально — тем лучше. Абсолютный минимум — локально лежащие исходники. Дальше — локальная сборка, локальный запуск, локальная БД, и вплоть до локальных сервисов.


                                                                  Но всеже, иметь сервер «для деплоя» и софт который этот деплой исполняет мне кажется более еффективно.

                                                                  А это не взаимоисключающие вещи. Можно иметь локальное окружение и сервер для деплоя (первое тестовое окружение и далее).

                                              0
                                              Вполне сносное решение, я как раз так и работаю.
                                              IDE на одном ПК, сам проект на другом ПК, монтирую директорию с проектом как диск по ssh, чтение и запись без задержки… работать можно из любого места, демонстрировать проект тоже можно где угодно…
                                              в общем то плюсов достаточно…
                                                +2
                                                работать можно из любого места

                                                Из любого, или все-таки из любого, где есть адекватный интернет?


                                                (про "без задержки" я даже говорить не буду, тут все упирается в количество файлов, с которыми вам надо иметь дело одновременно)

                              +2

                              Свой для каждого разработчика?

                                0
                                Вообще правильно написанный код должен работать одинаково правильно и на локальных windows-машинах, и на реальном сервере. Так что локальная разработка — дополнительный способ проверить правильность кода (хотя конечно должна быть и постоянная проверка на реальном или максимально приближенном к реальному сервере).
                                Это как код на С++ собирать разными компиляторами: те баги что не видит msvc, видит gcc и наоборот.
                                  +1
                                  Неа. dll не so, и окружение разное. А термин «правильно написанный код» еще дефинировать надо. Еще тут предлагается сразу в продакшен его, чтоб не мучался… проверим, ага :)
                                    0
                                    Ну вот правильный код ИМХО должен быть абстрагирован от конкретных расширений «dll» и «so», а оперировать просто понятиями «динамически загружаемый двоичный модуль». Это как с абсолютными путями, которые начинающие разработчики впихивают в код, а потом удивляются, чего их код на других машинах не собирается или не работает :)
                                      0
                                      Угадаю. Вы не на ПХП программируете?
                                        0
                                        На чем я только не программирую… и на ПХП тоже приходилось (правда немного).
                                        А что не так?
                                          –1
                                          скажем так, что есть функционал, который работает исключительно в никсах.
                                          и тут у виндовозов случается пичалька.
                                            0
                                            правда, этот функционал отмечен в мануале на php.net особо. Так что использовать его или нет — решает каждый по ситуации.
                                              0
                                              это как-то противоречит написанному мной?
                                                0
                                                Скажите, а что это за функционал такой? Мне даже интересно стало:) Что может понадобиться для веб-сайта такого, чего в винде нет и даже не портировано?
                                                  0
                                                  по памяти, например, вот или вот.
                                                  плюс раньше была пичалька с разделяемой памятью и многими файловыми функциями, но вроде это дело поправили где-то в PHP 5.2/5.3
                                    0
                                    Ну в теории-то, если мы про чистый сферический код в вакууме говорим, то всё правильно.
                                    На практике чаще надо ехать, а не чтобы шашечки. Поэтому какие-то фичи в проекте могут быть зависимыми от среды — это раз, какие-то баги могут просто не отлавливаться на другой среде (например, опечатки с регистром в названиях файлов под виндой).
                                    И дальше-больше. Если в проекте есть какие-то интеграции и зависимости с различными внешними службами и сервисами, то гораздо проще и правильнее поддерживать доступ к ним с одного сервера разработки, чем открывать для бесконечного количества рабочих машин по всему миру. Там и другие нюансы могут быть, например большой объем данных, передаваемый к/от внешней службы, или нужна скорость.
                                      0
                                      Если в проекте есть какие-то интеграции и зависимости с различными внешними службами и сервисами, то гораздо проще и правильнее поддерживать доступ к ним с одного сервера разработки, чем открывать для бесконечного количества рабочих машин по всему миру.

                                      Вы же в разработке наверное используете не боевые службы и сервисы, а тестовые? Будем честными, в половине случаев никаких проблем с доступом нет вообще (если это, скажем, публичный SaaS), во оставшейся четверти — это внутренний сервис компании, и при правильно организованной сети это тоже не проблема, в оставшейся восьмой части можно написать прокси (мы, кстати, так и сделали один раз, заодно и отладку себе радикально упростили), и только в оставшейся восьмой части надо хоть как-то об этом думать.

                                    +1
                                    Я думал на тему удаленного сервера. Не нравится, что все разработчики будут зависеть от его функционирования. Мне ближе идеология git, когда у каждого разработчика своя независимая инфраструктура для разработки.
                                      –1
                                      Каждому надо настроить всю инфраструктуру проекта. Если речь о простых сайтиках, то может быть и нормально. А когда есть что-то нестандартное — это серьёзное неудобство и поле для потенциальных ошибок.
                                    +4
                                    Кстати, одно из величайших открытий для меня было, что можно поставить git или svn непосредственно на production сервере.

                                    Зачем?


                                    Ведь больше не надо мучиться с синхронизацией файлов по ftp\sftp, достаточно ввести svn up или git pull origin master!

                                    И для кого только системы автоматизированного развертывания пишут...

                                      +1
                                      на собственных проектиках есть постоянно deploy.sh, который делает git pull, перезагружает php-fpm и ещё что-нибудь. Работаю и не обламываюсь :) а настраивать CD на маленьких проектах как мне кажется это лишний геморрой
                                        0
                                        Работаю и не обламываюсь

                                        А кто-то без версионника работает и не обламывается.
                                        А кто-то прямо на продуктиве правит и не обламывается.


                                        а настраивать CD на маленьких проектах как мне кажется это лишний геморрой

                                        Ну да, писать собственный deploy.sh — конечно, меньший геморрой, чем взять готовое решение с тремя настроечными полями.


                                        Но вообще, конечно, идея "давайте сделаем git pull" выглядит хорошей… пока вы выполняете несколько условий:


                                        1. содержимое версионника не требует обработки перед выкладкой (например, компиляции)
                                        2. все нужное для выкладки лежит в версионнике (бинарные зависимости, например, тоже)
                                        3. вы обновляете только одну точку развертывания (например, вам не надо обновлять БД вместе с сайтом)
                                        4. вам не нужно управлять конфигурацией продуктива

                                        (и даже в этом случае могут быть проблемы класса "а как обеспечить бесперебойность работы во время обновления" и "как сделать так, чтобы на продуктив не утекло ничего опасного с точки зрения безопасности")


                                        Но если вам надо забрать зависимости, скомпилировать бинарник, выложить его на продуктив, сконфигурить там очередь, мигрировать БД — и все это проделать на ферме, — то поддержка deploy.sh становится непозволительно дорогой.


                                        PS а вы для каждого ландшафта свой deploy.sh пишете? а храните вы их где?

                                          0
                                          повторюсь, делаю это для своих проектов, они маленькие, на одном сервере в основном

                                          языки в основном php, python, так что компиляция не нужна

                                          в плане БД есть миграции, которые можно тоже запустить в deploy.sh

                                          зависимости тянуться с помощью composer install для php, в git лежит composer.lock, так что версии зафиксированы и если ничего не изменилось то и ничего не устанавливается

                                          как говорил, фермы серверов нет, для обновления и очистки кэша через скрипт обновляется fpm

                                          Ну а на рабочих сложных проектах конечно CD есть
                                            0
                                            повторюсь, делаю это для своих проектов, они маленькие

                                            Проблема в том, что этот опыт не масштабируется. Более того, он вырабатывает плохие привычки.

                                      +4
                                      > Подождите, а чем плох денвер?

                                      Сам по себе наверное ничем. Но сейчас есть Vagrant и Docker. С нативной поддержкой в IDE. Так что «король» давно умер, и после уже сменилось не одно поколение королей.
                                        +5

                                        Мне очень нравятся такие обобщения:


                                        … правда жизни такова, что большинство разработчиков пользуются Windows в качестве основной OC на компьютере.
                                          +3
                                          У нас в 2016 это уже моветон.
                                            +2
                                            В свое время ДНВР был очень хорош — спасибо, Дмитрий Котеров.

                                            Однако время летит, появляются новые технологии, новые инструменты — и Вы, разработчик, должны идти в ногу со временем.
                                              +1
                                              Деплой из git-а в принципе еще можно как-то понять, ну там деплой-скрипт запускать на push в релиз-ветк, в элементарных случаях это вполне может быть даже git pull.

                                              Но samba на сервер разработки? Откройте для себя realsync того-же Дмитрия Котерова.
                                                0
                                                Устанавливать дополнительную утилиту, которая будет постоянно синхронизировать изменения в фоновом режиме… Явно ненужное усложнение. Шара и так прекрасно монтируется и устойчиво работает, как будто на сервере разработки локальный диск. Тут нет проблем с сетевым соединением, т.к. все происходит на одном и том же компьютере. Сервер samba ставить не нужно, в качестве сервера выступает Windows-машина. На сервере разработки нужен только mount.cifs, который может даже устанавливать не надо (не помню, кажется, входит в стандартный дистрибутив CentOS).
                                                +2
                                                В почему не настрайвать на апаче динамичные виртуал хосты? Очен удобно: https://github.com/akalongman/ubuntu-configuration/blob/15.10/README.md#apache-configure-dynamic-virtualhosts
                                                  0
                                                  Да, динамические хосты похоже тут будут лучше — хорошее замечание. Не уверен, можно ли в динамических хостах делать специфические настройки под разные папки, но думаю, это решаемо…
                                                    0
                                                    Да, с помошью .htaccess всё вазможно. К тому же, в линуксах даже .dev домены не нужно прописать в hosts, выходит просто создал папку проекта и всё, открываешь в браузер. Очен удобно
                                                  +1
                                                  >правда жизни такова, что большинство разработчиков пользуются Windows в качестве основной OC на компьютере

                                                  Да ну :)

                                                  >И очевидное решение, которое мы нашли, было удивительно простым. В Windows-машине нужно завести отдельную папку, в которой будут лежать все наши проекты. Эту папку нужно расшарить для доступа по сети и примонтировать в корневую директорию, с которой работает Web-сервер.

                                                  IMHO, наикривейшее решение нашли… Не говоря уж том, что расшарить можно и средствами что VMWare, что VirtualBox, и незачем огород городить.
                                                    +1
                                                    К сожалению, у вас действительно получилось решение уровня «костыли и велосипеды — разрабатываем как умеем». По факту уже несколько лет есть куда более гибкие и удобные решения: есть virtualbox и vmware, а для быстрой организации управляемых контейнеров есть vagrant и docker.
                                                    Вот вам пример поднятия «веб-сервера» в 3 команды: scotch box, кроме того для более «требовательных» есть puphpet и куча других готовых решений.
                                                      0
                                                      Я считаю, что все зависит от ситуации. Да, вы правы, решения с vagrant и docker безусловно лучше собственного велосипеда и мы на них перейдем. Это уже шаг в сторону масштабирования. Когда будет разрастаться команда, усложнятся конфигурации и будут разными для разных проектов. Пока мы реально не испытывали в этом необоходимости, т.к. состав команды постоянный, нас немного, конфигурация виртуалки примерно одна и та же для всех проектов. Вполне достаточно дать новому разработчку скопировать виртуалку и после несложных настроек он в строю.
                                                      –3
                                                      Я малость офигеваю. Если это LAMP, то для LAMP куча PaaS существует с бэкджеком и фреймворками, настроенных 100 % от потребностей пляшите, git в помощь. Обкатать на халявных тарифах, а от то у них свои заморочки OpenShift явно тяготеет к JBoss, Heroku — к ROR. LAMP у всех есть, но иногда «чтобы был». Потом если ваш реальный продакшн — бэком имеет Percona (и ее бэкапер), а структура репликации — мама не горюй — как ни крути штучное решение. Просто у Вас велосипед, да колеса гнутые. Клиентский софт PaaS потребует от силы ruby или python поставить ( не изучать), ну саму его утилиту для работы с сервисами (не труднее AWS, потом вэб морда всегда есть). Но git является обязательным условием (заодно удобством, инструментом контроля версий и т д). Чем такие облака удобны — можно проимитиовать любой сервер от песочницы до продакшена. Некоторый запас наглости и умения позволяет первыми же халявами разместить систему управления проектами (у нас Redmine). А Denver — слово из прошлого — есть современные WAMP.
                                                        0
                                                        Использую подход как у автора, за исключением того, что файлы загружаются по sftp при помощи IDE, так как с шарами есть проблемы со скоростью и правами доступа. Можете объяснить мне кто-нибудь, кто пользуется Vagrant, Docker и т.п. в чем их преимущество перед обычной виртуалкой, если работаю я один (нет команды с кем нужно делить конфигурацию)? И если я одновременно работаю над несколькими проектами, насколько быстро они запускаются, переключаются? Хостовая система Windows.
                                                          0
                                                          Если docker, то преимущество в том что у вас будет идентичное окружение для разработки на локалке, и тоже самое окружение будет на продакшен сервере. Причем независимо от того какой там linux дистрибутив стоит (? по крайней мере независимо от centos/debian, другие не проверял).
                                                          Допустим вам нужна база данных postgresql. Вы просто берете готовый docker образ из его хаба, и юзаете туже самую базу данных для разработки локально и на продакшене. И окружение у этой базы будет точно такое же, то самое, что заложено в образ самого postgresql docker образа.
                                                          Грубо говоря вы строите контейнеры локально, и разворачиваете их же на продакшене с минимальным оверхедом (по сравнению с виртуалками).

                                                          Vagrant позволяет одному, допустим старшему разработчику написать Vagrantfile, а все остальные разработчики стянут его, и у всех будет одинаковая среда для разработки независимо на какой хостовой ОС они сидят. При желании можно даже собрать образ максимально приближенный к продакшену.

                                                          Что docker что vagrant позволяют вам писать код в среде приближенной к продакшену. Насколько приближенной вы можете решить сами, но как минимум и там и там linux например.
                                                            0
                                                            Спасибо, но я спрашивал применимо не к команде, а к одиночке. :) Например я делаю одному клиенту сайт на WordPress, другому магазин на OpenCart, для них не нужны хитрые конфиги, плюс в большинстве случае клиент использует шаред хостинг, зачастую без ssh. Как в таком случае удобно использовать виртуалку для разработки?
                                                              0
                                                              заводишь одну виртуалку с мускуль/веб сервер/пхп/редис/мемкеш и иже с ними
                                                              заводишь виртуальных хосты внутри виртуалки
                                                                0
                                                                Так сейчас и есть, но автора же запинали, что это прошлый век.
                                                                  +1
                                                                  Потому что автор пишет велосипед. То что он разворачивает — быстро не сворачивается и много ручного труда, а еще очень много кривых вещей которые уже решены в нормальных инструментах (проброс фс)
                                                          +1
                                                          if [[ $D == *"bitrix"* ]]
                                                          

                                                          теперь все ясно )
                                                          по поводу flush_vhosts.sh — ересь, если мне понадобится проксировать веб-сокет на определенный порт в одном из виртуальных хостов, то после добавления еще одного мне все перетрет и придется делать заново, т.к. скрипт «Очищает конфигурацию виртуальных хостов.». Не лучше ли сделать чтоб хосты добавлялись, а не перетирались старые?
                                                            0
                                                            Выше предложили использовать динамические виртуальные хосты, может это самое правильное.
                                                            Перезаписываю, т.к. у нас не требуется каких-то особых настроек, веб-сокеты в проектах не используются. Какие-то мелкие настройки внести через .htaccess. Зато не остается мусора, если папку с проектом убрали или переименовали.
                                                            –1
                                                            Странно, что за десять лет работы разработчики так и не освоили линукс.

                                                            Only users with full accounts can post comments. Log in, please.