ShvetsGroup

 

Captions

RSS Следите за нашим блогом и будьте в курсе последних новостей.

 

Инфраструктура ShvetsGroup: окружения разработки и сервера

  • Аватар пользователя neochief
4 комментария

Инфраструктура ShvetsGroup: окружения разработки и сервера

iStock_000011296304XSmall.jpg

У каждой серьезной команды разработки со временем возникает надобность в стандартизации окружений разработки. Мы разделяем их на несколько типов:

  • Инфраструктура разработки в головном офисе.
  • Внешние сервера.
  • Локальные машины удаленных разработчиков.

Офисная инфраструктура

Каждое рабочее место разработчика представляет собой средне-мощную машину (Acer Aspire X3200), задача которой хорошо крутить офисный софт, тяжелые IDE типа Eclipse, Net Beans и прочих. Разработчик может использовать на ней как Windows (в большинстве случаев), так и Linux.

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

  • Локальный веб-сервер на Windows (в основном, Денвер) довольно медленная штука.
  • На локальный веб-сервер на Windows трудно ставить дополнительный Linux-софт (как то кодеки ffmpeg, memcached и прочее).
  • В случае Linux, у всех могут быть разные дистрибутивы, что тоже усложняет развертывание проектов в некоторых случаях.
  • Разработчики не могут посмотреть на локальные версии коллег.

Мы решили все эти проблемы покупкой относительно мощного сервера в офис, на котором установлен и работает веб-сервер и локальные песочницы разработчиков, с которыми они работают по сети.

Расскажу подробнее как это работает:

  • У каждого разработчика есть своя домашняя директория (напр. /home/misha) на сервере.
  • На сервере крутится Apache с модулем mod_vhost_alias, который создает vhost-ы в апаче для домашних директорий пользователя. Например, /home/misha/www/superproject доступен у нас по адресу http://superproject.misha.local/.
  • На сервере стоит Bind, который раздает локальные домены пользователям сети, чтобы приведенные домены открывались у всех в браузерах.
  • На сервере стоит Samba, которая дает возможность подключить сетевой диск к своей домашней директории (напр. /home/misha) на сервере. При этом, заведение новой песочницы по трудозатратам равно созданию папки (в /home/misha/www). С самого начала были сомнения, не будет ли это тормозить, т.к. скорость ограничена каналом подключения к серверу по сети, но как показала практика, достаточно обычного wifi подключения к серверу, чтобы все работало как часы.
  • При этом всем, доступ к песочницам других людей не ограничен ни на просмотр, ни на редактирование (вы можете как открывать их в браузере, так и коннектится по сети), но потенциально может быть ограничено разработчиком установкой соответствующих прав на файлы.
  • Работает SSH доступ на сервер.

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

Внешние сервера разработки

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

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

Облако Amazon

Данная проблема витала в воздухе пока мы не познакомились с облачными сервисами Amazon EC2. В двух словах, эти сервисы позволяют вам поднимать сервера разных конфигураций с оплатой за то, сколько вы по-факту использовали (например, 3 часа работы сервера + 3 гигабайта сетевого трафика), в различных регионах планеты (США, Европа, Сингапур). Поэтому, главное, что стоит понимать об амазоне — он позволяет в любой день за 5 минут арендовать 20 серверов с 60 гигабайтами памяти каждый на пару часов. С классическими хостингами вы такого не сделаете.

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

Сервера разработки тестирования

В общем случае, сервера тестирования у нас построены по похоже модели с офисным — для сервера существует домен, и с помощью mod_vhost_alias, можно получать доступ к произвольным проектам, и пусть к этим экземплярам будет выглядеть как домен третьего-четвертого уровня (напр. http://superproject.test.shvetsgroup.com/). На уровне конфигурации, разница составляет в том, что «главными» на сервере разработки являются проекты, а не разработчики.

Я много раз видел, как компании давали каждому разработчику рутовый доступ на сервера разработки и репозитории. К чему это может привести знают многие, особенно при привлечении еще не проверенных удаленных работников и команд. Для нас это было и есть особым моментом, поэтому для серверов тестирования/разработки соблюдается строгое разграничение прав доступа к проектам сервера, как извне, так и самими разработчиками. Никто из разработчиков не имеет доступа к "соседним" проектам на севере вообще, а веб-доступ к проектам закрыт http авторизацией (это также защищает от нежелательной индексации тестовой версии проекта поисковиками).

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

Сервер организационного ПО

Еще одна Amazon-машина, на которой хостятся SVN-репозитории, багтрекер и система документации (подробно об этом читайте во второй части).

Локальные машины удаленных разработчиков

Очевидно, мы никак не можем повлиять на железо/ПО, используемое на «той стороне», тем не менее, за все время работы, мы составили некоторый список того, чем должен владеть успешный удаленный разработчик для эффективной работы:

  • Широкий интернет канал (от 2Мб/с)
  • Бекап-интернет канал. Очень важная вещь, которая требуется именно тогда, когда ее нет. Здесь подойдет как дополнительный проводной провайдер, так и хотя бы доступ через подключенный мобильный телефон (GPRS/EDGE/3G), либо 4G (Yota/FreshTel).
  • Добротная рабочая машина, с двумя ядрами и 4GB оперативной памяти. Linux или Windows с виртуальной машиной для веб-сервера (не Денвер).
  • Большой монитор (от 22 дюймов), а лучше два, с хорошей цветопередачей.
  • Skype с форвардингом на телефон; хорошая, качественная гарнитура и веб-камера.

Комментарии

Johnny
3 января, 2011

>Офисная инфраструктура
Несколько вещей, о такой системе:
1. При больших проектах IDE просто начинают виснуть при сканировании и индексации. Приходится открывать отельные модули, либо использовать 5.5 Zend )
2. При добавлении новых файлов/папок в svn присходит проблема с пермишиннами. Так и не вышло адекватно обучить самбу, а может проблема и svn.
3. Лучше на серваке поднять raid. Оно того стоит.

Александр Швец
6 января, 2011

1. Пока не сталкивались, вероятно потому что все используют облегченные тулзы типа PHP Storm.
2. Да, проблема известная, но мы ее решили. Проблема возникает из-за неправильных умолчаний разрешений. Вот здесь описаны решения: 1, 2.

zolexiy
10 февраля, 2011

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

Иван
17 февраля, 2011

> Linux или Windows с виртуальной машиной для веб-сервера
А для чего нужно обязательно выносить веб сервер на виртуалку?
Чем плох сервер запущенный в той же рабочей среде?

Хотите что-то добавить?