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.

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

487 views

Published on

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

Published in: Education
  • Be the first to comment

Как 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. Вопросы?

×