catandmanandtelephone

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

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

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

tipicalfail

Здесь после развёртывания приложения из-за ошибок конфигурации не удалось установить соединением с “External Application 2”, а так же был нарушен протокол общения с “External Application 3”.  В данный момент такие проблемы проверяются ручными QA в течении 5-ти минут, до снятия заглушки.

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

main-idea

Здесь, после установки заглушки для пользователей и начала развёртывания, вместо реального сервиса разворачиваются специальные тесты “Knocker”, которые для проверки правильности интеграции и настроек приложения “простукивают” (посылают тестовые запросы, проверяющие наличие с той стороны внешнего сервиса и правильность наших запросов к нему). Для отправки запросов используется код самого разворачиваемого приложения и его же настройки. Что позволяет убедиться, что всё настроено и работает правильно. Если какие-то из тестов не пройдут, то сам процесс просто не даст развернуть реальное приложение!

Так ведёт себя кофе-машина, когда отсутствует её модуль, либо он установлен недостаточно плотно.

Похожим образом проверяется правильность настроек внутренней логики приложения. Следующая картинка.

second part of idea

После развёртывания приложения, тесты проходят по страницам приложения и доступным пользователю url-ам. И проверяют на наличие 500, 404 ошибок. Так же можно провести пару smoke тестов с помощью WebDriver. В случае провала автоматизированного тестирования, человеку ответственному за релиз посылается сообщение о причине падения теста.

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

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

happy_end

Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники
Опубликовать в Яндекс