Размещено на http://www.allbest.ru/

ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет компьютерных наук

Департамент программной инженерии

Выпускная квалификационная работа

по направлению подготовки 09.03.04 «Программная инженерия»

на тему Веб-приложение для планирования и мониторинга релизного цикла комплекса прикладных программ

Выполнил

студент группы БПИ142

4 курса бакалавриата

образовательной программы

«Программная инженерия»

Кан Сергей Александрович

Москва 2018



Основные определения, понятия и термины

1. Релиз - версия программы.

2. Релизный цикл - период времени, за который новый функционал проходит путь от принятия решения о его реализации до выхода в продуктивную версию приложения [6].

3. Релизная методология - это набор техник и правил, которые применяются командой разработки для поддержки регулярного выпуска новых версий разрабатываемого приложения.

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

5. Фреймворк - программная платформа, определяющая структуру программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта.

6. REST - архитектурный стиль взаимодействия компонентов распределённого приложения в сети. Веб-службы, построенные с учетом REST, называются RESTful.

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



Содержание

Введение

Глава 1. Средства для релиз-менеджмента. Релизный цикл

1.1 Направление исследования

1.2 Релизная методология

1.2.1 Стандартный релизный цикл

1.3 Сложности, возникающие при разработке

1.4 Обоснование предлагаемого способа

1.5 Существующие решения

1.6 Функционал, требующийся в рамках релиз-менеджмента

1.7 Методика исследования

Глава 2. Описание используемых методов

2.1 Архитектура приложения

2.2 Обоснование технологического стека

2.2.1 Клиентская часть

2.2.2 Серверная часть

2.2.3 Другие средства, использованные при разработке

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

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

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

2.5.1 Описание получения информации о релизе и результатах автотестов с помощью API приложения

2.5.2 Описание получения информации о релизе и результатах автотестов приложением самостоятельно

2.5.3 Описание добавления информации о релизе и результатах автотестов вручную

2.6 Описание обновления плана релиза

2.7 Описание отправки уведомлений

2.7.1 Описание отправки уведомлений в Telegram

2.7.2 Описание отправки уведомлений в Slack

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

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

3.2 Веб-приложение

3.2.1 Структура приложения

3.3.2 Принцип работы приложения

3.4 Сервис

3.4.1 REST-интерфейс

3.4.2 Формат данных3

3.4.3 База данных

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

3.5.1 Основное окно (дэшборд)

3.5.2 Страница планирования релизов

3.5.6 Страница релизного плана

3.5.7 Страница результатов прогона автоматизированных тестов

Заключение

Список источников



Введение

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

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

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

Достижение поставленной цели предполагает выполнение следующих задач:

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

? изучить существующие методологии релиз-менеджмента

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

? сформулировать требования к веб-приложению

? разработать архитектуру приложения и методы взаимодействия компонентов

? реализовать приложение в соответствии с поставленными требованиями

? сформировать пакет технической документации

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

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

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

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

релиз приложение уведомление менеджмент



Глава 1. Средства для релиз-менеджмента. Релизный цикл

1.1 Направление исследования

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

1.2 Релизная методология

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

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

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



1.2.1 Стандартный релизный цикл

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

Рисунок 1. Стандартный релизный цикл

Итак, рассмотрим стандартный пример (рис 1). Команда разработки работает по методологии скрам и имеет трехнедельный спринт. При разработке используется четыре среды развертывания - среда разработки (DEV), тестовая среда (TEST), препродуктивная среда (PREPROD) и продуктивная среда - конечный продукт (PROD). Таким образом, каждую третью неделю происходит релиз на продуктивной среде [6].

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

1.3 Сложности, возникающие при разработке

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

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

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

? релизную стратегию внутри одного приложения сложно поддерживать ввиду отсутствия инструмента для планирования и управления релизами;

? возникают сложности в организации взаимодействия между релизными менеджерами разных приложений;

1.4 Обоснование предлагаемого способа

Существует несколько способов решения обозначенной проблемы:

? назначение главного релизного менеджера, чьими обязанностями будет контроль за соблюдением релизной стратегии и планированием релизов всеми приложениями;

? ввести регулярные собрания ответственных за все приложения для совместного планирования релизов;

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

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

1.5 Существующие решения

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

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



1.6 Функционал, требующийся в рамках релиз-менеджмента

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

? Работа с инструментами непрерывной интеграции (Jenkins)

