Nerrvana в работе – как это делается у нас

Three whales - version control, continuous integration, Selenium

Part 1 – Nerrvana в работе – как это делается у нас – этот пост
Part 2 – Nerrvana в работе – SVN втыкается в Jenkins
Part 3 – Nerrvana в работе – сборка приложения и Jenkins (часть 1)
Part 4 – Nerrvana в работе – сборка приложения и Jenkins (часть 2)

Виктор закончил работу над первой публичной версией Jenkins плагина для облака Selenium тестирования Nerrvana, настроил Jenkins, и теперь тесты наших Answers запускаются автоматически. Пока Виктор занимается дооформлением плагина и выкладыванием его на GitHub, чтобы он стал доступен и на странице плагинов Jenkins-a, я занялся созданием новых страниц документации, связанных с плагином. Я мог бы, конечно, просто описать, как установить плагин, но мне показалось, что есть возможность сделать это лучше. И поэтому я решил написать не только о том, как установить плагин, но и о том, как процесс тестирования организован у нас и даже о том, как и почему мы организовали этот процесс и что обсуждали по ходу дела. Конечно, это будет один из возможных путей, но он позволит полнее представить, как можно организовать Selenium тестирование у себя и, надеюсь, будет полезен даже в том случае, если вы будете использовать не Nerrvana, а свою Selenium среду или решения, предлагаемые другими компаниями.

После достаточно долгих обсуждений мы остановились на следующем подходе:

1. После коммита в SVN-репозиторий срабатывает post-commit hook

2. SVN-хук сообщает Jenkins об этом событии.

3. Jenkins разворачивает (deploys) приложение, или, попросту говоря, берёт закоммиченную вами версию и устанавливает её на одном из выделенных для этой цели серверов в нашем оффисе.

4. Jenkins, используя Nerrvana плагин, синхронизирует код тестов, которые уже были извлечены из SVN-репозитория на шаге 3, с тестами, которые уже лежат на Nerrvana, и запускает тесты.

5. По окончании тестирования неплохо было бы отправить коммитеру письмо со статусом выполнения (выполнились ли тесты или завершились фатально), и сколько ошибок (кратенько) они накопали. Пока* будет достаточно просто письма со ссылками на отчёты с каждой платформы.

* – в будущем мы планируем загружать результаты тестирования с разных платформ обратно в Jenkins и собирать один агрегированный кросс-платформенный отчёт. Конечно, в этом случае будет логично отсылать почтовые уведомления уже из этой aggregate_notify Jenkins задачи. Без такого подхода придётся просматривать 5-6 отчётов с каждой платформы, на которой тестировали.

Теперь несколько слов о том, что же мы обсуждали и почему реализовали именно такую схему.

Как часто запускать тесты?
Тесты, конечно, можно запускать периодически. Например, каждый рабочий день вечером или два раза в день. Аргументы против такого подхода следующие:
- будет непонятно, чей коммит поломал приложение или чьи изменения в тестах содержали ошибки. Запуск тестов по коммиту также локализует код, содержащий ошибки, более точно
- бывают дни, когда коммитов просто нет, так как мы работаем и над другими проектами, где тестирования с Selenium вообще нет или такими, где их ещё нет. В этом случае запуск тестов по расписанию просто отработает вхолостую.

Давать ли возможность Jenkins ждать некоторое время прежде чем забирать код из SVN-а?
Изначально решили ждать 5 минут, потому что часто одно большое изменение коммитится несколькими логическими кусками.

Jenkins quiet period in advanced tab

При таком подходе коммиты 12, 13 и 14, прошедшие в течение 5 минут, приведут к тестированию ревизии 14. Однако недостатком такого подхода является тот факт, что нужно укладываться в этот заранее заданный период. Иногда результаты хочется получить побыстрее, иногда – наоборот, нужно какое-то время подождать связанных коммитов. При таком подходе также нет гарантии, что коммит ревизии 14 в нашем примере тоже будет сделан вами. Может оказаться, что коммитер ревизии 14 тоже расчитывает на 5 минутное ожидание. В результате количество поломанных тестов будет больше, и времени на “разбор полётов” потребуется тоже больше.
Решили, что лучше использовать специальный тег “#noselenium” в тексте коммита. Если его нет, то Selenium тесты запустятся. Такой подход хорош тем, что не нужно помнить о 5 минутах. Если вы коммитите файлы Unit тестов или, например, документацию – то, что не требует Selenium, – вы просто включите #noselenium в текст вашего коммита. У этого подхода, казалось бы, есть недостаток – нужно не забыть добавить #noselenium в коммит, но нашлось простое решение. Все мы пользуемся TortoiseSVN и есть способ добавить нужный нам тег в сообщение коммита через темплейт. Таким образом останется только оставить его в комментарии коммита если данный коммит не последний или изменение не требует запуска Selenium в принципе.

