Файл: Критерии выбора средств разработки WEB-приложений.pdf

2.2. Алгоритм регистрации пользователя

1. Пользователь вводит данные – e-mail, пароль и подтверждение пароля – в специальную форму.
2. Данные отправляются на сервер, происходит проверка на наличие в базе данных пользователя с такими же данными. В случае успешного прохождения проверки пользователь сохраняется в базе данных со статус non-active.
3. Пользователю на указанную почту отправляется письмо для активации аккаунта.
4. После прохождения пользователем по ссылке, указанной в письме, статус пользователя в базе данных меняется на active.
5. Пользователь проходит аутентификацию с помощью e-mail и пароля.

2.3. Алгоритм аутентификации пользователя

Для аутентификации используется JWT – JsonWebToken. JWT является JSON-объектом, в котором хранится информация о пользователе, в данном случае, его e-mail, login и пароль [2]. Этот JSON-объект подписывается специальным секретным ключом, который позволяет его прочитать, но не позволяет изменить.

1. Пользователь вводит свой E-mail и пароль.
2. Данные отправляются на сервер, ведется поиск по e-mail в базе данных.
3. При совпадении электронных адресов входящий пароль шифруется по секретному ключу, шифр сравнивается с тем, что хранится в базе данных.
4. Если пароли совпадают, генерируется авторизационныйтокен, предусматривающий определенную роль пользователя.
5. Теперь при обращении пользователя к какому-то ресурсу, данные будут предоставляться ему в зависимости от его роли согласно авторизационномутокену.

2.4. Описание методов получения информации о релизах и результатах прогонов автоматизированных тестов

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

В рамках данной работы описываемый метод получения данных является наиболее предпочтительным. В настоящее время все больше команд разработки и компаний в целом используют средства для непрерывной интеграции – такие как Jenkins от компании Hudson или TeamCity от JetBrains [14].

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

Алгоритм:

1. Приложение завершает процесс установки нового релиза на очередную среду развертывания / завершается прогон автоматизированных тестов.
2. Запускается скрипт, отправляющий на разрабатываемый сервис посредством вызова API POST-запрос с актуальной информацией в виде JSON-объекта.
3. Сервер разрабатываемой системы принимает JSON-объект и сохраняет информацию в базу данных
4. Сервер вызывает событие прихода актуальной информации, сокет клиента, подписанный на события данного типа, обрабатывает новую информацию и обновляет ее на дэшбордах в режиме реального времени.

В некоторых ситуациях описанный ранее метод не может быть реализован ввиду отсутствия нужных инструментов. В таких случаях некоторые команды разработки создают специальные веб-страницы, на которых хранится информация об актуальном релизе. В данном случае, при предоставлении ссылок на эти веб-страницы, которые называются healthcheck-ами (от англ. Health– здоровье, check– проверять), веб-приложение способно с заданной периодичностью обходить их и собирать информацию своими средствами.

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

Алгоритм:

1. Приложение завершает процесс установки нового релиза на очередную среду развертывания / завершается прогон автоматизированных тестов.
2. Приложение обновляет информацию о релизах на healthcheck-е.
3. Релизная система с заданной периодичностью опрашивает healthcheck, проверяя информацию.
4. При изменении информации сервер вызывает событие прихода актуальной информации, сокет клиента, подписанный на события данного типа, обрабатывает новую информацию и обновляет ее на дэшбордах в режиме реального времени, новая информация сохраняется в базу данных.

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

Алгоритм:

1. Пользователь вводит информацию об актуальном релизе
2. После заполнения формы информация отправляется на сервер
3. Сервер обрабатывает входящую информацию, сохраняет данные в базу данных.

Основной сущностью релизной системы являетсярелиз, по сути являющийся планом релиза. Релизный менеджер заводит планы релизов вручную, указывает зависимости от других релизов, назначает предполагаемые даты установки релиза. При непосредственном релизе созданные ранее план необходимо обновить. Также в системе предусматривается возможность добавления деплоеводного релиза, когда релиз устанавливается с той же мажорной версией (например, 1.2.0), но в нем добавляется не новая функциональность, а, например, исправления последней добавленной (bugfix).

Алгоритм обновления плана релиза:

1. В релизную систему приходит информация о новом релизе.
2. В базе данных ищется существующий план релиза с такой же мажорной версией, как у нового (например, в версии 1.2.0 мажорной версией является 1)
3. Если план релиза не найден, создается новый. Если такой уже существует, в массив deploys добавляется новый элемент. На странице плана релиза список деплоев обновляется.
4. В случае, если это первый из деплоев, статус плана релиза изменяется на “Released”.

Для некоторых команд или компаний бывает важно знать текущее состояние системы, которую они разрабатывают, или изменения этого состояния. Например, productowner-ы приложения хотели бы знать, когда тесты на продуктивной среде их системы падают и в каких местах. Некоторые команды просто хотят знать о том, что их система перестала отвечать. Для этого в разрабатываемой программе будут предусмотрены средства для отправки уведомлений в популярные мессенджеры, часто используемые компаниями –Telegram и Slack.

Алгоритм отправки уведомлений в Telegram (рис. 3):

1. Создать бота с помощью Telegram-бота @BotFather. После создания бота будет получен идентификационный токен.
2. Создать канал в Telegram, в который будут посылаться сообщения. Получить chatId.
3. С помощью npm-пакета node-telegram-bot-api подключить бота программно с помощью его идентификационного токена.
4. С помощью chatId созданного ранее канала подключиться к нему.
5. Отправить сообщение.

Рисунок 3. Пример использования пакета «node-telegram-bot-api»

Алгоритм отправки уведомлений в канал в Slack (рис. 4):

1. Настроить интеграцию вашего рабочего пространства с помощью SlackIncomingWebhook.
2. В коде добавить интеграцию с помощью полученного webhook-а.
3. Сформировать сообщение, указать параметры: канал, в который будет отправляться сообщение, содержание, дополнительные опции.
4. Отправить сообщение.

Рисунок 4. Пример использования пакета «node-slackr»

Выводы по главе

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

Глава 3. Методы реализации и практические результаты

3.1. Функциональные требования

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

1. Программа должна быть представлена в виде веб-сайта (веб-приложения);
2. Регистрация пользователя

Регистрация в приложении должна происходить с помощью e-mail и пароля. Во время регистрации пользователь указывает его имя, должность в компании, принадлежность к конкретному проекту, роль в проекте, email и пароль (дважды).

При успешной регистрации пользователя перенаправляет на основное окно приложения –дэшборд. При возникновении ошибок приложение сообщает об этом пользователю посредством всплывающего окна.

1. Авторизация пользователя

Авторизация происходит с помощью e-mail и пароль. При успешной авторизации пользователя перенаправляет на основное окно приложения – дэшборд. Длительность сессии должна составлять один час.

При возникновении ошибки во время авторизации приложение сообщает об этом пользователю посредством выделения места ошибки – неверное имя пользователя / пароль.

1. Отображение актуальной информации о приложениях

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

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

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

1. Релизы
   1. История релизов

Должна быть предусмотрена возможность просмотра истории релизов (деплоев) в зависимости от различных фильтров – даты, приложения, среды развертывания.

• 1. Создание планов релизов

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

План релиза должен включать:

• Название проекта
• Название релиза
• Приложение, на которое накатывается релиз
• Среда развертывания приложения, на которую накатывается релиз
• Запланированная дата начала релиза
• Запланированная дата окончания релиза
• Актуальная дата релиза
• Версию релиза
• Типрелиза – Release / BugFix / HotFixит.д.
• Статусрелиза – Released / Planned / In Process / Delayed / Canceled
• Ответственный за релиз
• Ссылки (например, на соответствующую задачу в Jira)
• Комментарии
  1. Обновление плана релиза

RMS должна позволять изменять план релиза несколькими способами:

• Приложения через API должны иметь возможность отправлять информацию в систему посредством JSON-файла. Система ищет созданный релизный план по версии релиза и обновляет его, добавляя на его страницу очередной деплой;
• Если приложения предоставили доступ к специальным веб-страницам с информацией об актуальной версии релиза в виде JSON-строки, RMS должна предоставлять возможность периодически проверять эту страницу и обновлять информацию о плане релиза в случае обновления данных;
• В случае отсутствия у приложений возможности передавать данные первыми двумя способами, у пользователя должна быть возможность изменить план релиза вручную.
  1. Отображение планов релизов