Доклад Алексей Анисимова о процессе обеспечения качества в hh.ru описывает переход к автоматизации релизов и тестирования, что привело к улучшению качества и снижению времени на выпуск новых версий. Основное внимание уделяется проблемам, связанным с тестовой средой и необходимостью гармонизации с боевыми конфигурациями, а также внедрению технологий Docker и Ansible для оптимизации процессов. В результате, компания теперь выпускает более 10 релизов в день, с качественными показателями на высоком уровне.

1. Software quality assurance days
22 Международная конференция
по вопросам качества ПО
sqadays.com
анкт-Петербург. 17–18 ноября 2017
Алексей Анисимов
hh.ru. Москва, Россия
Как hh.ru дошли до 500 релизов в квартал
без потери в качестве

2. Обо мне
● с 2002 года в тестировании
● занимался ручным тестированием,
автоматизацией, управлением
● сейчас Head of QA в hh.ru
https://twitter.com/absolut_real

3. План доклада
Общая информация про архитектуру и цикл разработки в hh.ru
Как было 3 года назад
Проблемы того времени
План и решение
Проблемы в процессе решения
Что получилось

5. hh.ru внутри
SOA архитектура
~ 50 сервисов
(микросервисы и не очень)
Python, Java, Postgresql,
Cassandra
больше 100 серверов в бою

6. Цикл разработки ● Git flow - каждая задача в своей
ветке
● В Ready to release может перевести
только тестировщик
● Готовые задачи собираются в
Release candidate
● RC автотестируется и отдается в
эксплуатацию

7. Какие были проблемы?
● Длинная инструкция для выпуска релиза
- человеческий фактор
● Релиз требует вовлеченности человека на день
- ошибки при сборке
● Разные типы сервисов релизятся по разному
● Автотесты почти всегда не проходят, прогон занимает 2-3 часа
- недоверие к тестам, много задач не прогоняются через регресс
- отдельные люди заняты разбором падений и прогоном тестов
● Тестовая среда очень сильно отличается от боевой
- разные настройки, синхронизируемые людьми, если они не забыли
● Часть релизов проходит сразу в эксплуатацию, минуя тестовую среду
- особенно изменения в базе, очередях и т.п.

8. К чему все это приводило?
● Даунтайм на продакшене из-за разных настроек в тестовой и
боевой среде (отсутствие некоторых звеньев, другие конфиги)
● Некоторые задачи не выходят в продакшен очень долго -
высокий time to market
● Непротестированные изменения в базе приводят к даунтаймам
● Общее нежелание заниматься релизами

9. Надо что-то делать! Но что?

10. Давайте все релизить автоматически?
Уберем человека из процессов релиза
И автотесты пусть тоже робот запускает.
Решим проблемы с релизами:
●Отсутствие очереди задач на релиз
●Нет личного отношения к задачам - роботу все равно
●Нет ошибок из-за внимания
●Деплой проверим заодно

11. Ура! Давайте сделаем!
Но, не все так просто:
●Куча разных вариантов сборки и выпуска релизов
●Тестовая среда непригодна для проверки деплоя приложений
- на бою все на разных машинах. В тесте все на одной
- отсутствуют балансировщики, конфиги и порты другие
●Нет возможности установить нужную версию приложения автоматом
на “свежий” тестовый стенд и проверить ее перед релизом
автотестами
●Автотесты должны быть быстрые и стабильные, чтобы им доверяли

12. Три части плана
● Подготовка и сборка релизов
● Тестовая среда похожая на бой
● Быстрые и стабильные автотесты
● Соединим все вместе!

13. Сборка релизов - как?
● Нет готовых продуктов для удовлетворения наших требований
● Свое приложение с веб-интерфейсом для одновременных пользователей
● Доступность логов и результатов
● Возможность дособрать, пересобрать релиз
● Различный порядок действий при сборке различных сервисов
● Все в deb пакеты для унификации
● Несколько серверов сборщиков с разным окружением (ubuntu 12-14-16,
java/python)
● Интеграция с внутренней авторизацией
● Статистика

14. Сборка релизов - workflow

15. Сборка релизов - что получилось
● Человек может собрать релиз, нажав несколько кнопок
● Выбрать нужные ему задачи