? Работа с инструментами планирования, управления проектами (Jira, Trello, MS Project)

? Работа с системой контроля версий Git

? Планирование релизов, заведение расписания релизов

? Работа с корпоративными мессенджерами (Slack, Skype for business)

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

1.7 Методика исследования

Проект разделяется на три части: теоретическая, аналитическая и практическая. В первой части рассматривается и изучается проблема пользователя, выявляется важность и актуальность темы. Выбираются способы исследования проблемы, рассматриваются существующие аналоги, также ставятся цели и задачи, выполнение которых определяет направление следующей аналитической части. В ней разбираются модели и решения, используемые в системе, описываются алгоритмы и архитектура приложения. Заключительной частью является создание программного продукта и пакета документации. Для простоты понимания читателем далее разрабатываемая система также будет называться RMS - release management system.

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



Глава 2. Описание используемых методов

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

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

2.1 Архитектура приложения

Разрабатываемая система представляет собой клиент-серверное приложение. Пользователи взаимодействуют с веб-браузером через веб-приложение, которое обращается к API и вызывает соответствующие методы. Если пользователями являются не люди, а приложения, эти приложения обращаются к API самостоятельно.

Сервер предоставляет собой RESTful API, который также взаимодействует с базой данных MongoDB.

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

Методы, использующиеся для передачи и получения данных, описаны далее в главе.



Рисунок 2. Архитектура веб-приложения "RMS"

2.2 Обоснование технологического стека

При разработке учитывались такие факторы, как:

? возможность работы в режиме реального времени,

? высокая производительность, выполнение асинхронных действий,

? масштабируемость проекта

? масштабируемость базы данных.

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

2.2.1 Клиентская часть

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



Таблица 1 Технологический стек клиенсткой части

React.js	Javascript-библиотека для построения интерфейса пользователя. В схеме разделения данных MVC (model-view-controller) React отвечает за отображение данных (View). Использование данной библиотеки позволяет строить одностраничные приложения, динамически создавать пользовательский интерфейс [10].
Redux	Контейнер для состояния приложения. Современные одностраничные приложения подразумевает большое количество манипуляций с состоянием приложения - Redux позволяет упростить этот процесс и хранить все состояние приложения в специальном объекте - store [11].
redux-saga	Библиотека, позволяющая упростить процесс обработки сторонних эффектов (например, запросы к серверу)
Material UI	Библиотека, имплементирующая React-компоненты в стиле Material Design от компании Google.

2.2.2 Серверная часть

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

Таблица 2 Технологический стек серверной части

Node.js	Программная платформа, основанная на движке V8, позволяющая писать масштабируемые сетевые приложения, использующая неблокирующее асинхронное взаимодействие. Разработчик имеет возможность писать серверные приложения, используя язык JavaScript [8].
Express	Веб-фреймворк для приложений Node.js, предоставляющий для веб-приложений обширный набор функций и позволяющий быстро создать надежный API [4].

2.2.3 Другие средства, использованные при разработке

Таблица 3 Другие средства, использованные при разработке

MongoDB	Документоориентированная СУБД, не требующая описания схем таблиц. Данные хранятся в виде документов, созданных в формате JSON, объединенных в коллекции. Для текущей работы это наиболее приемлемый вариант, так как данные о результатах автоматизированных тестов, так же как и информация о последних релизах, поступает в виде JSON-файлов. К тому же для разрабатываемого приложения важным фактором является масштабируемость, MongoDB позволяет делать это, не затрачивая много усилий [7].
Socket.io	JavaScript-библиотека, используемая в веб-приложениях, предназначенная для обмена данных в режиме реального времени. Данная библиотека состоит из двух частей - клиентской и серверной (для приложения Node.js). Основным протоколом является WebSocket, но в некоторых случаях, когда это требуется, могут быть использованы другие (например, Ajax) [12].
Mongoose	ODM (object document mapper), позволяющий определять объекты со строго-типизированной схемой, соответствующей MongoDB.[1] Mongoose будет использоваться для того, чтобы определить модель для объектов, описывающих результат автотеста или релиз, чтобы в случаях, если отправляющая сторона послала неправильную информацию, приложение могло корректно это обработать.
Babel	Транспайлер, позволяющий разработчикам писать приложения на различных языках программирования и переводящий их код в JavaScript, который может быть обработан современными веб-браузерами [3].
Webpack	Сборщик файлов приложений, написанных на JavaScript [13]
npm	Менеджер пакетов, входящий в состав Node.js [9].
node-slackr	NPM-пакет, имплементирующий функционал отправки уведомлений в Slack
node-telegram-bot-api	NPM-пакет, имплементирующий функционал отправки уведомлений в Telegram

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

