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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Работа с инструментами непрерывной интеграции (Jenkins)
• Работа с инструментами планирования, управления проектами (Jira, Trello, MS Project)
• Работа с системой контроля версий Git
• Планирование релизов, заведение расписания релизов
• Работа с корпоративными мессенджерами (Slack, Skypeforbusiness)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 1

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

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

Таблица 2

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

Таблица 3

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