16. ● SQL & docker images автоматически
включаются в релиз
Не задумываться о правильном оформлении
задачи для службы эксплуатации

17. ● Виден статус сборки
● Релиз собирается всегда одинаково роботом

18. Deploy - как было
● Тестовые стенды не похожие на бой - даунтаймы
● Отдельные конфиги для теста и для боя
● Ограниченные возможности автоматического конфигурирования тестовых
стендов
● Не все изменения можно установить на тестовый стенд и проверить
- нет балансировщиков, фронтов и т.п.
● Chroot для питона с разными зависимостями
● Сложно поддержать разные версии ubuntu

19. Deploy - какой был план?
● Конфигурация системы такая же как в бою
● Использовать боевые конфиги каждого сервиса с минимумом
изменений
● Процедура деплоя как в бою. И протестировать можно перед
выкладкой
● Автоматический накат и откат версий приложений в т.ч. удаленно
● Возможность сборки из ветки
● Поддержать все остальные функции текущего тестового
окружения и постараться сделать их лучше
● Интеграция с системой сборки релизов

20. Deploy - что делали?
● Параллельно сделали тестовые стенды с новым окружением
- чтобы не останавливать текущие процессы выпуска задач

21. ● Внутри новых тестовых стендов:
○ конфигурация аналогичная боевой с
балансировщиками, фронт-серверами
○ docker контейнеры как аналог машин с сервисами в
бою
○ ansible как система для конфигурации и деплоя
сервисов
○ обвязка для более простого развертывания и
управления стендами

22. Технологии - почему такой выбор?
Docker:
●Изоляция окружения внутри контейнера
●Простота взаимодействия с контейнерами
●Возможность использования разных версий операционных систем
●Версионность
●Решили попробовать новую многообещающую технологию,
поддерживаемую сообществом :)

23. Технологии - почему такой выбор?
Ansible:
●Служба эксплуатации использовала Ansible при деплое сервисов в
бой
●Шаблоны конфигурационных файлов с возможностью
использования переменных
●Переопределение переменных
●Понятный yml

25. Deploy - что получилось?
● Тестовые стенды повторяют архитектуру боевой системы
● Можем после сборки релиза установить его на стенд автоматически
● Можем тестировать любые изменения в конфигах приложений

26. Deploy - что получилось?
● Стенды по прежнему можно использовать для ручного
тестирования
● Разработчики и тестировщики больше вовлечены в деплой и
настройку приложений - больше возможностей влиять на боевые
настройки

27. Deploy - не все так гладко
● Целый год тюнили окружение
● Некоторые операции стали выполняться дольше, чем раньше
(ввиду использования ansible и сложности системы)
● Было много противников и недовольных
● В течение года любые проблемы на стендах начинались со
слов
“наверное, это из-за докера”

28. Deploy - пул стендов под релизы?
● Под релизы всегда нужны свежие и обновленные стенды
● Сделали пул стендов - сейчас их 7
● Они автоматически обновляются и готовы к проверке релизов

29. Что после деплоя приложения на стенд?
Приложение надо проверить набором регрессионных автотестов

30. Автотесты - как было устроено
● TestNG / Java / WebDriver
● Jenkins для запуска
● Тесты собраны в сьюты в Jenkins по областям функционала
● Параллелизация силами TestNG
● Параллелизация сьютов с помощью Jenkins
● VM с браузерами
● ~6 выделенных автоматизаторов тестирования

31. Автотесты какие были проблемы
● Тесты падают в основном из-за самих тестов и окружения
● Таймауты где надо и где не надо
● Одни тесты зависят от других
● Результаты недостаточно понятны - разбираются только
отдельные люди
● Тестируем внешние сервисы вместе со своим проектом
● Длинные тестовые сьюты - долгий перезапуск при падениях
● Автоматизаторы часто не в курсе тонкостей продукта при
написании автотестов и не заинтересованы в покрытии тестами
нужного функционала

32. Автотесты - какой был план?
● Скорость
○ тесты должны быть быстрее - 1 час на прогон
● Стабильность
○ минимум нестабильных тестов, непроходящих после 1
перепрогона
● Простота добавления новых тестов
○ чтобы любая команда, добавляющая функционал могла
написать автотесты