1. Пользователь вводит данные - e-mail, пароль и подтверждение пароля - в специальную форму.

2. Данные отправляются на сервер, происходит проверка на наличие в базе данных пользователя с такими же данными. В случае успешного прохождения проверки пользователь сохраняется в базе данных со статус non-active.

3. Пользователю на указанную почту отправляется письмо для активации аккаунта.

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

5. Пользователь проходит аутентификацию с помощью e-mail и пароля.



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

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

1. Пользователь вводит свой E-mail и пароль.

2. Данные отправляются на сервер, ведется поиск по e-mail в базе данных.

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

4. Если пароли совпадают, генерируется авторизационный токен, предусматривающий определенную роль пользователя.

5. Теперь при обращении пользователя к какому-то ресурсу, данные будут предоставляться ему в зависимости от его роли согласно авторизационному токену.

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

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

2.5.1 Описание получения информации о релизе и результатах автотестов с помощью API приложения

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

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

Алгоритм:

1. Приложение завершает процесс установки нового релиза на очередную среду развертывания / завершается прогон автоматизированных тестов.

2. Запускается скрипт, отправляющий на разрабатываемый сервис посредством вызова API POST-запрос с актуальной информацией в виде JSON-объекта.

3. Сервер разрабатываемой системы принимает JSON-объект и сохраняет информацию в базу данных

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

2.5.2 Описание получения информации о релизе и результатах автотестов приложением самостоятельно

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

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

Алгоритм:

1. Приложение завершает процесс установки нового релиза на очередную среду развертывания / завершается прогон автоматизированных тестов.

2. Приложение обновляет информацию о релизах на healthcheck-е.

3. Релизная система с заданной периодичностью опрашивает healthcheck, проверяя информацию.

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

2.5.3 Описание добавления информации о релизе и результатах автотестов вручную

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

Алгоритм:

1. Пользователь вводит информацию об актуальном релизе

2. После заполнения формы информация отправляется на сервер

3. Сервер обрабатывает входящую информацию, сохраняет данные в базу данных.

2.6 Описание обновления плана релиза

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

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

1. В релизную систему приходит информация о новом релизе.

2. В базе данных ищется существующий план релиза с такой же мажорной версией, как у нового (например, в версии 1.2.0 мажорной версией является 1)

3. Если план релиза не найден, создается новый. Если такой уже существует, в массив deploys добавляется новый элемент. На странице плана релиза список деплоев обновляется.

4. В случае, если это первый из деплоев, статус плана релиза изменяется на “Released”.

2.7 Описание отправки уведомлений

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

2.7.1 Описание отправки уведомлений в Telegram

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

1. Создать бота с помощью Telegram-бота @BotFather. После создания бота будет получен идентификационный токен.

2. Создать канал в Telegram, в который будут посылаться сообщения. Получить chatId.

3. С помощью npm-пакета node-telegram-bot-api подключить бота программно с помощью его идентификационного токена.

4. С помощью chatId созданного ранее канала подключиться к нему.

5. Отправить сообщение.

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



2.7.2 Описание отправки уведомлений в Slack

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

1. Настроить интеграцию вашего рабочего пространства с помощью Slack Incoming Webhook.

2. В коде добавить интеграцию с помощью полученного webhook-а.

3. Сформировать сообщение, указать параметры: канал, в который будет отправляться сообщение, содержание, дополнительные опции.

4. Отправить сообщение.

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

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



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

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

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

1) Программа должна быть представлена в виде веб-саи?та (веб-приложения);

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

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

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

3) Авторизация пользователя

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

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

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

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

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

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

5) Релизы

a. История релизов

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

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

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

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

? Название проекта

? Название релиза

? Приложение, на которое накатывается релиз

? Среда развертывания приложения, на которую накатывается релиз

? Запланированная дата начала релиза

? Запланированная дата окончания релиза

? Актуальная дата релиза

? Версию релиза

? Тип релиза - Release / BugFix / HotFix и т.д.

? Статус релиза - Released / Planned / In Process / Delayed / Canceled

