Организация среды веб-разработки

    Продуктивность коллектива веб-студии напрямую зависит от удобства среды разработки. У нас сложилась стройная система организации работы с проектами, включающая в себя набор таких неотъемлемых компонентов, как IDE, SCM, PM-система, багтрекер и development-сервер. Этим постом я бы хотел начать цикл статей, посвященных настройке и использованию этих компонентов в нашей студии.

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

    Идеи

    1. Среда разработки должна быть единой для всех сайтов.
    2. Девелоперы не должны тратить время на настройку каждый своей серверной части.
    3. Работает ли над проектом один человек или несколько — контроль версий необходим.
    4. Если рабочий каталог (IDE workspace) находится на сервере, то можно поработать и дома, не тратя время на повторную настройку окружения на домашнем десктопе или ноуте.

    Концепция


    Основа концепции заключается в том, что разработка всех проектов ведется на одном сервере. Плюсы очевидны:

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

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

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

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

    Минусами этой концепции являются требования к скорости и надёжности сети и недостаточная гибкость индивидуальной настройки ПО под каждый проект в отдельности. В нашем случае плюсы значительно превосходят минусы :)

    Доступ


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

    Просмотр.
    У себя, внутри студии, мы выбрали следующую схему:

    username.project.example.com/trunk
    По такому адресу сам разработчик и все члены команды получают доступ к наработкам друг друга. Для контроля версий мы используем SVN (схема unstable trunk, stable branch), создавая по репозиторию для каждого проекта, соответственно, мы обращаемся к нужной ветке, указывая её путь (/trunk; /branches).

    Редактирование.
    Самое удобное для разработчиков — это видеть файлы проекта без отделения их от файловой системы ОС. Поэтому, каждый разработчик, чтобы начать работать с проектом, просто монтирует свою директорию на сервере к себе на локальную машину.

    Реализация


    Как ни странно, но с реализацией все очень просто.

    Bind
    Естественно, если мы хотим получить домены вида username.project.example.com, то необходимо добавить следующую строчку в файл зоны:

    *.example.com. IN A 208.77.188.166
    Все поддомены подходящие по маске *.example.com, будут адресованы на адрес вашего веб-сервера.

    Apache
    Теперь, нужно научить веб-сервер обрабатывать наши домены и адресовывать их к нужной директории. Рабочая директория на сервере для разработчика выглядит следующим образом: /var/www/username.example.com/project/trunk/htdocs/
    Может быть, правильнее было бы хранить все в /home/username/.

    Настраиваем виртуальные хосты:

    <VirtualHost *:80>
    ServerAlias *.*.example.com
    ServerPath /var/www/
    DocumentRoot /var/www/
    RewriteEngine On
    RewriteCond %{http_host} ^([^.]+)\.([^.]+)\.example\.com [NC]
    RewriteRule ^/(trunk|branches|tags)\/?(.*)$ /%1.example.com/%2/$1/htdocs/$2
    </VirtualHost>


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

    Линукс
    Протокол ssh (если у вас сервер так же, как и клиент под linux или unix) является родным, поэтому, создав каждому из разработчиков пользователя на сервере, монтирование директории осуществляется одной командой:
    sshfs -o workaround=rename username@example.com:/var/www/username.example.com/ /home/username/username.example.com/
    Параметр workaround=rename нужен для корректной работы с svn.

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

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

    Мак
    Тут два варианта, можно использовать ssh: для монтирования директории подойдет приложение Macfusion; можно использовать нативный AppleTalk, тогда примонтировать директорию можно будет через Finder.

    Поддержку AppleTalk можно организовать с помощью установки пакета netatalk. Для настройки потребуется добавить в файл /etc/netatalk/AppleVolumes.default строчку:
    /var/www/username.example.com/ username.example.com allow:username cnidscheme:cdb options:usedots,upriv,noadouble
    Теперь в Finder можно нажать ⌘+K и в поле адрес вводим afp://username@example.com/username.example.com

    Заключение


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

    Подробнее
    Реклама

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

      +4
      а freeware аналогов ExpanDrivе нету?

      p.s. Молодец. Ждем продолжения.
        +2
          0
          Он «Free for home use», так что не совсем подходит.
            0
            тоже посмотрел на это и приобрёл ExpanDrive, лицензия обошлась на десятку дороже чем у NetDrive
          +2
          Пардон, еще надо ftp>sftp бридж. mindterm например.
          правда, и то и другое freeware только для home use.
            +2
            Dokan SSHFS
            Как установить тут: blog.azomazo.ru/2009/02/ssh-windows.html

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


            Но опятьже на таком диск с SVN при помощи, например, TortoiseSVN работать не получается…
            –3
              0
              У нас похожая структура. Только диск подключается не софтом, а самой виндой как сетевой. Проекты доступны по адресу projec.username.company.com. Работает всё на FreeBSD сервере. У каждого на сетевом диске список папок с проектами. Каждая папка автоматом монтируется в поддомен.
                0
                Скажите, а согласно Вашей системе юрлов, username.company.com на что указывает?
                Дело в том, что username.projec.company.com позволяет при удалени младшего сегмента projec.company.com видеть версию репозитория)
                  0
                  test.username.company.com -> /users/username/www/test/
                  username.company.com -> /users/username/www/ — корень рабочей директории пользователя. В ней лежат директории с проектами. Тоесть у каждого разработчика своя копия проекта. Только база данных общая. После окончания задачи на каком либо из проектов идет коммит в репозиторий, который лежит на отдельной машине. Если нужно вылить проект на продакшн, то жмется спец кнопка, которая запускает скрипты экспорта. С её же помощью можно посмотреть текущую версия на живом сервере проекта и откатить исходники при необходимости.
                0
                А зачем именно workaround=rename? Я давно монтирую так директории и проблем с SVN не встречал, может быть потому что я один монтирую эту папку и никто другой не «мешает» мне? :)
                  0
                  По идее никто другой и не должен — это же ваша личная папка.
                  0
                  У меня вот какой вопрос возник.
                  Допустим над проектом (project1) работают два программиста (pr1, pr2) и один верстальщик (m1), т.е. получается что каждый из пользователей получит свой каталог проекта, что-то такое:
                  /var/www/pr1.example.com/project1/
                  /var/www/pr2.example.com/project1/
                  /var/www/m1.example.com/project1/

                  Но существует ли в этой схеме вариант увидеть общий итог работы этих трех?
                  Т.е. когда их частные изменения собираются вместе.

                  Допустим работа верстальщика m1 добавляется к работе программиста pr1.
                  Может они самостоятельно, с помощью SVN, подгоняют свои проекты под этот общий итог?

                  Возможно я не совсем разобрался в самой идее и поэтому надеюсь на вашу помощь.
                    0
                    ну, когда один из них сделал то, что ему было нужно, он делает comit, остальные уже могут сделать update и получить результат его работы в свою версию.
                      0
                      Каждый пользователь делает commit куда-то сюда, в зависимости от ситуации:
                      username.project.example.com/trunk
                      username.project.example.com/tags
                      username.project.example.com/branches

                      А как они будут делать update?
                      Ведь у них независимые по сути проекты.

                      Просто я видел немного другую организацию хранения проекта:
                      project.example.com/trunk
                      project.example.com/tags
                      project.example.com/branches/username1
                      project.example.com/branches/username2

                      Т.е. идея в том, что есть один проект и над ним работают разные люди. При этом конфигурирование доступа для конкретной реализации проекта в Apache можно также автоматизировать.
                        +1
                        У них независимые копии проекта, а репозиторий один.

                        Посмотреть итог работы этих троих можно сделав пост-хук-коммит, который бы обновлял например: /var/www/build.example.com/project/, тогда по адресу build.project.example.com будет находиться самая последняя версия проекта.

                        Если в репозитории по ветке на каждого разработчика, то чтобы посмотреть результат работы нужно будет делать merge между ветками.
                          0
                          Просто именно описание того что есть некоторый магический build.example.com не было в статье. И я хотел узнать как у вас это делается.
                          Спасибо за ответ.
                            0
                            Где-то недавно проскакивала статья о создании хуков: adw0rd.ru/2009/subversion-hooks/
                              0
                              Спасибо за ссылку.
                              Мне просто не очень понравилась идея хуков.

                              Вот некоторый пример.
                              Пусть все будет как и описано в этом комменте ( habrahabr.ru/blogs/webdev/65005/#comment_1815206 )

                              Теперь допустим программист pr1 добавляет в проект некоторую функциональность, допустим новостную ленту. Когда дело доходит до представления ( шаблонов), то на начальном этапе программист сам этим занимается. Но в какой-то момент подключается верстальщик m1. Видимо он должен извлечь некоторые наработки программиста pr1 ( а если еще и pr2 работал на этой же функциональностью, то и как-то merge сделать) себе в рабочую копию. Хотя он конечно может извлечь все из интеграционного проекта build.

                              Но вот что мне не нравится больше всего, при продолжении работы программист и верстальщик делают commit и в интеграционном проекте build будут последние изменения сделанные кем-либо из pr1, m1. Это усложняет совместную разработку.

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

                              Таким образом нет username.project.example.com/trunk, а есть project.example.com/trunk и в редких случаях project.example.com/branches/username (его «нужно» потом объединять с основной веткой разработки).

                              Это не значит что нельзя автоматизировать просмотр извлеченных рабочий копий для каждого пользователя. Как вариант в домашнем каталоге пользователя есть каталог projects. Туда пользователь извлекает из SVN рабочую копию проекта и apache автоматически подхватывает его по адресу username.project.example.com

                              Но при этом всегда есть, актуальная что-ли, версия проекта.

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

                              В любом случае я ваш метод не критикую, просто сейчас в нашей компании пытаемся внести большую организацию в веб-разработку и ваша статья очень кстати. И никак не могу переложить на наши внутренние процессы вашу организацию. :(
                                +1
                                >Но вот что мне не нравится больше всего, при продолжении работы программист и верстальщик делают commit и
                                >в интеграционном проекте build будут последние изменения сделанные кем-либо из pr1, m1. Это усложняет совместную разработку.

                                Почему после коммита обоих в build появится только один? Наоборот при коммите изменения сольются. А если не сольются, то второму надо будет сначала апдейт сделать, потом конфликты поправить.
                                Репозитарий на всех один. Программист и верстальщик просто сделали checkout в свои личные директории.

                                >Таким образом нет username.project.example.com/trunk, а есть project.example.com/trunk и в редких
                                >случаях project.example.com/branches/username (его «нужно» потом объединять с основной веткой разработки).

                                То, что вы называете project.example.com/branches/username есть почти то же самое, что и username.project.example.com/trunk. За исключением того, что в первом случае в репозитарии уже лежит модифицированный код, который надо сливать с основным проектом. А во втором случае модифицированный код лежит пока у конкретного программиста и ему нужно сделать commit в общую ветку.
                                  0
                                  > Почему после коммита обоих в build появится только один? Наоборот при коммите изменения сольются.
                                  > А если не сольются, то второму надо будет сначала апдейт сделать, потом конфликты поправить.

                                  согласен. немного стормозил. изменения сольются, но в любом случае если использовать предложенный post-хук это будет не так удобно делать (я имею в виду svn update перед коммитом в build).

                                  > Репозитарий на всех один. Программист и верстальщик просто сделали checkout в свои личные директории.

                                  > То, что вы называете project.example.com/branches/username есть почти то же самое, что и
                                  > username.project.example.com/trunk. За исключением того, что в первом случае в репозитарии уже лежит
                                  > модифицированный код, который надо сливать с основным проектом.
                                  > А во втором случае модифицированный код лежит пока у конкретного программиста и ему нужно сделать commit в
                                  > общую ветку.

                                  Странно как-то у вас написано. В первом случае вы говорите про репозитарий, а во втором сравниваете с рабочей копией. Я вроде так и не говорил никогда. Насколько я понял не важно как обращаешься к проекту
                                  pr1.project.example.com/trunk или pr2.project.example.com/trunk получаешь в рабочую копию данные из одного репозитория?

                                  Если это так, то я не понимаю фразу из статьи:
                                  — У себя, внутри студии, мы выбрали следующую схему:

                                  username.project.example.com/trunk
                                  По такому адресу сам разработчик и все члены команды получают доступ к наработкам друг друга.
                                    0
                                    >pr1.project.example.com/trunk или pr2.project.example.com/trunk получаешь в рабочую копию данные из одного репозитория?
                                    Я так понимаю, что здесб лежат рабочии копии программистов. Т.е. это не свн. Возможно я ошибаюсь.
                                      0
                                      Ага. Я наконец понял что это не свн. Это и был главный глюк. Просто нужно было описание работы с SVN в отдельный подраздельчик вынести.
                                      0
                                      Разобрался.
                      +3
                      Под линукс очень удобно использовать automount sshfs — вот подробная статья по настройке. Это по сути «монтирование по требованию».
                        +1
                        а в чем конкретно проблема с SVN и samba?
                        у нас аналогичная структура и все прекрасно работает и из консоли и через TortoiseSVN

                        т.е. нужда в ExpanDrivе отпадает
                          0
                          У нас не получалось закоммитить файл, который находился не в version control.

                          В то время как раз шло активно обсуждение в мейл-листе самбы на эту тему www.nabble.com/-PATCH--Working-copy-on-Samba-share-td19606426.html

                          Сейчас может быть ситуация с выходом новых версий изменилась.

                          У вас какая версия svn и самбы?
                            0
                            svn и 1.4.х и 1.5.х, про самбу точно не знаю, но такая система в нашей конторе уже сильно больше года работает
                              0
                              Вы пользуетесь сразу двумя версиями SVN для одного репозитария?
                                0
                                :) нет конечно — разные проекты, разные dev-сервера, разные репозитории
                              0
                              У нас в офисе настроено так же, как описано в статье. И тоже существует проблема с рабочими копиями на самбе. Причем эта проблема проявляется у разработчиков, которые пользуются линухом. Под виндой все нормально. Проблема (предположительно) заключается в несоответствии UID и GID серверного (из-под которого открывается досутуп к шаре) и локального (который пытается примонтировать) пользователей. Поэтому одно из решений, которое у нас успешно работает — изменить локальный UID/GID, приведя в соответствии с серверными. Я же принципиально пользуюсь sshfs, хотя испытываю дискомфорт от тормознутости.

                              Третья альтернатива — NFS, которая намного лучше подходит линух-пользователям, чем самба.
                                0
                                PS. Подтверждаю, что без опции workaround=rename работать невозможно ввиду интенсивных переименований в служебных папках SVN во время операций с деревом.
                            0
                            Хорошая схема, ее много лет назад обсуждали в инете и конфах, теперь думаю она с теми или иными вариациями у очень многих работает.
                              0
                              Странно, но у TortoiseSVN на виндовых машинах никогда проблем с шарами самбы проблем не было.
                                0
                                Eclipse + Subclipse — проблем на винде, линукс и макосе в шарами самбы проблем не имеет.
                                  –2
                                  А какой IDE, если не секрет? Eclipse?
                                    –2
                                    Спасибо за ExpanDrivе, не знал про нее. А бесплатные аналоги есть?
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                        0
                                        Похоже, совсем не используется удаленная отладка?
                                          –1
                                          Просто модуль для пхп добавить.
                                            +1
                                            Я не у вас спрашивал, но раз уж вы считаете это тривиальным, опишите какой модуль и как его следует настроить, чтобы множество разработчиков могло отлаживать и не блокировать работу друг-друга.
                                              0
                                              А разве одновременно возможна лишь одна сессия дебага? о_О
                                              я в phped втроенный юзаю, как вариант от zend'a отладчик или xdebug.
                                                0
                                                По-моему нет, но настройка xdebug.remote_host предполагает один постоянный хост.
                                                Просто интересно посмотреть как админ выпутается.
                                                  0
                                                  ой ли?
                                                  .htaccess:
                                                  ===
                                                  php_value xdebug.remote_host %my-remote-ip%
                                                  ===

                                                  Понятное дело, нужные опции для .htaccess из конфига Апача должны быть включены.
                                                    0
                                                    А если двое программистов работают над одним проектом (каталогом)?
                                                    Наверное через SetEnvIf можно
                                                      0
                                                      Боюсь, что ОДНА физическая директория для разработки проекта несколькими программистами — это ОЧЕНЬ тесно и плохо (при активной разработке и близких задачах). Причем считаю так, основываясь и на своем, отрицательном опыте в этом плане.
                                                        0
                                                        Ну так и что? они все равно так работают. В один файл index.php, в который с помощью modrewrite сгоняются все запросы. Это модно.
                                                        До тех пор пока не встает вопрос об отладке.
                                                          0
                                                          Приведу простейший пример: разрабатываются одинаково подключаемые одновременно модули, и для контроля «всё ли происходит как надо» оба программиста в своём коде добавляют var_dump(). После чего получаем взаимную феерию с, иногда, тяжкими последствиями.
                                                            0
                                                            Неважно что там у вас было на практике. Приложение УЖЕ построено наихудшим образом из кусков опенсорсных и самодельных велосипедов.
                                                            Предложите лучше красивую схему отладки и взаимодействия.
                                                              0
                                                              Дык, кажется, в статье о том речь есть: каждому по самостоятельной копии приложения, которую каждый в своей директории дорабатывает, многодоменность — через тот же mod_rewrite, сведение работающих и отлаженных доработок — через всё тот же svn.

                                                              Ну и отдельно, само собой, live-версия.
                                            0
                                            Вот и у нас такая же проблема — хотим использовать такую схему, но скорее всего нельзя будет использовать отладку одновременно для нескольких клиентов. Во-первых, у нас есть клиенты Windows (PHPEd, dbg) и Linux (Netbeans, xdebug), а прикрутить два модуля одновременно вряд ли получится. Во-вторых, даже если учитывать только клиентов Netbeans, сомневаюсь, что Netbeans умеет работать с отладочным прокси-сервером.

                                            Жаль, но без отладки никак.
                                              0
                                              А может быть всё-таки попробовать Eclipse-PDT + ZendDebugger? У него точно есть возможность много хостов указывать.
                                                0
                                                Eclipse-PDT, к сожалению, напрочь отказывается создавать проект (Битрикс)
                                            0
                                            Похоже, что в случае WiFi этот способ использовать комфортно не получится: Netbeans постоянно подвисал при скроллировании дерева проекта и при прочих операциях с файлами, а у нас был всего лишь один клиент…
                                              0
                                              А как монтировали директорию?
                                                0
                                                Как было сказано в топике, через sshfs с настройкой workaround=rename
                                                  0
                                                  Попробуйте примонтировать с использованием компрессии или кэшированием:
                                                  ...
                                                  -C equivalent to ’-o compression=yes’
                                                  ...
                                                  -o cache=YESNO enable caching {yes,no} (default: yes)
                                                  -o cache_timeout=N sets timeout for caches in seconds (default: 20)
                                                  -o cache_X_timeout=N sets timeout for {stat,dir,link} cache
                                                    0
                                                    Спасибо за совет, кажется после включения компрессии стало немного побыстрее. В любом случае, похоже, что проблемы возникают из-за того, что первое сканирование
                                                    проекта происходит на сервере. Попробую отсканировать локально и закачать на сервер папку nbproject/.
                                              0
                                              а база на проект общая для всех разработчиков? :)
                                                0
                                                БД всмысле
                                                  0
                                                  Как вам удобнее. Можно без проблем обойтись одной, можно приложение настроить, чтобы для каждого разработчика подхватывало различный dsn.

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

                                              Самое читаемое