33. Автотесты - скорость
Что делали:
●Курс на использование сервиса фикстур
●Каждая область функционала должна единожды быть
протестирована через UI, в остальных случаях использовать сервис
фикстур для создания предусловий

34. Сервис фикстур у нас это:

36. Автотесты - скорость
Что делали:
●Разбиение сьютов на более мелкие с ограничением времени
прохождения
●Увеличение параллельных потоков при прогоне
- в Jenkins
- в самих тестах при помощи TestNG
●Настройка тестовых стендов под большую нагрузку

37. Автотесты - стабильность
Что делали:
●Избавлялись от тестирования внешних сервисов
- запроксировали внешние запросы (счетчики, и т.п.)
- внешние интеграции заменили моками

38. Автотесты - стабильность
● Только implicit ожидания - когда в автотесте таймаут, то он ждет чего-то (элемента и
т.п), а не просто так
● Больше использования сервиса фикстур
● Тюнинг тестового окружения
● Замена VM с браузерами на docker-контейнеры
- увеличили количество, проще обслуживать
● Тюнинг selenium таймаутов на гриде и на нодах
● Грид на хорошем железе
● Мониторинг серверов с гридом и браузерами

39. Автотесты - простота
Что делали:
● Обширный рефакторинг самих тестов
● Тренинги и обучение для тестировщиков
● 3 выделенных автоматизатора для помощи, оптимизации кода и
ревью

40. Автотесты - простота
● Максимально
подробное
логгирование на
русском языке

41. Автотесты - простота

42. Автотесты - простота
Что получилось:
● Автотесты пишутся внутри команд
● Обязательное ревью у автоматизаторов
● Все понимают как написать тест на новый функционал
или как поправить старый

43. Больше тестов
каждый месяц!

44. Автотесты - скорость, стабильность, простота
hh.kraken:
● Динамическая балансировка автотестов во время прогона
● Избавление от сьютов
● Автоматическая генерация тестов для запуска
● Возможность запустить тесты одного класса или package

45. Было После группировки Динамическая
балансировка

46. Автотесты - что получилось?
● Понятные всем результаты

47. Автотесты - что получилось?
● Интеграция с системой выпуска релизов
- возможность запустить, перезапустить тесты
- смотреть результаты

48. Тесты прошли. Что дальше?
● Задача автоматически переводится на службу эксплуатации.
● Далее в авто режиме/полу-авто режиме новый релиз выходит в бой.
● Мониторим изменения в бою
● Если все ок - код попадает в ветку мастер автоматически

49. Весь процесс релиза от начала и до конца
Глазами сотрудника технического департамента
Если все хорошо:

50. Если что-то не так:

51. Обязательный мониторинг всех частей системы
CPU, Memory, etc

52. Мониторинг релизов

53. Мониторинг системы автотестирования

54. Мониторинг selenium

55. Мониторинг релизов

56. Итого
● 10+ релизов в день
● Тесты за 30-35 минут
● Тестовая среда аналогичная продакшену
● Готовность выпускать релизы хоть круглые сутки
● Качественные показатели на высоте

57. Итого - количество

58. Итого - качество

59. Итого - качество

60. С чего начать?
● Цель - что хочется получить!
● Конвенции
● Договориться об используемых технологиях
● Когда все придерживаются обозначенных контрактов, можно начать
автоматизировать частями
● Оптимизировать по пути, не делать все сразу

61. Инструменты
● Возможность использования систем CI – Jenkins / Bamboo
● Docker – для приложений – простота и удобство
● Системы удаленной конфигурации – Ansible
● Проверенные решения для автотестов – смотреть в сторону готовых оберток
над селениумом – Selenide, etc.
● Для автотестов и окружения выбрать язык программирования, по которому есть
экспертиза внутри компании

62. Что почитать/посмотреть
● Все источники выбираются под ваш стек технологий
● Доклады с конференций от крупных компаний про процессы выпуска
приложений
● Про тренды в тестировании и обеспечении качества:
http://www.satisfice.com/blog/ James Bach
http://www.developsense.com/ Michael Bolton
● Slack chats: http://testers.io https://software-testers.herokuapp.com/
https://devopschat.co/
Моя статья про переделку тестового окружения
https://habrahabr.ru/company/hh/blog/271221/

63. Вопросы?