Продуктивность коллектива веб-студии напрямую зависит от удобства среды разработки. У нас сложилась стройная система организации работы с проектами, включающая в себя набор таких неотъемлемых компонентов, как IDE, SCM, PM-система, багтрекер и development-сервер. Этим постом я бы хотел начать цикл статей, посвященных настройке и использованию этих компонентов в нашей студии.
В первой части я расскажу о самом основном — среде разработки (о том, как мы организовали совместный доступ к проектам).
Основа концепции заключается в том, что разработка всех проектов ведется на одном сервере. Плюсы очевидны:
1. Мы избавляемся от многочисленных настроек на машинах сотрудников
Все уже настроено один раз на сервере, поэтому не нужно тратить время ни системным администраторам на настройку внутренней сети для обеспечения доступа к каждому из компьютеров, с другой — сами разработчики экономят свое время на настройке, если им потребуется поработать удалённо.
2. Единая конфигурация серверного ПО
Во многих проектах есть определенные требования к серверному ПО. Если эти требования сразу будут заданы при разработке на сервере, то это может значительно сэкономить время на этапе тестирования и переносе на продакшн. Отпадает необходимость в синхронизации версий ПО на компьютерах программистов с рабочим сервером (например, при обновлении апача, пхп и т.п.)
3. Совместный доступ к рабочей копии каждого сотрудника
То, что в данный момент разрабатывается одним человеком на его workspace, другие могут сразу же увидеть из веба. Также, как и последнюю общую версию из репозитория системы контроля версий.
4. Экономия ресурсов
Мы очень часто слышим от наших знакомых рассказы о том, как им плохо живется из-за того, что работодатели пожалели денег на нормальный компьютер. В подобных ситуациях экономия ресурсов будет очень полезной, функции веб-сервера и интерпретатора снимаются с локальной машины.
Минусами этой концепции являются требования к скорости и надёжности сети и недостаточная гибкость индивидуальной настройки ПО под каждый проект в отдельности. В нашем случае плюсы значительно превосходят минусы :)
Если весь код при разработке интерпретируется на сервере, то как организовать к нему удобный доступ?
Просмотр.
У себя, внутри студии, мы выбрали следующую схему:
По такому адресу сам разработчик и все члены команды получают доступ к наработкам друг друга. Для контроля версий мы используем SVN (схема unstable trunk, stable branch), создавая по репозиторию для каждого проекта, соответственно, мы обращаемся к нужной ветке, указывая её путь (/trunk; /branches).
Редактирование.
Самое удобное для разработчиков — это видеть файлы проекта без отделения их от файловой системы ОС. Поэтому, каждый разработчик, чтобы начать работать с проектом, просто монтирует свою директорию на сервере к себе на локальную машину.
Как ни странно, но с реализацией все очень просто.
Bind
Естественно, если мы хотим получить домены вида username.project.example.com, то необходимо добавить следующую строчку в файл зоны:
Все поддомены подходящие по маске *.example.com, будут адресованы на адрес вашего веб-сервера.
Apache
Теперь, нужно научить веб-сервер обрабатывать наши домены и адресовывать их к нужной директории. Рабочая директория на сервере для разработчика выглядит следующим образом: /var/www/username.example.com/project/trunk/htdocs/
Может быть, правильнее было бы хранить все в /home/username/.
Настраиваем виртуальные хосты:
Монтирование рабочей директории
Локальные машины девелоперов могут работать под разными ОС, и настройка в каждом из случаев может отличаться.
Линукс
Протокол ssh (если у вас сервер так же, как и клиент под linux или unix) является родным, поэтому, создав каждому из разработчиков пользователя на сервере, монтирование директории осуществляется одной командой:
Параметр workaround=rename нужен для корректной работы с svn.
Виндоус
Тут все, как обычно, несколько сложнее, придеться использовать дополнительный софт, мы выбрали ExpanDrivе, программа позволяет примонтировать директорию по ssh.
Логичным было бы использовать Самбу на сервере, чтобы отказаться от использования дополнительного софта, но, к сожалению, попытки подружить Самбу с svn не увенчались успехом, сделать checkout из svn в примонтированную директорию не получится. Сейчас, может быть, ситуация изменилась, но год назад тикет в багтрекере самбы на тему совместимости с svn был открыт.
Мак
Тут два варианта, можно использовать ssh: для монтирования директории подойдет приложение Macfusion; можно использовать нативный AppleTalk, тогда примонтировать директорию можно будет через Finder.
Поддержку AppleTalk можно организовать с помощью установки пакета netatalk. Для настройки потребуется добавить в файл /etc/netatalk/AppleVolumes.default строчку:
Теперь в Finder можно нажать ⌘+K и в поле адрес вводим afp://username@example.com/username.example.com
Данная концепция подойдет как основа среды разработки для большинства небольших студий. При этом она очень гибкая и просто расширяется, например, для добавления одного проекта или нового разработчика достаточно создать соответствующий каталог и добавить пользователя в систему.
В первой части я расскажу о самом основном — среде разработки (о том, как мы организовали совместный доступ к проектам).
Идеи
- Среда разработки должна быть единой для всех сайтов.
- Девелоперы не должны тратить время на настройку каждый своей серверной части.
- Работает ли над проектом один человек или несколько — контроль версий необходим.
- Если рабочий каталог (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
Заключение
Данная концепция подойдет как основа среды разработки для большинства небольших студий. При этом она очень гибкая и просто расширяется, например, для добавления одного проекта или нового разработчика достаточно создать соответствующий каталог и добавить пользователя в систему.
