Мессенджеры на работе — это не прокрастинация, или как мы сделали сервис для автотестирования. Часть 2

На связи Сергей Кондитеров и Сергей Бушмелев, ведущие инженеры по автоматизации тестирования в компании РТЛабс. Это вторая часть статьи «Мессенджеры на работе — это не прокрастинация, или как мы сделали сервис для автотестирования». Как и обещали, в данной статье мы расскажем о том, как масштабировали наш сервис, как развивали функциональность автотестов и как в итоге вышли за рамки обычного репорт-бота. 

На первом этапе нами был создан бот. Он работал стабильно, пользователи получали нужные отчёты, но в какой-то момент пришла мысль, что мы привязаны к одному мессенджеру. Хотелось получить возможность осуществлять интеграцию с другими мессенджерами. В связи с этим было принято решение перевести наш монолитный сервис на микросервисную архитектуру, в которой каждый микросервис будет заниматься решением своих узконаправленных задач.

1. Архитектура

2. Основные компоненты:

   2.1. Клиенты
   2.2. Async-server
   2.3. User-manager
   2.4. Jenkins-adapter

3. Регистрация пользователей

4. Пользовательский сценарий

5. Функционал, не связанный с автотестами:

   5.1. Отпуска
   5.2. Интеграция с Jira

6. Заключение

Архитектура

Микросервисы пишутся в связке Java 17 + Spring Boot, в качестве базы данных используется PostgreSQL. Взаимодействие между ними осуществляется при помощи Apache Kafka и REST API.

Ядром всей системы является Async-server. Он занимается непосредственной обработкой команд, поступающих от клиентов в асинхронном режиме, и отправкой результатов обработки команд клиентам. 

User-manager хранит информацию о зарегистрированных пользователях и о том, к выполнению каких команд у них есть доступ. 

Адаптеры занимаются взаимодействием с такими системами, как Jenkins и Jira (Jenkins-adapter и Jira-adapter). 

Когда пользователь отправляет сообщение боту, его запрос сначала попадает в один из клиентов, затем отправляется в Async-server, который, в свою очередь, пересылает его в User-manager. Если пользователь имеет требуемую роль, запрос обрабатывается, результаты обработки отправляются пользователю.

Описанная архитектура сервиса предоставляет возможность быстрой  его интеграции с интересующим нас мессенджером или сервисом. Необходимо лишь реализовать очередной клиент — в случае, если мы хотим работать с новым мессенджером, или адаптер — если хотим добавить возможность взаимодействия с интересующим нас сервисом, например с Jira.

Основные компоненты

Рассмотрим более подробно каждый компонент архитектурного решения.

Клиенты

Первым звеном в работе сервиса являются клиенты. Это компоненты, которые нацелены на работу с конкретным мессенджером. Они занимаются выполнением следующих задач:

• приём сообщений от пользователей

• сбор информации о пользователях

• отправка запросов на обработку сообщений пользователей в асинхронный сервис обработки

• отправка результатов обработки сообщений пользователям 

Клиенты отправляют сообщение от пользователей и всю необходимую информацию о них в Async-server. Отправляемая информация представлена в виде сущности:

@Getter @Setter public class UserMessage {     //сообщение от пользователя     private String text;     //инициировано ли событие нажатием по кнопке     private boolean callback;     //id сообщения     private String messageId     //id чата      private String chatId;     //информация о пользователе       private User originalUser;     //из какого клиента было отправлено сообщение     private Client client;     //было ли сообщение из группового чата     private boolean isGroupChat;     //название чата      private String channelName; }  public enum Client {     TELEGRAM; }  @Getter @Setter public class User {     //id пользователя в мессенджере     private String id;     //имя пользователя     private String firstName;     //фамилия пользователя     private String lastName;     //псевдоним пользователя     private String userName; }

После обработки сообщения пользователя Async-server отправляет результат обратно в клиент в виде сущности:

@Getter @Setter public class Payload {      /*     указываем, какое сообщение должно быть по итогу     POST - отправка обычного сообщения     EDIT - исправление уже существующего     DELETE - удаление     для edit и delete надо указать originalId     */     private SendMethod sendMethod;     private String originalId;     //id сообщения, в ответ на который необходимо прислать сообщение     private String replyTo;     //id чата, в который необходимо отправить сообщение     private String chatId;     //текстовое сообщение пользователю     private String text;     //клавиатура     private String keyboard;        /*     указываем тип отправляемого содержимого     SIMPLE - обычный текст     DOCUMENT - отправка документа     */     private MediaType mediaType;     //имя отправляемого файла     private String fileName;     //файл         private byte[] data;     //в какой клиент осуществлять отправку      private Client client; }

Async-server

Первоочередной задачей было создание легко расширяемой и легко читаемой архитектуры классов, отвечающих за обработку команд. Так как количество команд бота, которые он способен обработать, может быть неограниченным, использовать switch-case для того, чтобы узнать, какую именно команду выполнить, очевидно является плохим решением. Все когда-то встречали код, в котором блок case расстилается на десятки, а то и сотни строк! Это абсолютно неприемлемое решение для нас.

В данном кейсе нам отлично подходил функционал Spring Framework. Необходимо создать базовый класс, от которого будут наследоваться все классы, занимающиеся обработкой команд пользователя. Помимо этого, классы-наследники должны быть отмечены аннотацией @Component. С её помощью мы даём понять spring, что нам необходимо создать bean данного класса.

public abstract class AbstractBaseHandler {      protected List<Payload> handle(UserMessage usermassage) ;   }

Теперь мы можем получить все классы, являющиеся наследниками AbstractBaseHandler, следующим образом: 

@Service public class HandlerProvider {  private List<AbstractBaseHandler> handlers;  @Autowired public void setHandlers(List<AbstractBaseHandler> handlers) {     this.handlers = handlers;  } }

Первым делом spring будет искать в своём контейнере bean List<AbstractBaseHandler>. Не обнаружив его, он найдёт всех наследников AbstractBaseHandler, которые являются bean, после чего «заинжектит» в наш List.

Следующий шаг: необходимо закрепить команды бота за классами, которые занимаются их обработкой, а также возможность получения экземпляра класса в зависимости от того, какую команду отправил нам пользователь.

Один из способов решения данной задачи — использование reflection api. Для этого создали аннотацию @Command, в которую мы передаём массив команд. Их будет обрабатывать наш класс.

@Retention(RUNTIME) @Target(TYPE) public @interface Command {     /**      * Возвращает список команд, поддерживаемых обработчиком      *      * @return список команд, поддерживаемых обработчиком      */     String[] command(); }

Таким образом мы можем получить необходимый экземпляр класса, в соответствии с введённой командой пользователя:

@Service public class HandlerProvider {   private List<AbstractBaseHandler> handlers;  @Autowired public void setHandlers(List<AbstractBaseHandler> handlers) {      this.handlers = handlers;  }    public void process(UserMessage usermassage) {   AbstractBaseHandler =  getHandler(usermassage.getText()).handle(usermassage);   Дальнейшая обработка…  }    private AbstractBaseHandler getHandler(String text) {      return handlers.stream()              .filter(handler -> handler.getClass()                      .isAnnotationPresent(BotCommand.class))              .filter(handler -> Stream.of(handler.getClass()                              .getAnnotation(BotCommand.class)                              .command())                   .anyMatch(c -> text.toLowerCase().startsWith(c))))              .findAny()              .orElseThrow(UnsupportedOperationException::new);  } }

Далее необходимо позаботиться о безопасности: ограничить доступ к боту для незарегистрированных пользователей. Для этого мы создали аннотацию @BotRole, которая будет нести в себе информацию о том, какой минимальной ролью должен обладать пользователь для обращения к модулю:

@Retention(RUNTIME) @Target(METHOD) public @interface BotRole {       /**  * @return возвращает роль, для которой разрешено выполнение команды  */ Role role();  /**  * @return возвращает наименование модуля  */ Module module();        }

После получения экземпляра класса из аннотации узнаём требуемую роль к модулю, отправляем запрос в User-manager  и сравниваем с текущей ролью пользователя в модуле.

Таким образом мы получаем: 

• легко расширяемую и легко читаемую архитектуру классов, отвечающих за обработку команд

• безопасность 

• интеграцию с ролевой моделью user-manager 

Для вызова меню с наборами автотестов и для запуска автотестов мы имеем два отдельных класса — AutoTestsMenuHandler и StartBuildHanlder, соответственно:

@Component @Command(commandName = "/tests", message = "Меню запуска тестов") public class AutoTestsMenuHandler extends AbstractBaseHandler {      @BotRole(role = Role.USER, module = Module.JENKINS)     protected List<Payload> handle(UserMessage usermassage) {         Обработка логики     } }

@Component @Command(commandName = "/start_build", message = "Запуск автотестов") public class StartBuildHandler extends AbstractBaseHandler {       @BotRole(role = Role.USER, module = Module.JENKINS)      protected List<Payload> handle(UserMessage usermassage) {         Обработка логики     } }

Вся структура меню, из которого происходит запуск автотестов, хранится в БД. В нашем случае это PostgreSQL.

CREATE TABLE public.at_menu (  id int8 NOT NULL,  command varchar(255) NULL,  name varchar(255) NULL,  parent int8 NULL,  CONSTRAINT menu_pkey PRIMARY KEY (id),  CONSTRAINT menu_parent FOREIGN KEY (parent) REFERENCES public.at_menu (id) );

Таблица имеет следующие столбцы:

• command — команда, которая будет исполняться при нажатии

• name — название кнопки

• parent — родительский элемент

Наличие столбца parent позволяет нам выстроить древовидную структуру. Это особенно актуально при большом количестве кнопок, так как их можно группировать в разделы и подразделы.

User-manager

Первоочередной задачей было позаботиться о безопасности, чтобы незарегистрированные пользователи не имели доступа к сервису. 

Если у других компонентов появляется необходимость удостовериться в том, что пользователь зарегистрирован в системе или он обладает необходимыми правами, они обращаются в User-manager за следующей информацией: 

• роли в модулях

• авторизованные мессенджеры

• ID в мессенджерах

• псевдоним в  мессенджерах

Каждому пользователю присваивается связка Module + Role. Module — это сгруппированный  набор определённых команд бота. Role — это одна из ниже перечисленных ролей пользователя в Module:

• READER

• USER

• ADMIN

Таким способом можно разграничивать права пользователя во всех модулях сервиса.

Jenkins-adapter

В данный компонент был вынесен весь функционал по взаимодействию с Jenkins. Он непосредственно инициирует запуск джоб с помощью отправки API-запроса в Jenkins, получает результат выполнения джоб и формирует отчёт об итогах выполнения автотестов. 

В ранних версиях бота вся информация о наличии новых билдов осуществлялась при помощи API-запросов. Это очень сильно нагружало Jenkins. В текущей версии бота Jenkins-adapter получает информацию о новых билдах из rss feed. Это существенно снизило нагрузку на Jenkins.

Помимо уже имеющегося функционала по получению отчёта о прохождении автотестов и запуска их из бота, текущая версия обросла дополнительными фичами. Давайте рассмотрим подробнее каждую из них.

Тэгание ответственных лиц

В ранней версии бота был недостаток: при взаимодействии с пользователями через групповые чаты отчёты могли просто потеряться среди большого количества сообщений. Ответственные за тот или иной набор тестов лица могли пропустить информацию о том, что не все автотесты были успешно пройдены. В текущей реализации при наличии неуспешных тестов бот дополнительно к отчёту тэгает ответственного пользователя.

Перезапуск автотестов

При получении неудовлетворительных результатов зачастую имеется необходимость запустить джоб с упавшими тестами. Особенно это характерно для UI-тестов, так как процент успешных среди них достаточно невысок (по причине их низкой стабильности), по сравнению, например с API-тестами. Нам хотелось сократить время этих рутинных операций, чтобы осуществлять перезапуск можно было по нажатию кнопки из мессенджера. Поэтому, если сборка неуспешная, формируется клавиатура с двумя дополнительными кнопками: «Перезапуск упавших тестов» и «Перезапуск сборки».

Вся информация о том, какой джоб перезапустить, хранится в callback кнопке (более подробно её рассмотрим в главе Пользовательский сценарий). Тelegram имеет ограничение на количество передаваемых символов в callback. Мы решили данную проблему, создав дополнительную таблицу в базе данных, в которой хранится эта информация, а в callback «зашиваем» лишь id этой записи.

Статистика выполнения автотестов

Еще одна из полезных фичей, которая появилась в текущей версии, — получение статистики по результатам прохождения автотестов.

После получения результатов автотестов Jenkins-adapter записывает данные в БД. По заданному расписанию информация отправляется в Async-server. Async-server отправляет данное сообщение в нужный клиент, а он доставляет сообщение пользователю, подписавшемуся на рассылку статистики.

Регистрация пользователей

Так как взаимодействовать с ботом могут только зарегистрированные пользователи, было важно реализовать функционал, который бы позволял осуществлять сбор всей необходимой информации для регистрации  пользователя. Для этого был создан функционал диалога с ботом. Каждый желающий получить доступ к системе просит своего коллегу, уже имеющего доступ, дать ему реферальный код. Он необходим для выполнения команды, инициирующей запуск диалога с ботом.

Запрос на регистрацию нового пользователя отправляется администраторам бота после завершения диалога.

Это в разы сокращает время на регистрацию новых пользователей в системе, так как нет необходимости лично проводить опрос каждого претендента на доступ.

Пользовательский сценарий

Для демонстрации пользовательского сценария заполним данными ранее созданную таблицу at_menu:

INSERT INTO public.at_menu (id,command,name,parent) VALUES                     (1,'/tests 1','UI тесты',NULL),                     (2,'/tests 2','API тесты',NULL),                     (3,'/tests 3','Мобильные тесты',NULL),                     (4,'/start_build 4','Портал',1),                     (5,'/start_build 5', 'Портал',2),                     (6,'/start_build 6','Android',3),                     (7,'/start_build 6','IPhone',3);

Теперь представим себе следующий сценарий: зарегистрированный пользователь осуществляет запуск автотеста из бота и после его выполнения получает отчёт об итогах. Давайте рассмотрим, что происходит на системном уровне при выполнении данного сценария. 

Пользователь отправляет боту команду /tests. Данная команда инициирует вызов метода handle обработчика AutoTestsMenuHandler в компоненте Async-server. Команда /tests без аргументов сообщает обработчику, что необходимо вернуть разделы меню, не имеющие родительских элементов.  К БД будет выполнен запрос с условием parent = NULL. Таким запросом мы получим стартовое меню. 

После получения данных из БД мы формируем клавиатуру с кнопками. Каждая кнопка будет иметь имяname, которое будет соответствовать столбцу name, иcallback (мета-информация, которую содержит в себе кнопка), которое будет соответствовать столбцуcommand. Клавиатура представлена в виде сущностей:

@Getter @Setter public class Button {    //Имя кнопки     private String name;    //Callback кнопки    privat String callback; }  @Getter @Setter public class Row {    //Список кнопок в ряду    private List<Button> buttons; }  @Getter @Setter public class Keyboard {      //Список рядов с кнопками     private List<Row> rows;    public String toString() {      try {        ObjectMapper objectMapper = new ObjectMapper();        return objectMapper.writeValueAsString(this);      } catch (JsonProcessingException e) {        //Обработка      }    } }

Сформированный экземпляр классаPayload отправляется в один из клиентов, который, в свою очередь, формирует сообщение для пользователя и отправляет его:

//Создаём клавиатуру для Telegram private InlineKeyboardMarkup setKeyboard(Payload payload) throws JsonProcessingException {     //создаём клавиатуру     ObjectMapper objectMapper = new ObjectMapper();     List<List<InlineKeyboardButton>> keyboard = new ArrayList<>();     if (payload.getKeyboard() != null && !payload.getKeyboard().isEmpty()) {         //Получаем клавиатуру, созданную в async-server         Keyboard additionalButtons = objectMapper.readValue(payload.getKeyboard(), Keyboard.class);         for (Row row : additionalButtons.getRows()) {             //надо создать строку             List<InlineKeyboardButton> additionalRow = new ArrayList<>();             for (Button button : row.getButtons()) {                 //создаём кнопку                 InlineKeyboardButton btn = new InlineKeyboardButton();                 btn.setText(button.getName());                 btn.setCallbackData(button.getCallback());                 //добавляем в строку                 additionalRow.add(btn);             }             //добавляем в клавиатуру             keyboard.add(additionalRow);         }     }          InlineKeyboardMarkup inlineKeyboardMarkup = new InlineKeyboardMarkup();     inlineKeyboardMarkup.setKeyboard(keyboard);     return inlineKeyboardMarkup; }   //отправляем сообщение пользователю private void sendMessage(Payload payload) throws TelegramApiException {     SendMessage sendMessage = new SendMessage();      sendMessage.setChatId(payload.getChatId());     try {        sendMessage.setReplyMarkup(setKeyboard(payload));     } catch (JsonProcessingException e) {         //обработка     }     sendMessage.setParseMode(ParseMode.HTML);     sendMessage.setText(payload.getText());      //отправляем сообщение пользователю     execute(sendMessage);  }

В нашем случае пользователь получит сообщение с кнопками:

• «UI тесты»

• «API тесты»

• «Мобильные тесты»

Как уже было сказано ранее, в каждую кнопку зашитcallback. При нажатии кнопки боту отправляется команда, которая находится вcallback. После нажатия пользователем кнопки «Мобильные тесты» боту будет отправлена команда /tests 3. Цифра три — это аргумент команды, который является id записи в таблице. К БД будет выполнен запрос с условием parent = 3. После этого пользователю будет отправлена клавиатура с кнопками:

• «Android»

• «IPhone»

При нажатии пользователем кнопки «Android» боту отправится команда /start_build 6. В данной команде аргумент — это id заранее заготовленного пресета (описывается в первой части статьи). Данная команда инициирует выполнение метода  handle обработчика StartBuildHandler. Обработчик отправит REST API запрос в Jenkins-adapter, который, в свою очередь, отправит запрос со всеми параметрами в Jenkins. Произойдёт запуск build, после чего пользователю отправится уведомление о том, что его build поставлен в очередь.

По окончании выполнения теста Jenkins-adapter сформирует отчёт и пользователю придёт уведомление с его результатами.

Функционал, не связанный с автотестами

Опыт использования мессенджеров в работе нам показался весьма положительным, поэтому со временем наш сервис стал обрастать функционалом, далеко выходящим за рамки автотестирования.

Отпуска

Одним из первых появился функционал по работе с отпусками сотрудников. В User-manager добавили возможность задать принадлежность пользователя организационной команде, даты и вид отсутствия, реализовали механизм оповещения об отпусках пользователей в команде по подписке. Теперь руководители своевременно получают информацию об отсутствующих сотрудниках. Им также поступает информация о тех сотрудниках, кого не будет на рабочем месте в ближайшее время.

Своевременное получение данной информации существенно упрощает планирование и управление командой.

Интеграция с Jira

Следующим функционалом, никак не связанным с автотестированием, стало взаимодействие с Jira. Зачастую сотрудники забывают списывать время, поэтому мы решили реализовать функционал, который бы присылал пользователю регулярные уведомления о количестве списанных им часов на задачи. 

По аналогии с Jenkins-adapter, вся работа с Jira была вынесена в отдельный микросервис Jira-adapter. По заданному расписанию происходит отправка REST API запроса к Jira с целью получения информации о затраченном времени за прошлую неделю. После получения данной информации происходит формирование отчёта в HTML-формате.  

Заключение

В итоге, после внедрения всех технических решений, описанных в данной статье, новая версия, по сравнению со старой, имеет следующие преимущества:

• микросервисная архитектура

• есть возможность осуществить в кратчайшие сроки любые интеграции — всё ограничивается лишь нашей фантазией

Проект по разработке сервиса дал нам интересный и полезный опыт. Кроме того, мы значительно прокачали свои навыки:

• разработки на Spring Boot

• разработки чат-ботов

• проектирования баз данных

• проектирования масштабируемых систем