PHPStorm + XDebug + Bitbucket: разработка на удаленном сервере в небольшой команде

В этой статье я расскажу как мы построили процесс разработки сайта не поднимая локальных копий веб-сервера в небольшой команде разработчиков с использованием Xdebug на тестовом сервере и автоматического развертывания репозитория на боевой сервер.



Немного о причинах НЕ поднимать локальную копию веб-сервера:
  1. Если вы работаете под Windows, а веб-сервер на линукс, то локальный сервер для сложного портала(в котором много специфического софта) под винду поднять бывает вообще невозможно, остается поднимать копию на виртуальной машине, но в этом случае разница в настройке ПО разработчика между настройкой под виртуальную машину и настройкой под удаленный веб-сервер заключается лишь в IP адресе.
  2. Если таки поднимать локальную копию, то придется постоянно синхронизировать настройки ПО сервера, базу данных и кроме того остается вопрос как быть с крон-задачами, которые часто должны выполняться под утро.
  3. Если сайт распологается на нескольких серверах или даже отдельные его части занимают несколько серверов(например, масштабированные таблицы — часть таблицы на одном, часть на другом сервере), то все это тоже может сильно усложнить задачу создания локального сервера.
  4. Производительность вашей машины и сервера может сильно различаться, что может иметь влияние и на код.
  5. Далеко не все участники проекта могут распологать достаточными навыками системного администрирования.

Но отказываясь от создания локальной копии сервера, мы теряем массу плюсов такого подхода:
  1. Запуск интерпретатора из IDE и соответственно отладка.
  2. Скорость закачки файлов и пинг.
  3. Разработчики работают каждый со своей копией сервера, поэтому они друг другу никак не могут помешать.

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

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

Пояснения к схеме:

  • Разработчик имеет копию репозитория
  • Тестовый и боевой веб-сервер в качестве корневой директории проекта имеет рабочую копию репозитория
  • Файлы проекта связаны в PHPStorm с рабочей директорией тестового веб-сервера, это значит при Ctrl+S происходит автоматический аплод редактируемого файла на сервер

Как происходит разработка:

  1. разработчик правит код локально
  2. нажимает Ctrl+S файл загружается на сервер
  3. запускает в браузере нужную станицу тестового веб-сервера(или выполняет на ней нужное действие), смотрит результат
  4. если необходимо запускает дебаггер с помощью Xdebug
  5. если все устраивает делает коммиты в репозиторий и потом Push
  6. хранилище(в нашем случае это Bitbucket) автоматически после каждого Push'а опрашивает указанный скрипт на боевом сервере
  7. при опросе этот скрипт вызывает git pull и т.о. приводит рабочую директорию боевого веб-сервера до актуальной версии из репозитория

Подготовка сервера

в нашем случае проект существовал без репозитория, отдельная тема как его туда добавить(т.к. надо исключить массу файлов которые не нужно добавлять в репу), но допустим репа уже есть на Bitbucket, а файлы на сервере лежат в обычной директории
  1. логинимся под юзером проекта:
    su myproject
    
  2. генерим SSH ключи для авторизации на bitbucket без пароля
    ssh-keygen -t rsa
    
  3. получаем публичный ключ
    cat ~/.ssh/id_rsa.pub
    и добавляем его на Bitbucket в раздел Deployment keys в настройках проекта
  4. клонируем проект во временную директорию ~/tmp/myproject.ru:
    mkdir ~/tmp
    mkdir ~/tmp/myproject.ru
    cd ~/tmp/myproject.ru
    git clone git@bitbucket.org:username/myproject.ru.git
    
  5. копируем .git и .gitignore в рабочую директорию проекта (у нас это /vhosts/myproject.ru/), остальные файлы не копируем!
    cp -r .git .gitignore /vhosts/myproject.ru/
    rm -rf ~/tmp/myproject.ru
    
  6. приводим файлы к состоянию из репозитория
    cd /vhosts/myproject.ru
    git reset --hard
    

Подготовка клиента