Что делать с задачей Jenkins, запускающей PHP toolchain?
В самом начале Виктор установил такую последовательность задач Jenkins – коммит запускает PHP toolchain, потом разворачивается тестируемое приложение (одна задача – Jenkins job) и запускаются Selenium тесты на Nerrvana (вторая задача – Jenkins job). Мы решили выделить запуск PHP toolchain в отдельную и независимую задачу и запускать её всегда (отсутствие тага #noselenium не влият на запуск этой задачи). Selenium-тесты запустятся быстрее, так как они не ждут выполнения этой задачи.

Как обеспечить доступ к Jenkins, находящемуся в Харьковском офисе, с SVN-сервера, находяшегося в Newark, NJ, USA ?
SVN-хук должен иметь возможность обратится по HTTP к Jenkins. Jenkins у нас установлен в офисе в Харькове. Наш SVN-сервер находится в компьютерном центре Linode в Newark, NJ, USA. Конечно, можно было бы отфорвардить порт с публичного адреса харьковского офиса на внутренний, но мы поступили иначе, создав локальный slave-репозиторий. Предложение было сделано нашим сисадмином – Вадимом.

SVN master and slave work with Jenkins commit hook

SVN master and slave work with Jenkins commit hook
(click to enlarge)

Теперь коммитить можно в оба репозитория, но коммит в репозиторий, установленный в Харькове – slave, на самом деле перенаправляется на сервер в США. Там svnsync, который тоже, кстати сказать, инициируется SVN-хуком, синхронизирует изменение с сервером, установленным в Харькове, и вот тут срабатывает хук для Jenkins, который будет запускать задачу развёртывания приложения для тестирования Selenium-ом. Таким образом, репозиторий в офисе только для чтения, но SVN-хук на нём всё равно срабатывает, когда изменения поступают в процессе синхронизации с SVN-сервером в США. Подробнее о синхронизации SVN можно прочитать в этой статье. При таком подходе не нужно открывать Jenkins наружу, ну и вероятность, что хук не достучится до Jenkins, уменьшается, так как они находятся теперь в одной локальной сети.

Описанный подход был реализован Виктором в нашем Харьковском офисе. Он же, по моей просьбе, записал шаги по настройке и установке всех компонентов, но изначально было понятно, что для написания подробного руководства мне придётся повторить этот процесс ещё раз самому, дополняя работу Виктора и исправляя неточности. В нашем Харьковском офисе железо используется очень плотно. Там и тестовая версия Nerrvana, и достаточно сложные в установке девелоперские версии систем наших клиентов, и Jenkins. Мы интенсивно используем Xen, с которым подружились в процессе создания Неррваны. Мне же не хотелось “путаться под ногами” в и так достаточно сложной среде в поисках дополнительного места и ресурсов для виртуальных машин, чтобы написать что-то действительно полезное и понятное. Тогда я решил – а почемы бы мне не построить свою собственную среду у себя дома (пардон, в нашем Сиднейском офисе)? Для этого мне нужны 2 машины. На одной будет установлен SVN-сервер и Jenkins, на другой – будет разворачиваться WAUT (Web Application Under Test).

Set up to document Nerrvana plug-in

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

Всё, что вы видите на рисунке, на самом деле одна машина Windows 7 с VMWare Workstation 8 на борту. Слава чудесам виртуализации! SVN/Jenkins и WAUT – виртуальные машины CentOS 6.2. Между прочим, я недавно писал о минимальной установке CentOS 6.2 на VMWare Workstation 8 с помощью кикстарт файла в нашем блоге. Далее я отфорвардил на ADSL модеме свой публичный IP адрес на IP адрес сервера WAUT, предоставив таким образом доступ к нему с Nerrvana. Если вы будете делать нечто подобное и ваш провайдер не даёт вам статический адрес, вы можете воспользоваться услугами DynDNS, поскольку большинство модемов поддерживают этот сервис.

Проделав эту работу, я смог описать, как всё собиралось и настраивалось настолько подробно, что следующий пост не вместит в себя весь процесс, а будет посвящён только связке SVN/Jenkins. Затем будет пост о разворачивании приложения для тестирования и в самом конце пост рассказывающий о том, как создать задачу Selenium тестирования в Nerrvana и как вызывать её по-окончанию задачи установки приложения для тестирования.

Print this post | Home

Comments are closed.