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

[Drakon]

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

Есть 2 сервера, на которых работает несколько интернет-проектов - на данный момент 3 вида каталогов скидок, саун по разным городам России. Всё работает на самописном движке, но планируется ведение ещё нескольких отдельных проектов и переход на какой-то достаточно развитый PHP-фреймворк. Также есть дополнительный сервер которые используется в качестве тестового.

Возникают несколько проблемных аспектов:
1. Каким образом лучше всего организовать подключение новых программистов к работе? Учитывая, что все работают по удалённой схеме - часто из других городов, нормальное собеседование провести нет возможности, поэтому единственный вариант который я вижу - поверхностное собеседование и сразу подключение программиста к практическим задачам (сначала несложные, чтоб присмотреться к качеству кодирования, потом посложнее) - всё это через SFTP-протокол на тестовом сервере.
Далее если человек осваивается и работает - можно уже выделить время и развернуть на его компьютере локальную версию сайта.
2. Тут же возникает вопрос с тестовыми серверами - если много программистов, значит должно быть много тестовых серверов... Например чтобы отлаживать рекламу необходимо, чтоб имя хоста в адресной строки браузера было оригинальным, а не что-то типа test1.основной_домен.ru. Выход вижу такой - сделать несколько копий кода на тестовой сервере, каждому программисту поставить cookies типа testServerId=[1,2,3,...] и nginx'ом по этой куке отправлять к разным инстансам апача либо в апаче отлавливать куку и брать файлы из разных директорий.
3. Далее вопрос про то, что несколько программистов могут делать изменения в одном и том же файле, плюс нужно чтоб они получали изменения от других программистов. Тут придётся использовать кодовый репозитарий. Как вариант рассматриваю git, сейчас он уже используется, но только для связи моего компа и боевого сервера. Здесь наверное лучше организовать так - на каждую копию сайта на тестовом сервере можно стягивать код с продакшена, но заливать на продакшн нельзя. У каждого программиста должна быть своя релиз-ветка типа 'vasya-release-branch'. Программисты с локальных машин загружают изменения на тестовый сервер, я стягиваю их к себе, делаю merge с мастер-веткой и заливаю на боевой. Другие альтернативы могут быть?
Кстати непонятно, как на git'е сделать, чтоб человек мог видеть только часть исходников, это вообще реализуемо или лучше использовать что-то типа svn/mercurial?
4. Вопрос актуальности структуры БД на тестовом сервере и на компьютерах программистов. Как это решить? Как вариант вижу репликацию MySQL с боевого на тестовый. А вот на компах программистов - хз.
5. Каждому программисту нужен ssh-доступ к тестовому серверу, причём чтоб он ничего не сломал на тестовом сервере - тут наверное лучше всего пойдёт chroot-среда для каждого.
6. Организация документации и автоматического тестирования - кто сталкивался с такой задачей в случае распределённой команды?
7. Кто-нибудь видел детальные сравнения PHP-фреймворков типа ZF, Symfony 2, CodeIgniter, CakePHP, Yii, Prado. Всё, что нахожу какое-то поверхностное.

Готов выслушать критику, замечания, вопросы.

 

[Dovg]

Не буду спорить или тем более учить, но расскажу как сделано у нас.

1. первая задача нового программиста (после тестового занятия и всех юридических формальностей) - развернуть у себя окружение. Для этого нужно сделать "svn co" всех нужных проектов, настроить веб-сервер, поднять базу, установить софт, которого еще нет ну и т.д. В плане выбора дистрибутива у нас полная демократия, можно выбирать любой linux. Единственное о чем мы просим - дистрибутив должен иметь архитектуру amd64, чтобы не ловить лишние баги.
От программистов мы код не скрываем. ИМХО это вопрос доверия. Если вы не доверяете человеку, просто не берите его на работу. да и как мы все знаем, код никому не нужен

2. Каждый программист (а сейчас и каждый тестер) имеет свое личное тестовое окружение. Формат - user_name.project_name.testserver.ru Как правило они работают с общей базой, но если программисту требуется внести несовместимые правки в схему данных, то он предварительно делает копию базы и только после тестов вливает изменения в основную ветку.
Отдельно имеется окружение с именем trunk.project_name.testserver.ru, которое соответствует транку. Там мы делаем регресс перед выкладкой.