Если у вас еще не установлен Git — ставим
В PHPStorm прописываем путь до Git'а (это файл bin/git.exe) — Settings -> Version Control -> Git -> Path to Git executable

Клонируем репозиторий:

В PHPStorm вкладка VSC -> Checkout from Version Control -> Git
указываем имя новой директории проекта и путь к репозиторию, например
username@bitbucket.org/username/myproject.ru.git

Сихноризируем файлы с удаленным сервером:

  1. Добавляем сервер и указываем его доступы File -> Settings -> Deployment
  2. в Root path указываем путь до корня проекта (в моем случае /vhosts/myprojet.ru/) — корень проекта на сервере должен совпадать по иерархии файлов с корневой директорией репозитория
  3. Переходим во вкладку Mappings и указываем в Deployment path on server — / и в Web path on server тоже — / (если тот начинается с корня сайта)
  4. Выбираем наш сервер в списке и жмем на кнопку Use as default
  5. Далее в Deployment -> Options нужно выбрать On explicit save action (Ctrl+S) в Upload changed files automatically to the default server
  6. В Warn when uploading over newer file выбираем Compare timestamp & size (хотя можно и по содержимому) и отмечаем Notify about remote changes, это позволит узнать если кто-то правил тот же файл

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

Настройка автопула на боевом сервере:

  1. Создаем shell скрипт для автоматического pull'а проекта /vhosts/myproject.ru/gitsync.sh:
    #!/bin/sh
    cd /vhosts/myproject.ru && git reset --hard && git status --porcelain -uall | egrep '^\?\?' | awk '{ print $2; }' | xargs rm && git pull
    Поскольку git выдает ошибку при pull, если добавлены новые файлы, но при этом не зафиксированы, а git reset --hard их не удаляет, то мы парсим вывод git status и удаляем новые файлы, чтобы они были загружены из репозитория, кроме того git reset --hard отменяет все изменения в файлах, чтобы не было конфликтов.
    Не забываем добавить права на исполнение скрипту
    chmod a+x /vhosts/myproject.ru/gitsync.sh
    
  2. Поскольку операции с репозиторием проходят от пользователя-владельца файлов, а веб-сервер работает от другого пользователя, то нужно ему добавить разрешение на запуск авто-pull скрипта от чужого имени без пароля через /etc/sudoers
    # /etc/sudoers
    #
    # This file MUST be edited with the 'visudo' command as root.
    #
    # See the man page for details on how to write a sudoers file.
    #
    Defaults        env_reset
    #Чтобы можно было выполнять sudo без терминала, т.е. прямо от веб-сервера
    Defaults:www-data !requiretty
    # Host alias specification
    
    # User alias specification
    
    # Cmnd alias specification
    
    # User privilege specification
    root    ALL=(ALL) ALL
    
    # Allow members of group sudo to execute any command
    # (Note that later entries override this, so you might need to move
    # it further down)
    %sudo ALL=(ALL) ALL
    #
    #includedir /etc/sudoers.d
    
    #разрешаем запуск скрипта от чужого имени без пароля
    www-data ALL = (myproject) NOPASSWD: /vhosts/myproject.ru/gitsync.sh
    
  3. Созадем php скрипт, который будет из веба запускать наш shell скрипт /vhosts/myproject.ru/htdocs/gitsync.php (название можно выбрать более секретное, как и добавить передачу пароля):
    <?php
        $output = array();
        exec('sudo -u myproject /vhosts/myproject.ru/gitsync.sh 2>&1', $output);
        foreach ($output as $line)
        {
            echo $line."\r\n";
        }
        die();
    ?>
    
  4. в Bitbucket в настройках проекта во вкладке Services в раздел POST пишем путь до скрипта автопула: myproject.ru/gitsync.php и жмем Save

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

Подключаем Xdebug

Как установить его не буду описывать, будем считать что Xdebug установлен, правим конфиг /etc/php5/conf.d/xdebug.ini:
zend_extension=/usr/lib/php5/20090626/xdebug.so
xdebug.remote_enable=1
xdebug.remote_connect_back=1
xdebug.idekey=PHPSTORM
xdebug.remote_port=9000

