Как hh.ru дошли до 500 релизов в квартал без потери в качестве
Download as PPT, PDF1 like733 views
Доклад Алексей Анисимова о процессе обеспечения качества в hh.ru описывает переход к автоматизации релизов и тестирования, что привело к улучшению качества и снижению времени на выпуск новых версий. Основное внимание уделяется проблемам, связанным с тестовой средой и необходимостью гармонизации с боевыми конфигурациями, а также внедрению технологий Docker и Ansible для оптимизации процессов. В результате, компания теперь выпускает более 10 релизов в день, с качественными показателями на высоком уровне.
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
- 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. Автотесты - простота ● Максимально подробное логгирование на русском языке
- 42. Автотесты - простота Что получилось: ● Автотесты пишутся внутри команд ● Обязательное ревью у автоматизаторов ● Все понимают как написать тест на новый функционал или как поправить старый
- 44. Автотесты - скорость, стабильность, простота hh.kraken: ● Динамическая балансировка автотестов во время прогона ● Избавление от сьютов ● Автоматическая генерация тестов для запуска ● Возможность запустить тесты одного класса или package
- 45. Было После группировки Динамическая балансировка
- 46. Автотесты - что получилось? ● Понятные всем результаты
- 47. Автотесты - что получилось? ● Интеграция с системой выпуска релизов - возможность запустить, перезапустить тесты - смотреть результаты
- 48. Тесты прошли. Что дальше? ● Задача автоматически переводится на службу эксплуатации. ● Далее в авто режиме/полу-авто режиме новый релиз выходит в бой. ● Мониторим изменения в бою ● Если все ок - код попадает в ветку мастер автоматически
- 49. Весь процесс релиза от начала и до конца Глазами сотрудника технического департамента Если все хорошо:
- 50. Если что-то не так:
- 51. Обязательный мониторинг всех частей системы CPU, Memory, etc
- 56. Итого ● 10+ релизов в день ● Тесты за 30-35 минут ● Тестовая среда аналогичная продакшену ● Готовность выпускать релизы хоть круглые сутки ● Качественные показатели на высоте
- 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. Вопросы?