Интересный баг только что отловили. Рассказываю.

Имеем сервис с капчами. Чтобы уменьшить время отклика логично генерировать картинки по случайному коду в свободное время в час наименьшей нагрузки. Так и делаем — ставим в крон задачку, делаем 100500 капч (картинка + код в базе) и в течение дня их показываем. На тот случай если прегенерированные капчи все-же закончатся, делаем режим аварийного полета — если отгаданная и, в связи с этим, убираемая из базы капча уменьшает общее число капч до опасного уровня (например, остается меньше 50), то генерируем новую капчу вместо убранной.

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

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

Суть проблемы: веб-приложение для службы такси, диспетчера работают удаленно (из дома, из офиса и т.п.). Перед каждым — список заказов. Состояние заказов может измениться в любой момент — водитель взял заказ, водитель отказался, клиент отказался, другой диспетчер завел новый заказ. Очень важно чтобы диспетчер видел картину практически в реальном времени, поскольку в час пик звонки идут один за другим без перерыва. Вначале это было сделано через вызывающийся периодически (setTimeout) AJAX запрос, который получив с сервера отрендеренный список текущих запросов заменял содержимое div'а. Для 1-2 разработчиков, и пары тестеров это казалось нормальной идеей — 1-2 запроса в секунду не сильно напрягали. По результатам компромисса между актуальностью и снижением нагрузки на сервер определились что будем дергать сервер раз в 3 секунды.

В какой-то момент, если долго и усердно стараться сохранять покрытие тестами не меньше 80% кода, прогон полного комплекта тестов начнет занимать больше времени, чем уходит на перекур и на прочтение новых статей хабра. В свою очередь это приводит к тому, что полный комплект (suite) будет запускаться все реже и реже. Hudson начнет сообщать о сломанных билдах, а дальше сработает эффект разбитого окна и сломанный билд станет нормой.

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

В одном из наших проектов, в который согласно записям redmine вложено около 400 часов работы нашего коллектива ситуация с тестами до распараллеливания выглядела так (пару дней назад):
151 scenarios (151 passed)
3997 steps (3997 passed)
17m49.257s


18 минут!!!

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

Но анализ загрузки процессора при прогоне показывает, что в работе участвует только лишь одно ядро независимо от того, сколько их всего есть. Как говорит пословица, лучше день потерять, а потом за пять минут долететь. Порыскав в гугле мы нашли гем parallel_tests. Теперь мы не с такой завистью будем смотреть на erlang группу, которые могут спокойно распараллелить свои тесты на кластер арендованных облачных машин в Selectel.

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

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

Наша цель — задокументировать шаги, требуемые для преодоления встречающихся препятствий на пути к запуску полного набора тестов Cucumber со сценариями на Selenium на сборочном сервере Hudson.

Как известно, люди делятся на тех кто еще не делает резервных копий, тех кто уже делает, и тех кто уже делает и проверяет возможность восстановления

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

А делаем мы резервные копии через gem backup