Обратите внимание на директиву remote_connect_back — она позволяет коннектиться не к заданному IP машины разработчика, а к IP клиента который находится в окружении PHP (REMOTE_ADDR), т.о. с Xdebug могут работать одновременно несколько человек. Это не значит что Xdebug будет запущен при каждом обращении к серверу, для его старта по прежнему требуется передать определенные cookies — подробнее

Вбиваем тут IDE key указанный нами в xdebug.idekey ключ PHPSTORM и появившиеся ссылки внизу перестакиваем на панель закладок

Настраивать в PHPStorm специально ничего не надо, все уже настроено, но на всякий случай настройки тут — Project Settings -> PHP -> Debug

теперь чтобы отладчик заработал нужно:
  1. в PHPStorm включить прослушку коннектов дебаггеров — кнопка Start Listen PHP Debug Connection
  2. открыть сайт, ткнуть закладку Start debugger, перезагрузить страницу
  3. PHPStorm должен маякнуть о входящем подключении и открыть дебаггер

Поскольку соединение идет из вне, а многие теперь сидят за роутерами, то на роутере нужно сделать проброс порта 9000 на ваш локальный IP адрес, на D-link DIR 300 это выглядит примерно так:

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

Ссылки:
http://git-scm.com/
http://xdebug.org/
http://bitbucket.org/
http://jetbrains.com/phpstorm/

Similar posts

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

More