? Ответственный за релиз

? Ссылки (например, на соответствующую задачу в Jira)

? Комментарии

c. Обновление плана релиза

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

? Приложения через API должны иметь возможность отправлять информацию в систему посредством JSON-файла. Система ищет созданный релизный план по версии релиза и обновляет его, добавляя на его страницу очередной деплой;

? Если приложения предоставили доступ к специальным веб-страницам с информацией об актуальной версии релиза в виде JSON-строки, RMS должна предоставлять возможность периодически проверять эту страницу и обновлять информацию о плане релиза в случае обновления данных;

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

d. Отображение планов релизов

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

e. Страница плана релиза

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

6) Автотесты

a. История результатов автотестов

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

b. Страница с результатами прогона автотестов

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

7) Аналитика

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

8) API

К RMS должна идти электронная swagger-документация с описанием всех доступных методов (отправки релиза, результатов автотестов). Описание должно включать url запроса, метод запроса, описание заголовков и тела.

3.2 Веб-приложение

Клиентская часть является одностраничным приложением (SPA), написанным с помощью библиотеки React.

Далее описана структура проекта и особенности реализации.

3.2.1 Структура приложения

Для поддерживаемости кода и масштабирования проекта была использована следующая структура (рис. 5):



Рисунок 5. Структура проекта клиентской части

В папке “src” расположены все основные файлы. Точкой входа в приложении является файл index.js. Так как для управления состоянием приложения используется Redux, в папках actions и reducers описаны соответствующие объекты, относящиеся к различным сущностям в приложении. В папке sagas расположены в файлы с обработкой сторонних эффектов (middlewares). В папке sockets описаны действия с сокетами.

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



Рисунок 6. Файлы с реализацией работы одной сущности

3.3.2 Принцип работы приложения

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

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

1. Пользователь нажимает на кнопку

2. Компонент, с которым взаимодействует пользователь (форма), вызывает (dispatch) соответствующий экшн (action) Redux (“ADD_RELEASE”).

3. Данный экшн перехватывается соответствующей сагой (redux-saga), в которой обрабатываются сторонние эффекты (

a. В данном примере обрабатывается запрос на сервер для сохранения нового плана релиза, вместе с данными о релизе отправляется токен пользователя.

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

4. После обработки сторонних эффектов миддлвара диспатчит новый экшн, который перехватывается соответствующим редьюсером Redux.

5. В редьюсере обновляется состояние всего приложения, и нужные компоненты обновляются.

3.4 Сервис

3.4.1 REST-интерфейс

Доступ к серверу осуществляется посредством вызова API, состоящего из GET и POST-запросов. Ниже приведена таблица доступных методов (табл. 4):

Таблица 4 API сервиса

Путь (route)	Метод (HTTP method)	Заголовки (headers)	Тело запроса (body), параметры (parameters)	Значение
/releases/submit	POST	Content-Type:application/json	Название релиза, название проекта, приложение, среда развертывания, даты начала и окончания релиза (ожидаемые), актуальная дата релиза, версия релиза, связи с другими релизами, комментарии, ссылки, автор релиза	Создание релизного плана. Метод возвращает информацию об успешном или безуспешном создании релизного плана.
./tests/submit	POST	Content-Type:application/json	Тип теста, приложение, среда развертывания, процент успешного выполнения, success, сценарии, логи	Отправка результатов прогона автоматизированных тестов. Метод возвращает информацию об успешном или безуспешной отправке данных.
/releases/getrelease	GET	-	Параметры: id	Получение одного релиза. Ответ возвращается в виде JSON-объекта. В случае ошибки возвращается текст ошибки.
/releases/getreleases	GET	-	Параметры: дата начала, дата окончания, приложение, среда	Получение группы релизов. В случае отсутствия фильтров в параметрах возвращаются все сохраненные в базе данных релизы.
/releases/getdeploy	GET	-	Параметры: id	Получение одного деплоя. Ответ возвращается в виде JSON-объекта. В случае ошибки возвращается текст ошибки.
/releases/getdeploys	GET	-	Параметры: дата начала, дата окончания, приложение, среда развертывания	Получение группы деплоев. В случае отсутствия фильтров в параметрах возвращаются все сохраненные в базе данных деплои.
/tests/gettest	GET	-	Параметры: id	Получение результатов одного прогона автоматизированных тестов. Ответ возвращается в виде JSON-объекта. В случае возникновения ошибки возвращается текст ошибки.
tests/gettests	GET	-	Параметры: дата начала, дата окончания, приложение, среда развертывания	Получение результатов нескольких прогонов автоматизированных тестов. Ответ возвращается в виде JSON-объекта. В случае возникновения ошибки возвращается текст ошибки.

3.4.2 Формат данных

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

1) Информация о релизе (деплое)