3. Да, система контроля версий нужна у нас svn, по историческим причинам. Если бы выбирали сейчас, то это был бы git, ибо svn merge по сравнению с git - это адовый геморрой. Каждая новая фича делается в бранче. Вообще все делается в бранчах, а в транк попадают уже протестированные изменения (ну за исключением форс-мажора).
Бранчи именуются по след. правилам
* если на фичу есть тикет (у нас trac), то в имени бранча должен быть номер тикета, например ticket-11666-newFreePorno
* если тикета нет, но у фичи есть имя, то бранч содержит имя это фичи. Например новые плановые релизы у нас проводятся без тикетов. В этом случае бранч будет иметь имя newFeatureName
* если хочется потестить, либо что-то обкатать, то создается бранч с именем разработчика и опционально именем фичи, например dovg-Trololo
Соответственно в любое тестовое окружение можно зачекаутить любой бранч. У нас сейчас этим занимаются сами тестировщики. Обучились за полдня.

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

5. Тестовый у нас является набором виртуалок. Программисты и тестировщики имеют sudo там, где им это необходимо. Злые намерения мы исключаем, а в случае вреда по неосторожности тестовое окружение можно поднять и с нуля. Это быстро.

6. trac. Сейчас тестировщики внедряют jenkins, но это почти полностью мимо меня проходит, похвастаться не могу.

7. ... // у нас onphp

ps. Ни в коем случае не навязываю данный подход.

 

[samoshin]

1. Полностью согласен с Dovg. От себя добавлю, что возможно стоит организовать wiki с описанием процесса развертывания локального окружения. На данном этапе уже можно будет отсечь совсем слабых кандидатов.

2. Сначала не понял про рекламу. Получается чтобы тестировать рекламу, нужен один тестовый сервер с заданным адресом, например testovy.ru? Если так, то пока не могу предложить схемы отличной от той что ты предложил, не сталкивался.

3. С git не работал. Про svn могу сказать, что действительно есть геморой при объединении веток. Поэтому схема была следующей (2 варианта):
1. Каждый забирет себе копию транка, стабильные изменения комитятся туда же. Отладка идет на тестовом сервере - копия берется из того же транка. Когда на тестовом сервере все ок, изменения забираются на рабочий сервер.
2. Для рабочего и тестового сервера отщепляется бранч. Программисты забираю транк и комитят в транк. Мажорные изменения мерджатся сначала на тестовый сервер, после отладки делается слияние на продакшене.

По схеме описанной Dovg, думаю будет более грамотно. Но в svn будет гребля с бранчами.

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

5. Можно организовать виртуалки, например через http://wiki.openvz.org/Main_Page - вариант проверенный, но затратный по ресурсам. С chroot не сталкивался, но судя по докам тоже неплохой вариант.

