tr0mb Mar 30 2015 at 16:43

Процесс разработки и тестирования демонов

7 min

19K

Badoo corporate blogIT systems testing*Web services testing*

+28

Comments 14

aml Mar 30 2015 at 19:23

Спасибо за статью. Скажите, а регрессии производительности вы на этом же этапе ловите?

tr0mb Mar 30 2015 at 20:51

Для того, чтобы полноценно проверить производительность демона нужно дать нагрузку, сопоставимую с нагрузкой боевых демонов. К сожалению, для того, чтобы сделать это в тестах ресурсов сейчас нет, но благодаря тому, что демон не сразу выкатывают на продакшен, многие проблемы находят на предварительных этапах — фаталы могут поймать и функциональные тесты, а на тестовом окружении devel также могут вскрыться проседания. Сама же выкладка на продакшен осуществляется в несколько шагов — сначала только для некоторых стран, и только потом уже по всему миру. Отдел мониторга, если ловит какие-то аномалии на одном из этапов, сразу сообщает об этом.

saboteur_kiev Mar 30 2015 at 19:29

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

А насчет чистки после возможных «фатальных» ошибок, вы не думали использовать готовые виртуальные машины?
В простеньком велосипеде это может выглядеть как
1. скопировать образ готовой и настроенной «чистой» виртуальной машины в из каталога образов на тестовую машину.
2. Запуск виртуальной машины и подключение к ней по ssh, копирование и установка вашего нового демона
3. Запуск и тестирование.
4. Остановка виртуальной машины, удаление «отработанного» образа, или перемещение его в папку, если вдруг нужно будет посмотреть что там случилось.

В случае тестирования демонов, можно образ создать без gui, совсем маленький, то есть ресурсов потребуется на порядок меньше, а качество и надежность тестов увеличится.

tr0mb Mar 30 2015 at 21:04

Вы правы, сам процесс имеет много чего, что можно встретить при разработке других продуктов — git, jira и т.д. Специфика, как обычно, в деталях — как мы собираем демоны, артефакты и как выкладываем, тестируем.
Про виртуальные машины мы думали, но до недавнего времени мощностей для повсеместного внедрения в процесс не было. Сейчас мы ориентированы на использование docker-контейнеров — эксперименты уже проведены, результаты нам понравились и по-тихоньку начинаем использовать их в тестах.

hanovruslan Mar 30 2015 at 19:30

Интересно бы было узнать, как тестируются обновления, которые меняют поведение работающих демонов в данный момент на продакшене. Внутреннее версирование? Токенизация?

tr0mb Mar 30 2015 at 21:11

Если кратко — прогоняется регрессия, проверяется новое поведение и пишутся тесты, выкладывается на devel, и, если все хорошо, отправляется на продакшен. Процесс выкладки немного описал выше в комментариях.
Внутренне версирование есть.

dmx102 Mar 30 2015 at 19:32

Мне одному кажется, что заголовок не отражает сути статьи?
было бы интереснее узнать от вас, какие языки используете и для каких задач, как работаете с БД, обрабатываете большие объемы данных, как высвобождаете память, с какими трудностями вам пришлось столкнуться и как вы их решили и почему именно так.

tr0mb Mar 30 2015 at 21:16

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

fisher Mar 31 2015 at 10:06

ну вот так видится процесса разработки с точки зрения QA: open, in progress… on prod!

-2

stan_jeremy Mar 31 2015 at 12:56

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

А можно поподробнее почему не получается их очистить автоматически, ведь воркспейс в любом современном CI можно полностью очистить от всего постороннего не прибегая к rm -rf /* :)
Поэтому собственно:
1) почему остаются временные файлы, они оказываются в неожиданных местах (корки?) или как?
2) почему демон продолжает работать? Он не останавдивается по /etc/init.d/daemon stop или это не совсем тот демон в моем понимании? почему тогда не убивать его не совсем «gracefully» (sigint, sighup, sigkill)?

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

tr0mb Mar 31 2015 at 13:29

Когда я говорил про фатальные ошибки, я имел в виду ошибки самих тестов — т.е. там где логика становится неправильной и php вызывает фатал. А так как все временные файлы чистятся и демон останавливается в деструкторах тестов, то при фатале все это не вызывается.
Нет таких тестов у нас нет, имхо, сложность построения не окупится.

stan_jeremy Mar 31 2015 at 13:49

Т.е. я правильно понимаю, проблема в том, что после фатала php падает и не вызывает tearDown (phpunit) или его аналог?
А пробовали ловить фатал в register_shutdown_function, и в ней вызывать tearDown?

tr0mb Mar 31 2015 at 17:23

да, проблема действительно в этом. Из-за некоторых технических особенностей, кунг-фу с register_shudown_function не работает.
Кстати, был не прав насчет больших интеграционных тестов — коллеги подсказывают, что отдел веб-тестирования имеет такие тесты и использует.

eloin Mar 31 2015 at 17:16

1. Воркспейс очистить можно, да, но некоторые демоны могут писать временные файлы не в директории воркспейса (захардкожены в демоне). Про эти пути известно в тестах конкретного демона.
2. Это не совсем тот демон, да (но очень похож). Если фаталов нет, то примерно так и происходит — демон останавливается по sigterm (для некоторых команда остановки отличается).

Есть и интеграционные, и системные тесты — это селениум-тесты сайта на девеле + отдельная ветка автотестов, ты должен помнить :) Правда, там тесты не на все демона, а лишь на некоторые, но тесты периодически дополняются.