Файл с информацией о релизе (деплое) должен быть составлен в соответствии со следующей схемой:

{

"name": String,

"app": String,

"env": String,

"date": Date,

"version": String,

"author": String

}

2) Результаты автотестов

Файл с результатами прогона автоматизированных тестов должен быть составлен в соответствии со следующей схемой:

{

"name": String,

"app": String,

"env": String,

"date": Date,

"success": Boolean,

“passrate”: String,

"scenarios”: [

“name”: String,

“success”: Boolean,

...

]

}

3.4.3 База данных

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

Основные модели данных, использующиеся в приложении:

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

Схема релиза Mongoose:

var ReleaseplanSchema = new Schema({ numberID: Number, name: String, app: String, env: String, startdate: Date, enddate: Date, actualdate: Date, version: String, type: String, author: String, project: String, status: String, stage: String, actualdate: Date, scope: String, comments: String, id: String, dependencies:[], deploys: [], predcessors: [] });

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

Схема деплоя Mongoose:

var ReleaseplanSchema = new Schema({ numberID: Number, name: String, app: String, env: String, date: Date,

version: String, type: String, author: String, });

3) Autotest - модель, описывающая результаты одного прогона автоматизированных тестов. В модели описывается название типа тестов (например, экспресс-тесты, полные тесты и т.д.), приложение и среда развертывания, на которой проводится тестирование, сценарии тестирования и их логи.

Схема автотеста Mongoose:

var AutotestSchema = new Schema({ numberID: Number, name: String, app: String, env: String, date: Date, success: String, scenarios: [], type: String

}

4) Application - модель, описывающая приложение. В модели указывается название приложения, ответственный за это приложение релизный менеджер.

Схема приложения Mongoose:

var applicationsSchema = new Schema({ app: String, owner: String });

5) Environment - модель, описывающая среду развертывания. В модели указывается название среды развертывания, а также список типов тестов, которые выполняются на данной среде развертывания.

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

Список коллекций:

1) Releases

2) Deploys

3) Autotests

4) Applications

5) Environments

3.4.3 Структура приложения

В проекте серверного приложения использовалась следующая структура (рис. 7):

Рисунок 7. Структура проекта серверного приложения

Для упрощения процесса разработки в проекте серверного приложения модели базы данных вынесены в папку “models”, все методы по работе с ней - в папку “controllers” [5].

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

Для понимания работы приложения рассмотрим примеры основных его экранов.

3.5.1 Основное окно (дэшборд)

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

Рисунок 8. Основное окно приложения (дэшборд)

Рисунок 9. Основное окно приложения. Выбор карточек для отображения

На карточке можно увидеть результаты последних прогонов автоматизированных тестов в зависимости от типа теста и актуальный релиз, установленный на данной среде развертывания. При нажатии на ссылки “View execution log” или “View release notes” открываются страницы логов автотестов или релизных заметок текущего релиза.



3.5.2 Страница планирования релизов

На странице планирования релизов отображается диаграмма Ганта с релизными планами (рис. 10). Статус релизного плана обозначается цветом. При наведении на релизный план отображается краткая информация о нем, а также появляется ссылка для перехода на страницу релизного плана.

Рисунок 10. Страница планирования релизов

3.5.6 Страница релизного плана

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



Рисунок 11. Страница релизного плана

3.5.7 Страница результатов прогона автоматизированных тестов

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

Рисунок 12. Страница результатов прогона автоматизированных тестов



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



Заключение

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

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

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

? сделать данную систему SaaS - software as a service. В дальнейшем предполагается, что данная система будет самодостаточна и для ее конфигурации не будет требоваться разработчик, любой пользователь сможет настроить ее под свои нужды;

? добавить Swagger-документацию, чтобы команды разработки могли протестировать работу API, знали, как им пользоваться и какого формата входные данные передавать;

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

? добавить интеграцию с Jira или другими подобными инструментами. При установке релиза должна заводиться соответствующая задача в Jira;

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

...