Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

1

Share

Download to read offline

Как hh.ru дошли до 500 релизов в квартал без потери в качестве

Download to read offline

Доклад Алексея Анисимова на SQA Days-22. 17-18 ноября 2017. Санкт-Петербург, Россия
www.sqadays.com

Related Books

Free with a 30 day trial from Scribd

See all

Как hh.ru дошли до 500 релизов в квартал без потери в качестве

  1. 1. Software quality assurance days 22 Международная конференция по вопросам качества ПО sqadays.com анкт-Петербург. 17–18 ноября 2017 Алексей Анисимов hh.ru. Москва, Россия Как hh.ru дошли до 500 релизов в квартал без потери в качестве
  2. 2. Обо мне ● с 2002 года в тестировании ● занимался ручным тестированием, автоматизацией, управлением ● сейчас Head of QA в hh.ru https://twitter.com/absolut_real
  3. 3. План доклада Общая информация про архитектуру и цикл разработки в hh.ru Как было 3 года назад Проблемы того времени План и решение Проблемы в процессе решения Что получилось
  4. 4. hh.ru внутри SOA архитектура ~ 50 сервисов (микросервисы и не очень) Python, Java, Postgresql, Cassandra больше 100 серверов в бою
  5. 5. Цикл разработки ● Git flow - каждая задача в своей ветке ● В Ready to release может перевести только тестировщик ● Готовые задачи собираются в Release candidate ● RC автотестируется и отдается в эксплуатацию
  6. 6. Какие были проблемы? ● Длинная инструкция для выпуска релиза - человеческий фактор ● Релиз требует вовлеченности человека на день - ошибки при сборке ● Разные типы сервисов релизятся по разному ● Автотесты почти всегда не проходят, прогон занимает 2-3 часа - недоверие к тестам, много задач не прогоняются через регресс - отдельные люди заняты разбором падений и прогоном тестов ● Тестовая среда очень сильно отличается от боевой - разные настройки, синхронизируемые людьми, если они не забыли ● Часть релизов проходит сразу в эксплуатацию, минуя тестовую среду - особенно изменения в базе, очередях и т.п.
  7. 7. К чему все это приводило? ● Даунтайм на продакшене из-за разных настроек в тестовой и боевой среде (отсутствие некоторых звеньев, другие конфиги) ● Некоторые задачи не выходят в продакшен очень долго - высокий time to market ● Непротестированные изменения в базе приводят к даунтаймам ● Общее нежелание заниматься релизами
  8. 8. Надо что-то делать! Но что?
  9. 9. Давайте все релизить автоматически? Уберем человека из процессов релиза И автотесты пусть тоже робот запускает. Решим проблемы с релизами: ●Отсутствие очереди задач на релиз ●Нет личного отношения к задачам - роботу все равно ●Нет ошибок из-за внимания ●Деплой проверим заодно
  10. 10. Ура! Давайте сделаем! Но, не все так просто: ●Куча разных вариантов сборки и выпуска релизов ●Тестовая среда непригодна для проверки деплоя приложений - на бою все на разных машинах. В тесте все на одной - отсутствуют балансировщики, конфиги и порты другие ●Нет возможности установить нужную версию приложения автоматом на “свежий” тестовый стенд и проверить ее перед релизом автотестами ●Автотесты должны быть быстрые и стабильные, чтобы им доверяли
  11. 11. Три части плана ● Подготовка и сборка релизов ● Тестовая среда похожая на бой ● Быстрые и стабильные автотесты ● Соединим все вместе!
  12. 12. Сборка релизов - как? ● Нет готовых продуктов для удовлетворения наших требований ● Свое приложение с веб-интерфейсом для одновременных пользователей ● Доступность логов и результатов ● Возможность дособрать, пересобрать релиз ● Различный порядок действий при сборке различных сервисов ● Все в deb пакеты для унификации ● Несколько серверов сборщиков с разным окружением (ubuntu 12-14-16, java/python) ● Интеграция с внутренней авторизацией ● Статистика
  13. 13. Сборка релизов - workflow
  14. 14. Сборка релизов - что получилось ● Человек может собрать релиз, нажав несколько кнопок ● Выбрать нужные ему задачи
  15. 15. ● SQL & docker images автоматически включаются в релиз Не задумываться о правильном оформлении задачи для службы эксплуатации
  16. 16. ● Виден статус сборки ● Релиз собирается всегда одинаково роботом
  17. 17. Deploy - как было ● Тестовые стенды не похожие на бой - даунтаймы ● Отдельные конфиги для теста и для боя ● Ограниченные возможности автоматического конфигурирования тестовых стендов ● Не все изменения можно установить на тестовый стенд и проверить - нет балансировщиков, фронтов и т.п. ● Chroot для питона с разными зависимостями ● Сложно поддержать разные версии ubuntu
  18. 18. Deploy - какой был план? ● Конфигурация системы такая же как в бою ● Использовать боевые конфиги каждого сервиса с минимумом изменений ● Процедура деплоя как в бою. И протестировать можно перед выкладкой ● Автоматический накат и откат версий приложений в т.ч. удаленно ● Возможность сборки из ветки ● Поддержать все остальные функции текущего тестового окружения и постараться сделать их лучше ● Интеграция с системой сборки релизов
  19. 19. Deploy - что делали? ● Параллельно сделали тестовые стенды с новым окружением - чтобы не останавливать текущие процессы выпуска задач
  20. 20. ● Внутри новых тестовых стендов: ○ конфигурация аналогичная боевой с балансировщиками, фронт-серверами ○ docker контейнеры как аналог машин с сервисами в бою ○ ansible как система для конфигурации и деплоя сервисов ○ обвязка для более простого развертывания и управления стендами
  21. 21. Технологии - почему такой выбор? Docker: ●Изоляция окружения внутри контейнера ●Простота взаимодействия с контейнерами ●Возможность использования разных версий операционных систем ●Версионность ●Решили попробовать новую многообещающую технологию, поддерживаемую сообществом :)
  22. 22. Технологии - почему такой выбор? Ansible: ●Служба эксплуатации использовала Ansible при деплое сервисов в бой ●Шаблоны конфигурационных файлов с возможностью использования переменных ●Переопределение переменных ●Понятный yml
  23. 23. Deploy - что получилось? ● Тестовые стенды повторяют архитектуру боевой системы ● Можем после сборки релиза установить его на стенд автоматически ● Можем тестировать любые изменения в конфигах приложений
  24. 24. Deploy - что получилось? ● Стенды по прежнему можно использовать для ручного тестирования ● Разработчики и тестировщики больше вовлечены в деплой и настройку приложений - больше возможностей влиять на боевые настройки
  25. 25. Deploy - не все так гладко ● Целый год тюнили окружение ● Некоторые операции стали выполняться дольше, чем раньше (ввиду использования ansible и сложности системы) ● Было много противников и недовольных ● В течение года любые проблемы на стендах начинались со слов “наверное, это из-за докера”
  26. 26. Deploy - пул стендов под релизы? ● Под релизы всегда нужны свежие и обновленные стенды ● Сделали пул стендов - сейчас их 7 ● Они автоматически обновляются и готовы к проверке релизов
  27. 27. Что после деплоя приложения на стенд? Приложение надо проверить набором регрессионных автотестов
  28. 28. Автотесты - как было устроено ● TestNG / Java / WebDriver ● Jenkins для запуска ● Тесты собраны в сьюты в Jenkins по областям функционала ● Параллелизация силами TestNG ● Параллелизация сьютов с помощью Jenkins ● VM с браузерами ● ~6 выделенных автоматизаторов тестирования
  29. 29. Автотесты какие были проблемы ● Тесты падают в основном из-за самих тестов и окружения ● Таймауты где надо и где не надо ● Одни тесты зависят от других ● Результаты недостаточно понятны - разбираются только отдельные люди ● Тестируем внешние сервисы вместе со своим проектом ● Длинные тестовые сьюты - долгий перезапуск при падениях ● Автоматизаторы часто не в курсе тонкостей продукта при написании автотестов и не заинтересованы в покрытии тестами нужного функционала
  30. 30. Автотесты - какой был план? ● Скорость ○ тесты должны быть быстрее - 1 час на прогон ● Стабильность ○ минимум нестабильных тестов, непроходящих после 1 перепрогона ● Простота добавления новых тестов ○ чтобы любая команда, добавляющая функционал могла написать автотесты
  31. 31. Автотесты - скорость Что делали: ●Курс на использование сервиса фикстур ●Каждая область функционала должна единожды быть протестирована через UI, в остальных случаях использовать сервис фикстур для создания предусловий
  32. 32. Сервис фикстур у нас это:
  33. 33. Автотесты - скорость Что делали: ●Разбиение сьютов на более мелкие с ограничением времени прохождения ●Увеличение параллельных потоков при прогоне - в Jenkins - в самих тестах при помощи TestNG ●Настройка тестовых стендов под большую нагрузку
  34. 34. Автотесты - стабильность Что делали: ●Избавлялись от тестирования внешних сервисов - запроксировали внешние запросы (счетчики, и т.п.) - внешние интеграции заменили моками
  35. 35. Автотесты - стабильность ● Только implicit ожидания - когда в автотесте таймаут, то он ждет чего-то (элемента и т.п), а не просто так ● Больше использования сервиса фикстур ● Тюнинг тестового окружения ● Замена VM с браузерами на docker-контейнеры - увеличили количество, проще обслуживать ● Тюнинг selenium таймаутов на гриде и на нодах ● Грид на хорошем железе ● Мониторинг серверов с гридом и браузерами
  36. 36. Автотесты - простота Что делали: ● Обширный рефакторинг самих тестов ● Тренинги и обучение для тестировщиков ● 3 выделенных автоматизатора для помощи, оптимизации кода и ревью
  37. 37. Автотесты - простота ● Максимально подробное логгирование на русском языке
  38. 38. Автотесты - простота
  39. 39. Автотесты - простота Что получилось: ● Автотесты пишутся внутри команд ● Обязательное ревью у автоматизаторов ● Все понимают как написать тест на новый функционал или как поправить старый
  40. 40. Больше тестов каждый месяц!
  41. 41. Автотесты - скорость, стабильность, простота hh.kraken: ● Динамическая балансировка автотестов во время прогона ● Избавление от сьютов ● Автоматическая генерация тестов для запуска ● Возможность запустить тесты одного класса или package
  42. 42. Было После группировки Динамическая балансировка
  43. 43. Автотесты - что получилось? ● Понятные всем результаты
  44. 44. Автотесты - что получилось? ● Интеграция с системой выпуска релизов - возможность запустить, перезапустить тесты - смотреть результаты
  45. 45. Тесты прошли. Что дальше? ● Задача автоматически переводится на службу эксплуатации. ● Далее в авто режиме/полу-авто режиме новый релиз выходит в бой. ● Мониторим изменения в бою ● Если все ок - код попадает в ветку мастер автоматически
  46. 46. Весь процесс релиза от начала и до конца Глазами сотрудника технического департамента Если все хорошо:
  47. 47. Если что-то не так:
  48. 48. Обязательный мониторинг всех частей системы CPU, Memory, etc
  49. 49. Мониторинг релизов
  50. 50. Мониторинг системы автотестирования
  51. 51. Мониторинг selenium
  52. 52. Мониторинг релизов
  53. 53. Итого ● 10+ релизов в день ● Тесты за 30-35 минут ● Тестовая среда аналогичная продакшену ● Готовность выпускать релизы хоть круглые сутки ● Качественные показатели на высоте
  54. 54. Итого - количество
  55. 55. Итого - качество
  56. 56. Итого - качество
  57. 57. С чего начать? ● Цель - что хочется получить! ● Конвенции ● Договориться об используемых технологиях ● Когда все придерживаются обозначенных контрактов, можно начать автоматизировать частями ● Оптимизировать по пути, не делать все сразу
  58. 58. Инструменты ● Возможность использования систем CI – Jenkins / Bamboo ● Docker – для приложений – простота и удобство ● Системы удаленной конфигурации – Ansible ● Проверенные решения для автотестов – смотреть в сторону готовых оберток над селениумом – Selenide, etc. ● Для автотестов и окружения выбрать язык программирования, по которому есть экспертиза внутри компании
  59. 59. Что почитать/посмотреть ● Все источники выбираются под ваш стек технологий ● Доклады с конференций от крупных компаний про процессы выпуска приложений ● Про тренды в тестировании и обеспечении качества: 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/
  60. 60. Вопросы?
  • Irinva

    Dec. 23, 2017

Доклад Алексея Анисимова на SQA Days-22. 17-18 ноября 2017. Санкт-Петербург, Россия www.sqadays.com

Views

Total views

634

On Slideshare

0

From embeds

0

Number of embeds

256

Actions

Downloads

10

Shares

0

Comments

0

Likes

1

×