Comments 67

    –1
      +2
      И Vagrant реально удобней.
        0
        я рассматриваю в статье альтернативный подход — с централизованным сервером
        0
        читал
          0
          Кидать ссылку без сопроводительной информации, даже без пары слов — по-моему, не очень красиво.
          А вообще, по ссылке выше идёт более узкоспециализированная информация, причем немного отдалённая от сути этого топика.
          Я, например, думаю, что человек с удалённым сервером найдёт, как туда поставить lamp.
          А в этом топике опускаются ненужные тонкости, что повышает её ценность, т.к. рассказывается именно подход. Причём поэтапно.
          Это ведь тоже немаловажно. Если другая ide, или отсутствие тестового сервера — все факторы тем не менее позволят настроить и понять как пушить всем разом на удалённый сервер из среды разработки. Странно читать о настройках php 5.x и php.ini, если нужно настроить совместный удалённый контроль версий.
          Так что каждому — своё, а автору — плюс.
            0
            Я в первую очередь кидал ссылку на комментарии.
          0
          Не могли бы вы чуть подробнее расписать вот эту схему:
          ===
          Теперь после каждого push'а все файлы на сервере будут приводится к файлам из репозитория, можно такой же подход реализовать и на тест сервере, но в этом случае если один разработчик имеет незапушеные файлы, то на сервере они затрутся и их придется заново загружать.
          ===
          ?
          Просто если бы содержимое тест-сервера обновлялось только по push-ингу из локальных репозиториев разработчиков, то ошибки из-за незапушенных файлов уже проявлялись бы на момент тестирования на тест-сервере.
          А может я просто не до конца представляю себе схему взаимодействия для этого случая? )
            0
            подразумевается что в пуш попадают уже законченные, протестированные фичи
            т.к. разработка ведется на одном удаленном сервере — всю работу сразу же видно и сразу же можно её протестировать, до отправки в репозиторий и на продакшн соответственно
              0
              Я про вот эту ситуацию:
              ==
              можно такой же подход реализовать и на тест сервере
              ==

                0
                задачи практически не пересакаются, поэтому ошибки не появились бы из-за удаленных и незапушеных файлов чьих-то, но вообще автопул на тестовом сервере не очень удобно из-за того что в момент работы другого человека его правки могут удалиться с сервера
                  0
                  Все ж таки, не совсем понятно. В первоначальном варианте данные из IDE пользователя сохраняются на тестовом сервере при сохранении (CTRL+S). Когда рассматривается «такой же подход на тестовом сервере» — как это выглядит? Данные на тестовый сервер поступают только при push-ах из локальных репозиториев разработчиков? И как тогда в этом случае выполняется отладка изменений перед push-ингом?
                    0
                    предполагалось данные на тестовый сервер поступают так же при Ctrl+S, но кроме этого при пуше
                      0
                      Ок, разобрался, спасибо )
            0
            Вообще, PHPStorm умеет выгружать и на выбранный сервер при коммите. Собственно так и работаю как у вас, но не нужна «Настройка автопула на боевом сервере» и тех танцев, что у вас описаны. Проще, без заморочек, потери времени и прочего. Но для саморазвития полезно. Спасибо.
              0
              тоже вариант, просто репозиторий обеспечивает большую целостность и если коммит можно отменить и про него никто не узнает(хотя сервер пострадает), то пуш с хранилища уже никуда не денется и будет видно что, кто, когда и как
              +1
              Тестовый сервер (проект на нём) один для всех разработчиков без контроля версий?
                0
                один сервер для всех разработчиков, но с системой контроля версий, как показала практика в небольшой команде это хорошо работает и легко настраиватся и поддерживается
                  0
                  Хм, из статьи не видно, что по Ctrl+S будет автоматом комит на тестовый сервер.
                    0
                    при Ctrl+S будет аплод только на тест сервер, чтобы было видно результат работы, коммит будет при коммите
                      0
                      Вот это меня и беспокоит, разве на тестовом сервере нету конфликтов в коде от разных разработчиков?
                        0
                        нету, об этом и речь, иначе мы бы не смогли использовать такую схему

                        задачи не пересекаются по файлам
                          0
                          Всё же тестировать на одном общем сервере чревато не только конфликтами в исходниках. Как правило первое исполнение своего кода приводит к ошибкам. А тут ещё непроверенный код от других разработчиков в любую секунду появляется.
                            0
                            как я уже сказал в нашем проекте задачи разработчиков и верстальщиков практически не пересекаются, на практике никаких конфликтов не возникает, тем более работает 3-4 человека

                            если какие-то другие условия, то я бы скорее всего не стал такой подход использовать
                              0
                              Ну если ещё логика изолирована по файлам или отлаживаете с разделением по времени :)
                                –1
                                бред
                        +1
                        Обычно, у каждого разработчика своя песочница на тестовом сервере, а окружение одно. И много проблем даже из-за того, что кто-то при тестирование добавил неверные данный в базу/кеш/файловое хранилище/итп. Такое метод применяют только потому, что на проектах с большим стеком технологий (практически весь хайлоад) настроить окружение не так просто, да и требования к локальной машине поболее.

                        Но что бы еще и код был один и тот же — это очень специфичное и бессмысленное решение, да и подойдет только единичным проектам.

                        Но спасибо за мануалы, мне очень помог по XDebug, не мог у себя настроить, долго мучился без него.
                          0
                          ну я согласен с вами, что удобнее конечно иметь каждому свою песочницу и одно окружение, я думаю мы скоро так и сделаем, просто на данный момент описанное решение оказалось легко достижимым и эффективным
                  +1
                  А как происходит обновление удалённой директории когда меняется бранч?
                  Т.е. я локально работаю с TortoiseHG, меняю в нём бранч… как обновить удалённую директорию?

                  Второй вопрос

                  это позволит узнать если кто-то правил тот же файл


                  Почему не дать каждому разработчику свою директорию, в которой каждый будет работать в своём бранче?
                    0
                    IDE позволяет одновременно делать выгрузку по FTP
                      0
                      Там есть опция Upload, если в контекстном менб проекта и папок, но при выполнении этого действия аплоадятся 1) только новые файлы, т.е. изменённые с переключением на другой бранч все изменённые файлы в удалённую директорию не попадают. 2) Старые файлы которых нет в бранче на который переключился — не удаляются.

                      т.е не понятно как без сторонних тулз сделать удалённую директорию точно такой как в бранче при переключении.
                          0
                          Дмитрий, спасибо, обязательно попробую.

                          А так же спасибо за, Денвер, книги, наблы, библиотеки и всё остальное =)
                      0
                      сложность в организации, настройке и поддержке(если не понятно какие сложности возникают могу пояснить), проще использовать один общий тест-сервер
                        0
                        Так вы всё это время про тест сервер говорили, или про дев?

                        Даже если про тест, не знаю насколько велика ваша команда, но у нас 10 тест енвейрментов.
                          0
                          у нас один тест-сервер, общий для всех 3-4 человек
                            0
                            Так а что с синхронизацией кода с сервером при смене бранча, как вы это делаете?
                              0
                              тест-сервер ничего не знает о бранчах и репозитории — на него просто загружают файлы по Ctrl+S
                                +1
                                Понятно что он не знает.
                                Я выше в комментарии описал суть проблемы, как переключившись на бранч ЛОКАЛЬНО заапплоадить все изменившиеся файлы локально, удалить с сервера не нужные файлы, т.е. привести директории в соответствие.

                                Там есть опция Upload, если в контекстном менб проекта и папок, но при выполнении этого действия аплоадятся 1) только новые файлы, т.е. изменённые с переключением на другой бранч все изменённые файлы в удалённую директорию не попадают. 2) Старые файлы которых нет в бранче на который переключился — не удаляются.

                                т.е не понятно как без сторонних тулз сделать удалённую директорию точно такой как в бранче при переключении.
                                  0
                                  Это можно сделать средствами PHPStorm — Synchronize directory
                                    0
                                    Тем временем другой разработчик (у вас ведь их 3-4) будет синхронизировать другую ветку… очередной конфликт командной разработки.
                                    Один тестовый сервер сойдет для тестов перед выпуском проекта. Для разработчиков нужно иметь своё окружение. У них и так на локале код проекта, среда разработки. Почему оказывается накладно для разработчика установить ещё http сервер и субд?
                                      0
                                      у нас просто нет необходимости создавать бранчи, поэтому для нас этот подход работает, если все работают с одними файлами тогда конечно — создание бранчей, индивидуальное окружение, просто надо понимать чтобы бывают разные проекты и бывают разные, рабочие решения
                                        0
                                        Я даже не знаю что сказать… работа без бранчей для меня давно кажется… противоестественной =)
                                        Даже если бы я работал один — я бы делал бранчи для новых фич.
                                        Вдруг что-то нужно захотфиксить в проде, а ты в этот момент делаешь новую фичу?.. Быстро сделал бранч из продового тэга, задеплоил, потом замерджил апдейт в свой фичебранч… короче процесс… не понимаю как можно по другому… без бранчей =)
                                          0
                                          В 99% случаев можно поправить прямо в продовом бранче (именно бранче, тэги тут не очень и нужны), проверить, закоммитить и выложить на прод, как обычно. Не нужно ответвлять что-то от продового бранча (на то они и срочные фиксы, чтобы быть маленькими). Но дев-бранч и прод-бранч обязаны быть разными, конечно, без этого никак.
                                            0
                                            именно бранче, тэги тут не очень и нужны

                                            Если теги не нужны, как потом откатываться, если релиз оказался неудачным?
                                            Точнее до чего откатываться? Для этого релизы фиксируются тегами и в логе прода можно посмотреть в каком порядке релизы попадали в прод и откатиться до предыдущей версии. В нашем случае — одной кнопкой rollback в деплоере.

                                            Не нужно ответвлять что-то от продового бранча

                                            Ну у нас это формальный процесс, поэтому так. На самом деле сделать бранч — дело двух минут. Ишу в багтрекере, новый бранч из id ишу, пишем в него фикс, коммитим, деплоим. При желании даже тут есть место автоматизации, сделать какой-то UI, который будет по нажатию кнопки создавать ишу в багтрекере и бранч из продового тега с нужным именем. Останется только переключиться на него, вписать фикс и запушать/задеплоить.
                                              0
                                              О, может быть, вы — тот единственный человек, который на практике откатывает релизы в веб-проектах! Я давно вас ищу. Опровергните меня аргументированно тогда, пожалуйста.

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

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

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

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

                                                  Ну и если всё плохо, конечно откатываем, накатываем определённые таблицы БД обратно.
                                                  Реально доставляющие проблемы релизы случаются довольно редко, мы к ним готовимся, делаем бекапы, скрипты отката, ставим портал в мейнтененс мод или рид-онли, релизим, QA прогоняют автоматические тесты и если всё более менее ок тогда открываем портал и т.д.
                                                    0
                                                    Ага, колонки добавляются заранее, до релиза, и так, чтобы они не портили совместимости с существующим (в будущем — старым) кодом. Но возникает вопросы: а как же с разными constraint-ами (например, not null)? И как, меняя базу, быть уверенными, что это изменение, накаченное отдельно, не сломает существующий код?

                                                    Сдается мне, что все разрешенные изменения в структуре БД при этой схеме сводятся к 2 операциям:
                                                    1. Создание новой nullable колонки, причем такой, что код умеет правильно null-ы там интерпретировать, даже если по логике предметной области их там быть не может.
                                                    2. Добавление новой таблицы.
                                                      0
                                                      как же с разными constraint-ами (например, not null)


                                                      Ну если нул -то понятно в колонках будет нул до релиза, если не нул — обычно ставится default "...".
                                                      Иногда при релизе готовится какой-то транзишен/релиз скрипт, который прописывает что-то осмысленное в колонки.

                                                      И как, меняя базу, быть уверенными, что это изменение, накаченное отдельно, не сломает существующий код?


                                                      Ну новая колонка/таблица точно ничего не сломает, модификация полей происходит редко.

                                                      В целом по обоим пунктам — может мы просто не ставим никаких строгих условий, но не помню чтобы с этим были какие-то проблемы.

                                                      Сдается мне, что все разрешенные изменения в структуре БД при этой схеме сводятся к 2 операциям


                                                      Ну да, или nullable или дефолт, если это подходит.
                                                      Опять таки, в любом случае, если релиз откачен и задеплоен заново — можно прогнать скрипт, который проставит значения.
                                                        0
                                                        Проставит-то он проставит, да вот только за промежуток времени, когда он уже закончит работу, а новый релиз еще не накачен, в новых колонках опять образуются несогласованные данные, с которым новому коду (после релиза) надо будет иметь дело. В принципе, можно снова скрипт запустить, чтобы он по оставшимся (новым) данным прошелся, но все же это как-то сложно все… Шаг в сторону нестрогой схемы данных и отсутствия контроля целостности со стороны БД, что ли, хотя, конечно, на больших базах без асинхронного скрипта-пробивателя в любом случае не обойтись.
                                                          0
                                                          Ну, скрипт можно запустить после того как релиз накачен, если условиями это позволяется. У нас это обычно так. В крайнем случае, как я упоминал выше — ставится мейнтенанс мод и никакие новые записи не появляются. Опять таки в нашем конкретном случае можно себе это позволить. Для тех у кого система вечно живая и её невозможно остановить — ну да, нужно догонять, досинхронизировать. Ну, это уже всё такая теория… что на любой абстрактный вариант можно придумать любую абстрактную проблему, такие вещи нужно придумывать подкладывая к реальному случаю, реальной системе =)
                                          0
                                          Почему накладно установить http сервер и субд?
                                          потому что вместе с этим нужно будет ставить:
                                          redis
                                          sphinx
                                          IIP
                                          видео утилиты (у нас свой видео хостинг)
                                          прорву модулей для PHP
                                          настраивать как-то выполнение утренних крон-задач(очень ресурсоемких) — т.к. иначе на следующий день просто не будет множества данных которые каждый день агрегируются
                                          ну и плюс к этому нужно постоянно будет синхронизировать конфиги, модули, доп. ПО серверное, общие файлы

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

                                          а вот создавать каждому верстальщику виртуальную машину — бред.
                                            0
                                            Верстальщиков я не имел в виду, им xDebug не нужен. В чём накладно теперь понятно. А не расскажете, как делаются «песочницы»?
                                              +1
                                              я бы делал такт:
                                              на каждого разработчика создаем все домены проекта в http серверах, например
                                              vasya.video.project.ru
                                              vasya.travel.project.ru
                                              petya.video.project.ru
                                              petya.travel.project.ru
                                              и т.д.
                                              но не прописываем их в днс, а прописываем только в hosts(для простоты) на локале, далее файлы так организовываем
                                              1. файлы из репы заливаем в рабочую директорию веб-сервера и настраиваем свою IDE на работу со своей песочницей
                                              2. общие файлы(аплод, кеш и пр.) — делаем симлинки на основную директорию где все это есть
                                              3. конфиги создаем индивидуально

                                              т.о. у каждого своя песочница, при желании можно поправить конфиг и юзать собственную изолированную БД, или допустим вместо симлинка на кеш создать собственный кеш, при этом никто никому не мешает, но имеет общее окружение
                                                0
                                                В DNS можно прописать *.project.ru, и веб-сервер все сам будет разруливать, без возни с hosts.
                                                При этом явные записи vasya.video.project.ru с другим IP будут приоритетнее, чем *.project.ru
                                              0
                                              А зачем ставить всё это по отдельности? По сути просто папки и тестовые домены. Вебсервер работающий в подобном проде енвайрнменте. Синхронизировать заливать продовую базу с дев раз в какое-то время.

                                              База на всех одна, как и прочие сервисы.
                            +1
                            >> Если отладку можно получить с помощью Xdebug, а скорость переехав на другой сервер, то третье преимущество..
                            … можно сохранить, используя ферму виртуальных машин?
                              0
                              это более сложное решение, надо будет как-то синхронизировать состояние всех машин между собой, ну и открытый вопрос остается с БД и кроном
                              0
                              По идее необходимо в гите держать три ветки -stable/test/dev и уже из них выгружать на тестовый сервер и на продакшн.
                              А что касаемо рабочего места, то пожалуй для веб-разработки (для проектов на *nix хостинге) лучше использовать linux + phpstorm(linux) или netbeans (и локально поднятый LAMP) и отказаться от windows более чем полностью (я говорю о программистах, не дизайнер или верстальщик, в их случае с этим посложнее).
                                0
                                мало того, всем при этом нужно будет использовать такую же версию как и на сервере и такой же набор серверного софта… но как быть верстальщику при этом опять не ясно
                                0
                                А для чего нужна ета схема с git reset --hard и копированием только .git и .gitignore?
                                  0
                                  git reset --hard как и удаление файлов из git status нужно чтобы pull прошел без ошибок, если на сервере есть какие-либо правки(например срочно что-то правили, а только потом внесли в репу)
                                    0
                                    копирование .git и .gitignore нужно т.к. проект уже рабочий и он лежит себе в своей директории веб-сервера, при этом нужно файлы из репозитория скопировать с заменой в директорию вебсервера(при первичном подключении репы), можно конечно просто скопировать, а можно скопировать только .git и .gitignore и запустить git reset --hard — результат будет один и тот же
                                      0
                                      Все, я понял, у вас в /var/myproject были файлы проекта причем они там были вместе с кешами, конфигами (ну все то что в .gitignore добавлено)
                                      И вы хотели сохранить эти файлы, поетому просто удалить и сделать clone нельзя.
                                    0
                                    Если у Вас код хранится на BitBucket, то можно использовать для автодеплоя jenkins (или другой CI-сервер). Он опрашивает репозитарий и при появлении новых коммитов делает git pull.
                                    У нас такая схема вполне прижилась.
                                      0
                                      ну это суть два способа достижения одной цели
                                        0
                                        Не можно, а НУЖНО. Всегда удивляет, как люди не пользуются CI и git-flow, которые делают прозрачным процесс разработки и деплоя, при том, что начиная со второго проекта процесс будет занимать пять минут.

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