6. Лучшая документация, как известно, подробное описание кода в комментариях. Нужно выработать стандарнтный подход к написанию комментариев, тогда в последующем можно легко использовать системы создания документации из комментариев, например phpDocumentor, или активно развиваемый на его базе Docblox (http://habrahabr.ru/blogs/php/127804/).

7. Плотно сталкивался с CakePHP, Symfony, поверхностно с CodeIgniter. Cake и Igniter - очень просты, на них легко начать строить свое приложение. Документация хорошая, примеров много. Беда Cake в том что он поддерживает php4 и код плохо прочитывается различными средствами, которые поддерживают автодополнение, ну и соответсвенно от ООП там мало чего. Symfony - достаточно сложный фреймворк. Чтобы начать на нем нужно сначала читать доки, с наскока не получится. Он использует ООП по полной, отлично документирован, в том числе доки на русском языке. Очень много плагинов и отличная поддержка проекта. Для больших нагруженных проектов лучше Symfony самое оно.

 

[Dovg]

troll mode on:
>Лучшая документация, как известно, подробное описание кода в комментариях.
Лучшая документая - есть исходный код.
troll mode off

Про рекламу, кстати, не понятно. Как связан показ рекламы с необходимостью ровно одного тестового сервера?

 

[samoshin]

Лучшая документация - есть исходный код.

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

 

[Drakon]

Не буду спорить или тем более учить, но расскажу как сделано у нас.

troll mode on:
>Лучшая документация, как известно, подробное описание кода в комментариях.
Лучшая документая - есть исходный код.
troll mode off

Про рекламу, кстати, не понятно. Как связан показ рекламы с необходимостью ровно одного тестового сервера?

Есть яндекс.директ и гугл-адсенс. Они отображаются только в том случае, если в адресной строке браузра указан хост, к которому они привязаны. Т. е. если у меня проект на котором реклама висит на адресе site1.ru то и на тестовый сервер чтоб отлаживать размещение и показ рекламы я должен заходить через site1.ru (т. е. придётся поправить у себя на машинке файл /etc/hosts).

Про проектную документацию как лучше делать?
Я думаю надо как-то разбить по такой схеме
1. Wiki Общая документация для программистов (структура кода, список типовых приёмов кодирования, стиль кодирования, как выполнять тестирование и т. д.)
2. К каждой функции и классу давать комментарий. Всё это собирать phpDocumentor'ом - получится документация по функционалу.

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

 

[Dovg]

>Они отображаются только в том случае, если в адресной строке браузра указан хост, к которому они привязаны
А, теперь понятно.
У нас была подобная необходимость правда для других целей - мы фильтровали в nginx по куке или подстроке в user_agent

                        if ($http_user_agent ~ "developer") {
                                fastcgi_pass to-test;
                        }

 

[samoshin]

1. Wiki Общая документация для программистов (структура кода, список типовых приёмов кодирования, стиль кодирования, как выполнять тестирование и т. д.)
2. К каждой функции и классу давать комментарий. Всё это собирать phpDocumentor'ом - получится документация по функционалу.

Согласен. Об этом и писал.

 

[grigori]

ребята, вам надо на пару романы писать, в соавторстве!

 

[iceman]

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

 

[флоппик]

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

 

[Dovg]

>что за чушь про исходный код?
олололол

Есть мнение, что код должен быть самодокументируемым, чтобы другой программист, читая код, сразу его понимал и не пытался тыкаться во все файлы.
Единственное исключение ИМХО - это неочевидные куски бизнес-логики, которые не понять, не зная требований.
Может пойдем в другую тему, поспорить?

 

[Drakon]

На самом деле, опытные программисты не любят комментарии. Ни писать, ни читать.

Не всегда есть возможность нанять опытных... Да и найти их не так уж просто в условиях удалённой работы.

С Dovg полностью согласен - документировать нужно функции и классы + неочевидные моменты бизнес-логики.

Есть ещё вопрос - каким образом лучше всего поддерживать на тестовом сервере актуальность базы? Появилась такая идея - сделать скриптик, которые будет из продакшна брать около 10% базы (заранее её подготавливать - т. е. сносить все пароли и др. конфиденциальную инфу) + всё схему и закачивать на тестовый. Скрипт может выполняться по запросу программиста + возможность получить эту инфу в виде дампа. По-моему очень удобно, если накосячил с базой и при включении в работу нового человека.

 

[fixxxer]

Заведи каждому по девел базе и храни эталонный sql дамп, например.

 

[Drakon]

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

 

[tz-lom]

Drakon
если это доктрина - генери,кто же мешает?

 

[Drakon]

Сейчас у нас нету ORM, только планируем в будущем переход. А наладить процесс разработки нужно уже сейчас.

 

[AmdY]

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

 

[Drakon]

Решил-таки всё упростить.
Пока не вижу смысла в тестовом сервере на каждого программиста - лучше пусть у себя нормальную среду разработки поднимают. А тестового хватит одного - для тестирования масштабных изменений.
За основу работы с репозитариями взял такую схему - http://habrahabr.ru/blogs/Git/75990/ - но только получилось упростить - выкинул оттуда 2 лишних репозитария - dev (за счёт того, что через hook'и наладил в bare репозитарии на продакшене кто в какие бренчи может писать код) и выкинул репозитарий production - опять же за счёт хука сделал просто обновлене рабочего дерева в другом каталоге при загрузке мной коммита в master-ветвь.

Насчёт базы чего-то простую и прозрачную схему никак не придумаю... Вот программист делает какую-то задачу у себя на компе, вот он сделал пару изменений в структуре базы и добавил/удалил некоторые строки в БД. Я так понимаю AmdY предлагает отловить через phpmyadmin сделанные изменения... А как их увидеть мне и накатить на продакшн? Может лучше чтоб к каждому коммиту программист прилагал SQL-файл с запросами, которые надо выполнить чтоб установить коммит... Бывает кстати что SQL-файл недостаточно, а нужно выполнить целую программу - опять же получается, что нужно приложить файл. У кого какие мысли?

 

[fixxxer]

Если хочется все прям сурьозно, посмотри как устроены миграции в symfony или ruby on rails.

А в принципе вполне достаточно набора alter-ов и скриптов для конвертации, которые куда-то там комитятся. Ответственный за деплоймент в любом случае должен быть в курсе, что там зачем.