С вами снова Ольга Султанова, руководитель отдела тестирования Рунити. В этот раз расскажу, как мы автоматизировали рутинные задачи в нашем отделе с помощью собственного бота, сократили работу над почти десятью мелкими задачами, сосредоточились на более важных делах и стали регулярно отмечать дни рождения в команде. А еще подсветим проблемы. Статья будет полезна, прежде всего, тимлидам, тестировщикам и разработчикам. Подробности под катом.
Навигация по тексту:
Как всё начиналось и какие проблемы решали
Предыстория, как мы пришли к идее создания собственного бота. В отделе тестирования есть множество рутинных задач, которые отнимают время и требуют постоянного внимания.
Проблемы, с которыми мы столкнулись:
— Продление тестовых услуг. Некоторые из автотестов жестко связаны с определенными услугами. Например, проверками продления, тестом карточек услуг и многими другими. Не продли их вовремя — сначала у нас начнут фейлиться тесты, потом придется потратить время на поиск альтернативных услуг вместо тех, что закончились. Нередко эти услуги с некими определенными предусловиями. И таких услуг аж 130 штук — немаленькая такая задача получается.
— Голосовые активности: дейли, ретро и другие мероприятия, за которыми нужно следить. Все встречи есть в календаре. Но, думаю, с каждым могло быть, что, погрузившись в задачу, потерял счет времени и пропустил начало встречи… или вообще всю.
— Дежурства. Ежедневно назначено несколько дежурных по трем нашим ключевым продуктовым направлениям, важно не пропустить свой день. Например, в одном — нужно мониторить выкатки, в другом — разбирать баги от клиентских служб.
— Ревью MRов (Merge Requests). Когда-то MRы висели у нас в ревью слишком долго. Кому-то было неудобно получать оповещение о ревью на почту — письма просто терялись среди потока. Кто-то надеялся на других и если назначено 10 человек, то «пусть посмотрит кто-нибудь, кто не я». Чтобы такого не было, нужны конкретные ответственные за MRы.
— Метки в Jira. Необходимо следить, чтобы на все баги были навешаны метки для работы с метриками. Мы собираем разные показатели, в том числе из Jira. Это могут быть внутренние, внешние или критические баги и — найденные автотестами. Если метки у тикета нет, например, баг создал не тестировщик, а продакт-менеджер или клиентские службы, то такой дефект не попадает в расчеты метрик. И поэтому нам необходимо следить, чтобы на все реальные баги были навешаны нужные метки.
— Работа с метриками. Нам нужно собирать и анализировать метрики по багам, покрытию, автоматизации — где-то хранить и обращать внимание на них, если что-то идет не так. Из регулярного: раз в неделю мы отслеживаем хрупкость сборок. Раз в месяц — анализируем метрики по дефектам, покрытию и автотестам.
— Дни рождения в команде. О них важно помнить. Получать поздравления с днем рождения всегда приятно, но с ростом отдела довольно сложно уследить за всеми праздничными датами.
— Заполнение отчетов. Рутинная задача, которая настигает в конце месяца, когда нужно заполнить отчеты о нагрузке. В целом, задача на две минуты, но это тоже нужно держать в голове и хранить под рукой ссылку на отчет.
Вот такой список получился. Большинство из этих задач небольшие, но всё равно занимают время и могут выпадать из фокуса. Также все их можно выполнить вручную, использовать личные напоминалки и закреплять ссылки. Но если есть возможность автоматизировать, то почему бы не сэкономить себе время и не сделать это?
Отсюда мы решили, что пора завести своего ассистента, который будет помогать и напоминать о важном. Так у нас появился бот.
Как появилась первая версия бота
Изначально наш бот имел довольно ограниченный функционал: он просто брал информацию из файлов и присылал оповещение в корпоративный мессенджер. На тот момент бот был создан практически без использования кода, просто работал с хуками мессенджера и с API для получения данных из файлов.
Всё меняется, и со временем наши запросы на автоматизацию росли. Мы переехали из одного мессенджера в другой, поэтому бот значительно вырос — вот, что он умеет теперь (спойлер: он умеет решать все проблемы, которые мы обозначили выше, но расскажем о каждом пункте подробнее):
1. Поздравлять с днем рождения. После чего возникает цепная реакция поздравлений и пожеланий от команды, что тоже приятно и классно :)
2. Оповещать о дейли. За несколько минут до встречи бот напоминает о ней, назначает ведущего или резервного ведущего, если основной в отпуске.
3. Готовить к ретро. За несколько недель до мероприятия бот присылает напоминания ведущему о том, что уже можно начинать готовиться, собирать информацию, продумывать интерактивы и оформлять доску.
4. Напоминать о дежурствах. Каждое утро бот оповещает дежурного и закрепляет информацию в канале. На случай, если кому-то из разработчиков, допустим, нужна эта информация.
5. Напоминать об отчетах. В последний день месяца бот присылает ссылку на отчет, который нужно заполнить.
Это были функции оповещения, теперь переходим к более серьезным задачам, которые умеет решать бот.
6. Автоматически продлевать тестовые услуги, когда подходят даты их истечения.
7. Контролировать метки в Jira. Раз в неделю бот присылает список багов без меток, чтобы тестировщики могли их проверить.
8. Следить за хрупкостью сборок. Если процент хрупкости превышен, бот отправляет оповещение раз в неделю.
9. Анализировать метрики. Раз в месяц бот присылает оповещения, если превышены метрики по багам, покрытию и автотестам.
10. Призывать на ревью MR. Для каждого MR бот случайным образом назначает двух человек для проверки и отправляет оповещение в мессенджер, призывая их и всех остальных, на всякий случай.
Часть техническая: реализация
Теперь расскажем, что под капотом бота. Его примерная схема выглядит так, единственное, сейчас у нас больше ресурсов, чем было изначально.
Вся функциональность, связанная со списками людей (например, дни рождения, дежурства), использует API для работы с файлами. Данные берутся из электронных таблиц, где указаны имена сотрудников, даты и пересечения этих двух полей — всё довольно просто, но сложнее здесь и не нужно. После чего небольшой скрипт на JavaScript обрабатывает их и отправляет уведомления в мессенджер через вебхуки.
Для функциональностей, связанных с метриками, используется связка API Jira, базы данных, JavaScript и вебхуков мессенджера. Делаем JQL-запрос к Jira — данные попадают в базу данных, откуда скрипт на JavaScript забирает их и отправляет в мессенджер. Прослойка с базой данных нужна для долгосрочного хранения информации, которая используется нами для других задач, так что в теории для работы бота мы могли обойтись и без базы данных.
Для продления услуг реализация пока неидеальная — сложнее, чем могла бы быть.
Сначала с помощью запроса к клиентскому API мы получаем даты экспирации всех наших услуг. Если обнаруживаются услуги, которые можно продлить, то выставляется счет на их продление, а дальше подключается WebDriver — счета оплачиваются через веб-интерфейс приложения для клиентских служб, как если бы это был UI-автотест, поскольку для этого приложения у нас нет удобного API. Но в использовании никаких проблем такая реализация не доставляет.
Призыв на ревью добавлен отдельной джобой в pipeline при создании МRа. Когда автор кода готов к ревью, он вручную запускает эту джобу и стартует скрипт на JavaScript, который выбирает ревьюеров и отправляет им оповещение в мессенджер.
Сначала для этой цели прикрутили библиотеку Danger, но у нас возникли инфраструктурные проблемы в Git. Также тестировщикам удобнее было получать уведомления в мессенджер, поэтому работу с Danger мы пока архивировали и отложили в пользу бота.
Итак, запуск автоматизирован! Все задания запускаются по расписанию через GitLab.
Мы получаем стабильность и предсказуемость работы бота — каждая функция у нас описана человеческим языком, написано, во сколько и когда она будет опускаться. Всё хорошо, но остался момент…
Небольшое «но», над которым сейчас работаем
Хоть мы и автоматизировали много процессов, полностью исключить ручное вмешательство пока не удается. Например, актуализация текстовых документов. Данные о сотрудниках, даты дежурств и другие списки нужно обновлять вручную время от времени.
Дальше — актуализация списка услуг для продления. Если появляются новые тестовые услуги, их нужно вручную добавлять в список. И наоборот, если что-то потеряло актуальность, то это нужно выпиливать из системы для отслеживания.
Последнее — разбор тикетов без меток тоже нужно делать вручную. То есть, хотя бот присылает нам уведомления о багах без меток, анализ этих багов и проставление меток все равно требуют человеческого участия. Нужно понимание контекста и специфики бага — пока наш бот до такого не дорос. Подождем, как будут идти дела в будущем, возможно, посмотрим в сторону искусственного интеллекта.
Все задачи полностью автоматизировать сложно, но мы стараемся сделать так, чтобы их ручное выполнение было максимально удобным и быстрым. Например, делаем регламенты и закрепляем ссылки для быстрой навигации.
Итоги
Подведем промежуточные итоги — здесь есть пару мыслей. Во-первых, бот стал незаменимым помощником в нашем отделе. Он действительно упростил многие рутинные процессы и освободил время для более важных задач. Во-вторых, наш бот — живой проект, мы постоянно улучшаем и дорабатываем его.
Спасибо, что дочитали! И мы готовы обсудить, как вы решаете подобные задачи у себя? :)
Автор: runity
