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

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

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

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

1. Автотесты
   1. История результатов автотестов

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

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

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

1. Аналитика

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

1. API

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

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

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

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

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

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

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

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

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

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

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

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

1. Пользователь нажимает на кнопку
2. Компонент, с которым взаимодействует пользователь (форма), вызывает (dispatch) соответствующий экшн (action) Redux (“ADD_RELEASE”).
3. Данный экшн перехватывается соответствующей сагой (redux-saga), в которой обрабатываются сторонние эффекты (
   1. В данном примере обрабатывается запрос на сервер для сохранения нового плана релиза, вместе с данными о релизе отправляется токен пользователя.
   2. В зависимости от прав пользователя релиз или сохраняется или на клиент отправляется информация о том, что данное действие не может быть выполнено текущим пользователем ввиду отсутствия подходящих прав доступа.
4. После обработки сторонних эффектов миддлварадиспатчит новый экшн, который перехватывается соответствующим редьюсеромRedux.
5. В редьюсере обновляется состояние всего приложения, и нужные компоненты обновляются.

3.3. Сервис

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

Таблица 4

API сервиса

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

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

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

{

"name" : String,

"app" : String,

"env" : String,

"date" : Date,

"version" : String,

"author" : String

}

1. Результаты автотестов

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

{

"name" : String,

"app" : String,

"env" : String,

"date" : Date,

"success" : Boolean,

“passrate” : String,

"scenarios” : [

“name” : String,

“success” : Boolean,

. . .

]

}

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

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

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

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

varReleaseplanSchema = 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: []
});

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

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

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

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

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

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

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

}

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

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

varapplicationsSchema = new Schema({

app: String,
owner: String
});

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

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

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

1. Releases
2. Deploys
3. Autotests
4. Applications
5. Environments

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

• сделатьданнуюсистему SaaS - software as a service. В дальнейшем предполагается, что данная система будет самодостаточна и для ее конфигурации не будет требоваться разработчик, любой пользователь сможет настроить ее под свои нужды;
• добавить Swagger-документацию, чтобы команды разработки могли протестировать работу API, знали, как им пользоваться и какого формата входные данные передавать;
• добавить ролевую модель на уровне организации. На данном этапе подразумевается, что система разворачивается на локальных серверах отдельно взятой компании и настраивается под местные команды разработки. В будущем система должна позволять регистрировать разные компании, приложение должно быть развернуто в сети Интернет;
• добавить интеграцию с Jira или другими подобными инструментами. При установке релиза должна заводиться соответствующая задача в Jira;
• добавить возможность сохранения общего состояния всего комплекса программ в документ (например, Excel), чтобы стейкхолдеры, релизные менеджеры или любой другой член команды мог видеть целостное состояние системы.