1

Ільящук С.С., Файтас О.І. (керівник). Розроблення системи управління IT-

проектами з інтеграцією контролю версій в архітектурі мікрофронтендів.
Бакалаврська кваліфікаційна робота. - Національний університет “Львівська
політехніка”, Львів, 2021.
Розширена анотація.
Обсяги сучасних IT-проектів вимагають застосування методів і засобів
проектного управління під час розробки, серед яких - використання
інформаційних систем проектного менеджменту (ІСПМ). Сучасні ІСПМ є
складними багатофункціональними системами, реалізація яких вимагає
швидкого й адаптивного процесу розробки, значних масштабів команди та
можливості інтеграцій сторонніх сервісів.
Для онлайн застосунків цих вимог дозволяє досягти новітній підхід до
веб-архітектури - мікрофронтенди. Він передбачає розподіл
користувальницького інтерфейсу програми на ізольовані й самостійні
вертикальні секції, розробкою яких займаються окремі команди.
Об’єкт дослідження - мікрофронтенди.
Предмет дослідження - переваги і специфіка застосування архітектури
мікрофронтендів у розробці систем управління IT-проектами.
Мета дослідження: розробити прототип ІСПМ у архітектурі
мікрофронтендів та імплементувати інтеграцію системи контролю версій як
мікрофронтенд, аби продемонструвати специфіку й переваги підходу.
В роботі було проаналізовано архітектуру й її особливості, спроектовано
та розроблено прототип ІСПМ у вигляді окремих мікрофронтендів з
індивідуальними кодовими базами, кожна з яких застосовує власний
технологічний. Кожен мікрофронтенд є самостійною програмою. Розроблено
стандартизований метод їхньої інтеграції на одній сторінці. Налаштовано
незалежне розгортання частин програми. Результати роботи демонструють
переваги мікрофронтендів в розробці ІСПМ.
Ключові слова: МІКРОФРОНТЕНДИ, ВЕБ АРХІТЕКТУРА, ВЕБ-
ЗАСТОСУНОК, УПРАВЛІННЯ ПРОЕКТАМИ, ІСПМ, ІНТЕГРАЦІЯ.
 2

Перелік використаних літературних джерел.

1. Project Management Institute. A guide to the project management body of
knowledge (PMBOK guide) / Project Management Institute. – [S. l. : s. n.], 2017. –
756 p.
2. Li, Patrick. 2019. Jira 8 Essentials - Fifth Edition. Birmingham, England: Packt
Publishing. -- 420 p.
3. Rubin K. S. Essential Scrum: A practical guide to the most popular agile process /
Kenneth S. Rubin. – Upper Saddle River, NJ : Addison-Wesley, 2012.
4. Geers M. Micro Frontends in Action / Michael Geers. – [S. l.] : Manning
Publications, 2020. – 296 p.
 3

Iliashchuk S.S., Faitas O.I. (supervisor). Development of IT project

management system with version control integration in microfrontend architecture.
Bachelor's thesis. - Lviv Polytechnic National University, Lviv, 2021.
Extended annotation.
Modern IT projects have scope that requires the use of project management
tools and techniques. One such tool is a Project Management Information System or
PMIS. Modern PMIS are complex systems with rich functionality and creating them
requires quick and adaptive development flow, large teams and the possibility to
integrate external services.
For online applications, the modern architectural approach of microfrontends is
one way to achieve these requirements. This approach means dividing the program’s
user interface into isolated and autonomous vertical slices that are developed by
separate teams.
Study object - microfrontends.
Scope of research - benefits and specifics of applying microfrontend
architecture in development of project management systems.
Goal of research: to develop a PMIS prototype in microfrontend architecture
and implement version control integration as microfrontend to demonstrate specifics
and benefits of such approach.
In this research microfrontend architecture was analysed, PMIS prototype was
designed and developed as microfrontends with individual codebases each using it’s
own technological stack. Standardised method of microfrontend integration into the
page was developed. Independent deployment of microfrontends was set up. Results
of this work demonstrate the advantages of implementing PMIS in microfrontends.
Keywords: MICROFRONTENDS, WEB ARCHITECTURE, WEB
APPLICATION, PROJECT MANAGEMENT, PMIS, INTEGRATION.
References.
1. Project Management Institute. A guide to the project management body of
knowledge (PMBOK guide) / Project Management Institute. – [S. l. : s. n.], 2017. –
756 p.
 4

2. Li, Patrick. 2019. Jira 8 Essentials - Fifth Edition. Birmingham, England: Packt
Publishing. -- 420 p.
3. Rubin K. S. Essential Scrum: A practical guide to the most popular agile process /
Kenneth S. Rubin. – Upper Saddle River, NJ : Addison-Wesley, 2012.
4. Geers M. Micro Frontends in Action / Michael Geers. – [S. l.] : Manning
Publications, 2020. – 296 p.
 5

ЗМІСТ

ЗМІСТ 5

ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, ОДИНИЦЬ, СКОРОЧЕНЬ І ТЕРМІНІВ 7

ВСТУП 9

1. АНАЛІЗ ПЕРЕВАГ ТА СПЕЦИФІКИ ЗАСТОСУВАННЯ АРХІТЕКТУРИ

МІКРОФРОНТЕНДІВ 14
1.1. Визначення “мікрофронтенд” та суміжні поняття. 14
1.1.1. Визначні риси мікрофронтендів. 15
1.1.2. Історія використання мікрофронтендів. 16
1.2. Переваги й недоліки архітектури. 17
1.3. Специфіка імплементації. 20
1.3.1. Інтеграція та композиція підзастосунків. 20
1.3.2. Комунікація між підзастосунками. 22
1.4. Висновки до розділу 1. 23

2. ПРОЕКТУВАННЯ ВЛАСНОГО РІШЕННЯ В АРХІТЕКТУРІ МІКРОФРОНТЕНДІВ. 25

2.1. Цілі рішення. 25
2.2. Вимоги до можливостей користувача. 26
2.3. Огляд складових частин програми. 29
2.4. Моделі даних. 30
2.5. Головні потоки даних та активності. 31
2.6. Висновки до розділу 2. 33

3. РЕАЛІЗАЦІЯ ПРОГРАМИ. 34
3.1. Вибір допоміжних програмних засобів. 34
3.2. Серверна частина. 35
3.2.1. Застосунок-сервер. 35
3.2.2. База даних. 36
3.3. Мікрофронтенди. 37
3.3.1. Система управління завданнями. 37
3.3.2. Графік системи контролю версій Git. 39
3.3.3. Графік продуктивності команди. 39
3.4. Інтеграція та композиція підзастосунків. 40
3.4.1. Програма-контейнер, завантаження ресурсів підзастосунків. 40
3.4.2. Комунікація між мікрофронтендами. 43
3.4.3. Аутентифікація. 44
3.5. Налагодження незалежного розгортання. 45
3.6. Висновки до розділу 3. 46

4. ЕКОНОМІЧНА ЧАСТИНА 47
4.1 Економічна характеристика проектного рішення (програмного продукту) 47
4.2 Інформаційне забезпечення та формування гіпотези щодо потреби розроблення товару 47
4.3 Оцінювання та аналізування факторів зовнішнього та внутрішнього середовищ 49
 6
4.4 Формування стратегічних альтернатив 50
4.5 Бюджетування 53
4.6 Остаточний вибір стратегії 57

ВИСНОВКИ 58

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 60

ДОДАТОК А 62
А.1. Модель “сутність-зв’язок” реалізованої бази даних. 62
А.2. Діаграма потоку даних проектних параметрів. 63
А.3. Діаграма активності верифікації проектного репозиторію. 64

Додаток Б 65
Б.1. Директиви композиції серверу й бази даних для docker-compose. 65
Б.2. Маршрутизатор підзастосунку “Канбан” 66
 7

ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, ОДИНИЦЬ,

СКОРОЧЕНЬ І ТЕРМІНІВ
Веб-застосунок – розподілений вебсайт, із клієнтською та серверною
частиною, в якому клієнтом виступає браузерна програма, що опрацьовує
логіку інтерфейсу та користувальницьку активність, а сервером – веб-сервер,
який опрацьовує роботу з даними та ресурсомісткі операції.
Фронтенд (англ. front end) - клієнтська частина веб-застосунку.
Бекенд (англ. back end) - серверна частина веб-застосунку.
Мікрофронтенди - архітектурний підхід до розроблення веб-застосунків, за
якого клієнтська або клієнтська та серверна частини програми розробляються
як кілька окремих застосунків, пов’язаних між собою.
Мікрофронтенд – елемент архітектури мікрофронтендів, окремий застосунок,
із яких складається програма.
ІСПМ - інформаційні системи проектного менеджменту, також - системи
управління проектами.
Agile - клас методологій розробки програмного забезпечення, що базується на
ітеративній розробці, в якій вимоги та розв'язки еволюціонують через
співпрацю між багатофункціональними командами здатними до
самоорганізації.
Scrum - один із підходів Agile розробки.
Канбан (англ. Kanban) - метод управління розробкою програмного
забезпечення, популярний у Agile методологіях.
Канбан дошка - пов’язаний із Канбаном інструмент, що складається із набору
стовпців які позначають поточний стан виконання завдання і містять картки з
короткою інформацією про завдання.
Веб-фреймвокр (англ. Web Framework) - каркас із систематизованих
програмних рішень, що використовується у розробці веб-застосунків.
URL (також Уніфікований Локатор Ресурсів) - стандартизована адреса
певного ресурсу в інтернеті.
 8

Браузерна подія - браузерний інструмент реактивного програмування, що

дозволяє створювати програмні слухачі, які реагуватимуть на певну подію,
виконану деінде в межах веб-сторінки.
DOM (Об’єктна Модель Документу, англ. Document Object Model) -
програмна репрезентація елементів, присутніх на веб-сторінці.
Розгортання програмного забезпечення - набір операцій, що роблять певну
версію ПЗ готовою до експлуатації.
Docker – набір програмних продуктів, що націлені на оптимізацію
використання ресурсів операційної системи таким чином, аби забезпечити
функціонування програмного забезпечення в ізольованій та повторюваній
манері за допомогою так званих контейнерів.
JSON (JavaScript Object Notation) – відкритий стандарт передачі даних, що
передає інформацію у вигляді атрибутів та їх значень.
Ендпоінт (англ. endpoint) - вузол інтерфейсу мережевої комунікації між
клієнтом та сервером.
Git - розподілена система контролю версій файлів та спільної роботи.
Глобальні об’єкти - елементи, що доступні в будь-де в програмі.
Глобальний об’єкт window - у розробці веб, глобальний об’єкт, що
репрезентує вікно браузера.
 9

ВСТУП
За визначенням Інституту Проектного Менеджменту, управління
проектами - це застосування знань, навичок, інструментів та методів проектної
діяльності, аби виконати вимоги певного проекту [1, p.36]. Один з таких
інструментів - системи управління проектами (що також мають назву
“інформаційні системи проектного менеджменту” або ІСПМ) - програмне
забезпечення для планування, зберігання та поширення проектної інформації,
звітності, конфігурації тощо. Такі системи також можуть реалізовувати
автоматизований збір інформації та звітність про основні індикатори
продуктивності [1, p.98]. Кількість інформації, що обробляється в межах
розробки сучасних IT-проектів, робить неминучою використання таких систем
[1, p.82].
Завдяки швидкості, ефективності, економічності й точності хмарних
сервісів, дуже популярні онлайн ІСПМ [2]. Вони дозволяють зберігати значні
об’єми даних, що завжди будуть актуальними й максимально доступними для
всіх користувачів. Окрім того, завдяки популярності в сучасному проектному
управлінні підходу Agile, який використовують 71% опитаних в дев’ятому
глобальному опитуванні проектного менеджменту компаній [3, p.6], значна
частка цих систем імплементує інструменти саме для цієї парадигми. Саме таку
підмножину ІСПМ - онлайн системи для управління Agile проектами - буде
розглянуто в ході цієї роботи.
Ринок ІСПМ дуже насичений: technologyadvice.com надає 563 результати
на запит “project management” [4]. Тим не менш, більшість із існуючих рішень
мають дуже незначні користувальницькі бази і декілька з них є явними
фаворитами для користувачів.
За кількістю відгуків на technologyadvice.com [4] найпопулярнішими з
онлайн ІСПМ для Agile проектів є: Trello, Asana та Atlassian JIRA. Всі вони
імплементують канбан дошку, сховища проектних даних, відстеження завдань,
інструменти для планування тощо.
 10

Їхні відмінності, що дозволяють усім трьом рішенням бути у широкому

вжитку і конкурентоспроможними на насиченому ринку, найбільш явні в
пріоритетах дизайну цих систем.
JIRA має найглибшу й найдетальнішу імплементацію Agile концепції:
можливість конфігурації проектних процесів, тісні зв’язки між сутностями й
чіткі правила щодо управління ними. Важливою перевагою є також сервісний
застосунок, де користувачі можуть залишати звіти про помилки програмного
забезпечення, що перебуває в експлуатації. Trello, навпаки, є найбільш вільною,
гнучкою та модульною системою, з можливістю численних інтеграцій. Цю
ІСПМ використовують не лише для Agile проектів і навіть не лише для IT-
проектів, а низький поріг входу робить його оптимальним для маломасштабних
або дебютних робіт. Asana володіє найкращими можливостями візуалізації
даних, репортингу та інструментами командної взаємодії.
Усі три системи імплементують інтеграцію із системою контролю версій
Git: Trello й JIRA мають власний сервіс для цього, Asana дозволяє
синхронізувати дані із Git з допомогою сервісу Unito.
Як і проекти, для проектування яких вони застосовуються, сучасні ІСПМ
є складними багатофункціональними системами. Jira 8 Essentials [5, p.9]
визначає 8 чітко окреслених сервісів, з якими взаємодіє користувач. Розробка
таких систем є тривалим і складним процесом. Аби нове ІСПМ рішення не
втратило актуальність на ринку за час розробки, необхідно значне
масштабування команди й гнучкість, що дозволить адаптуватись до нових
потреб користувачів.
Розширення команди - складний і ризикований процесс, оскільки віддача
від кожного нового розробника, що працює над певною ділянкою програмного
забезпечення, зменшується. Через це команда розробки в сучасних підходах до
Agile є обмеженою: у Scrum, наприклад, одному з найпопулярніших Agile
фреймоврків, це обмеження складає від п’яти до дев’яти людей [6, p.16]. Тому
масштабування означає створення нових команд, що виконуватимуть різні
 11

завдання - зі спільного чи розділених беклогів (backlog), себто наборів завдань

до виконання.
Посібник Essential Scrum [6, p.213] розрізняє два види команд:
функціональні та компонентні. Функціональна команда - це команда з усіма
необхідними компетенціями, аби самостійно імплементувати нову функцію з
беклогу проекту. Компонентна команда, з іншого боку, фокусується на
розробці певного компонента або підсистеми та може імплементувати лише
частину нової функції для проекту. Для прикладу, функціональна команда
може реалізувати корзину в інтернет магазини від дизайну й до експлуатаційної
готовності, в той час як компонентна реалізує лише серверну частину корзини й
покладатиметься на іншу компонентну команду, з компетенцією у веб-
розробці, наприклад, для реалізації решти функціональності.
Зазвичай, IT-компанії формують компонентні команди, оскільки
переконані, що спеціалізація на певному технологічному стеку та технічній
підсистемі проекту підвищує якість та когерентность коду. Тим не менш, Scrum
надає перевагу функціональним командам, оскільки вони значно ефективніше
організовуються в часі й мають менше міжкомандних залежностей [6, p. 214-
217].
Проте жертвувати спеціалізацією команд не обов’язково. Окрім
горизонтального розподілу за технологічними компетенціями та підсистемами,
команди можна розділяти вертикально, за функціональними й доменними
елементами продукту. Такі команди залишатимуться функціональними і
здатними на наскрізну розробку певної функції програмного забезпечення,
проте імплементуватимуть лише певну секцію продукту. Наприклад, під час
реалізації проекту інтернет-магазину одна така команда відповідатиме за
каталог товарів, а інша - за корзину, оформлення замовлення й оплату.
Іншою важливою якістю для розробки проекту конкурентоспроможної
ІСПМ є закладена гнучкість. До прикладу, Trello в своїх перших релізах
надавав лише базову канбан дошку, але за відгуками користувачів було додано
інструменти автоматизації, а пізніше - числені інтеграції популярних сервісів.
 12

Це відповідає цілям Agile проектів: пристосовуватися до вимог замовника або

потреб кінцевого користувача під час розробки, навіть якщо це означає зміну
запланованого.
Але сучасні веб-застосунки є складними ансамблями модульних
підпрограм, що називаються пакунками. Залежність на пакунки дозволяє
значно скоротити необхідність написання типових рішень завдяки
використанню існуючих. Деякі пакунки, що називаються веб-фреймворками,
також надають особливе бачення й директиви щодо написання програмного
забезпечення, правила, які допомагають зберігати код систематизованим і
ефективним. На жаль, використання такого фреймворку за своєю суттю
обмежує потенційну гнучкість розробки: вимогливий каркас правил, що вони
надають, сумісний не з усіма архітектурними рішеннями, ефективними для
проекту, а багато пакунків-бібліотек є фреймворк-специфічними, що обмежує
бібліотеки доступних рішень. Міграція між фреймворками у випадку потреби є
кропітким та ресурсомістким процесом і може потребувати років [7].
Існує кілька технологій, що пропонують розділення команд за
вертикальними секціями продукту й гнучкість технологічного стеку. Федерація
модулів від пакувальника Webpack дозволяє створювати окремі збірки частин
проекту, що використовуються як незалежні пакунки. Інструменти
монорепозиторіїв, на зразок Lerna, дозволяють розділяти репозиторій
програмного забезпечення на підсистеми або об’єднувати існуючі репозиторії в
одну екосистему. Концептуально, усі схожі рішення прагнуть до спільної цілі:
реалізація вебсайту або веб-застосунку як композиції незалежних програм,
котрі можуть розробляти окремі команди. Такий підхід узагальнено називається
архітектурою мікрофронтендів.
В межах даної роботи розроблено прототип системи управління IT-
проектами в цій архітектурі з метою дослідити й продемонструвати, яким
чином вона дозволяє досягти технологічної гнучкості й можливості розробки
незалежними командами та чи пропонує інші переваги. Створене програмне
рішення, отримало назву Agitile - анаграма з літер слів Git та Agile.
 13

Ідея розподіленого програмного забезпечення у веб не є новою, але не

використовується поширено, і здобула активне зацікавлення й обговорення в
мережі лише в останні кілька років. Саме тому в розробці Agitile не
застосовуються існуючі інструменти для роботи з мікрофронтендами: важливо
відобразити специфіку деталей імплементації на рівні взаємодії частин
програми між собою та зі стандартними браузерними функціями, а не з
надбудованою системою, що приховує реалізацію. Окрім того, мікрофронтенд
фреймворки, такі як Single SPA, Bit та Piral наразі надають обмежені
можливості інтеграції підзастосунків, що базуються на конкретному
технічному підході, або ж нав’язують певні вимоги до природи програмного
забезпечення, що суперечить цілі технологічної гнучкості.
Розроблене програмне забезпечення, Agitile, не є і не має цілі бути
конкурентноспроможним продуктом. Це прототип або ж “proof of concept”, що
імплементує основні елементи й функції ІСПМ в архітектурі мікрофронтендів з
можливістю подальшого масштабування. Для відповідності моделі об’єкту
дослідження, визначено дизайн-концепцію: Agitile є ІСПМ для розробників
програмного забезпечення. Він не потребує участі менеджерського персоналу
для управління та навіть знеохочує її. Важливим елементом для визначеної
цільової аудиторії є інтеграція системи контролю версій, імплементація якої
також виконує роль дослідження можливості інтеграцій сторонніх сервісів як
незалежних підсистем програми та специфіку цього підходу.
 14

1. АНАЛІЗ ПЕРЕВАГ ТА СПЕЦИФІКИ ЗАСТОСУВАННЯ

АРХІТЕКТУРИ МІКРОФРОНТЕНДІВ
Мікрофронтенди не є чітко задокументованим технологічним підходом,
це множина організаційних, технологічних та архітектурних методів, засобів та
практик що використовуються для вертикальної декомпозиції розробки
програмного забезпечення у Web [8, p.4]. Таким чином, описані в даному
розділі характеристики є не необхідними для архітектури, а описовими щодо її
типової імплементації.

1.1. Визначення “мікрофронтенд” та суміжні поняття.

За пошуком “microfrontends” у пошуковику Google типовим написанням є

“micro frontends”, себто окремо з префіксом мікро-. Тим не менш, за правилами
українського [9, с.34] та англійського правопису слова з цим префіксом
пишемо разом. Окрім того, визначення “microservice”, що є схожим за
значенням і вважається походженням “microfrontend”, також зазвичай
вживається у написанні разом. Тому в цій роботі використовується лише
написання разом - “microfrontend” та “мікрофронтенд”.
Фронтенд (front end) - це клієнтська, браузерна частина програми, що
надає читабельний та зручний користувачеві інтерфейс, на відміну від бекенду
(back end) - програмно-апаратної частини, що не доступна користувачеві
безпосередньо, опрацьовує дані та виконується на сервері. Префікс “мікро-”
призначений символізувати, що сутність є частиною цілого. Мікрофронтендом,
таким чином, називають частину клієнтської програми вебсайту або веб-
застосунку, що водночас є окремою програмою.
Синонімічним визначенням в роботі є “підзастосунок”, себто підлегла
прикладна програма. Коли йдеться про мікрофронтенд як окрему програму,
вживається також вживається словосполучення “застосунок” з назвою по імені.
Застосунок, який інтегрує окремі мікрофронтенди й відображає їх на сторінці,
прийнято називати “програмою-контейнером”.
 15

1.1.1. Визначні риси мікрофронтендів.

Згідно маніфесту Майкла Гірса із neuland Büro für Informatik [10], ідея
мікрофронтендів полягає в тому, аби розглядати веб-сайт чи веб-застосунок як
комбінацію функцій, що належать незалежним командам. Кожна команда
відповідає за окрему сферу бізнесу або місію та спеціалізується на ній. Команди
є кроссфункціональними та імплементують свої функції наскрізно, від
проектування до інтерфейсу користувача, бажано включно із необхідною
серверною частиною [8, p.7]. Схильність до наскрізної імплементації
зумовлена походженням мікрофронтендів від мікросервісів (“microservices”) -
аналогічного підходу, що передбачає вертикальну декомпозицію програми, на
бекенді [18].
Цей підхід набув широкого розголосу у 2017-ому році, а перші
комерційні рішення, що його застосовують, з’явились у 2012-ому. Станом на
зараз (червень, 2021) лише 3 книги на цю тему зареєстровано в ISBN, одна яких
очікує видання цього року, а решта були видані протягом останніх двох. Отже,
мікрофронтенди - це сучасне архітектурне рішення, що активно розвивається.
Більш детально, Майкл Гірс, ідеолог цієї архітектури, визначає наступні
прагнення, що дозволяють імплементувати ефективне рішення у
мікрофронтендах:
● Технологічний агностицизм
Кожна команда повинна мати можливість вибирати та проводити
розробку, використовуючи власний стек без необхідності узгодження з
іншими командами. Деталі реалізації мікрофронтенду повинні бути
прихованими за абстрактним інтерфейсом. [10]
● Ізольований код та контекст виконання
Підпрограми не повинні мати спільних елементів або взаємозалежностей
в процесі виконання. Їх належить реалізовувати як повноцінні й
самостійні застосунки. Не варто покладатися на глобальні змінні або
спільний програмний контекст [10]. Це також вважається
 16

рекомендованою практикою в мікросервісах, де окремі серверні програми

не повинні залежати від спільних баз даних [8, p.141].
● Командні іменування
Якщо ізоляція неможлива, необхідно погодити правила іменування для
уникнення конфліктів. Простір імен CSS, браузерні події, локальне
сховище та файли cookie варто префіксувати, щоб уникнути зіткнень та
визначити приналежність. [8, 45-47]
● Пріоритет браузерних функцій понад специфічними інтерфейсами
Власні браузерні події підходять для спілкування, ніж глобальна система
Публікація-підписка. Якщо специфічного інтерфейсу комунікації між
підпрограмами не уникнути, його належить максимально спростити. [10]
● Стійкі веб-сторінки
Кожен мікрофронтенд повинен бути корисним, навіть якщо виникла
помилка при виконанні або виконання ще не завершено. Сприйняття
користувача має бути в пріоритеті. [10]
Жоден із цих пунктів не є обов’язковим, але такі характеристики
природним чином виникають при розробці веб-застосунків в архітектурі
розподілених мікрофронтендів та вважаються рекомендованими практиками.
Вони також не є абсолютними, оскільки хоча б мінімального зв’язку між
кодовими базами та технологічних залежностей неможливо уникнути, і не
завжди таке прагнення є продуктивним. Наприклад, спільна бібліотека для
опрацювання дат може бути винятково корисною спільною залежністю,
оскільки дозволить командам уникнути додатково форматування при обміні
датами між підзастосунками. Спільна бібліотека компонентів інтерфейсу
користувача навіть рекомендована для консистентності [8, p.214-215].

1.1.2. Історія використання мікрофронтендів.

Як вже було зазначено, ідея розподілу фронтенд моноліту на незалежні

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

кілька співробітників повідомили, головний їхній флагманський проект,

однойменний сайт електронної комерції, застосовує такий підхід вже багато
років. Існують також чутки, що Amazon використовує технологію динамічної
інтеграції інтерфейсу користувача, яка збирає різні частини сторінки до того, як
потрапить на сторінку браузеру [8, p.21].
Мікрофронтенди загалом досить популярні серед флагманів у секторі
електронної комерції. Стаття 2015-ого року від Otto Group, німецької
платформи поштової торгівлі, що є однією з найбільших в світі, описує
архітектурний підхід для розбиття моноліту фронтенду, який застосовується у
продукті компанії з 2012-ого року. Шведська меблева компанія IKEA [11], один
з найбільших роздрібних інтернет-ринків Zalando [12], німецька мережа
книжкових магазинів Thalia [13] та спортивний стрімінг-сервіс DAZN [14]
також перейшли на цю модель. Застосунок музичного сервісу Spotify,
написаний з допомогою веб-технології Electron, інтегрує кілька підзастосунків з
допомогою <iframe> [19]. Фреймворк мікрофронтендів Single SPA зазначає
двадцять комерційних проектів в експлуатації [15], які імплементують з його
допомогою архітектуру розподіленого веб-застосунку.

1.2. Переваги й недоліки архітектури.

Окрім технологічної гнучкості та можливості роботи незалежними

командами, можна виділити наступні найяскравіші переваги, що можуть надати
проекту мікрофронтенди:
● Інкрементальні й незалежні оновлення
Оскільки кожна підпрограма виконується окремо, вплив оновлень
обмежений, що дає більше свободи команді для введення частіших та
гранулярніших змін. Рефакторинг коду, оновлення застарілого
технологічного стеку, зміна певної ділянки бізнес-логіки - все це значно
простіше й безпечніше реалізовувати в ізольованому мікрофронтенді, ніж
у монолітному веб-застосунку [20].
● Прості, розподілені кодові бази
 18

Вихідний код для кожного окремого мікро інтерфейсу за визначенням

буде значно меншим, ніж вихідний код одного монолітного застосунку.
Ці менші кодові бази, як правило, більш прості та зрозумілі для
розробників. Зокрема, вони дозволяють уникнути складностей, що
виникають через ненавмисний та неналежний зв’язок між компонентами,
які не повинні знати один про одного. Проводячи товстіші лінії навколо
обмеженого контексту підпрограм, ця архітектура запобігає появі таких
випадкових зв’язків [20].
● Незалежне розгортання
Як і у випадку з мікросервісами, ключовою перевагою є незалежне
розгортання мікрофронтендів. Кожне окреме розгортання
мікрофронтенду має значно менший обсяг і вплив, що, в свою чергу,
зменшує пов'язаний із ним ризик. Незалежно від того, як і де розміщений
ваш код, кожна підпрограма може може власний конвеєр безперервної
доставки, який будує, тестує та розгортає її аж до виробничого
середовища. Кожен мікрофронтенд також має можливість бути
розгорнутим без зайвого впливу на контекст інших, оскільки вони
опираються на різні сховища даних [21].
● Автономні й спеціалізовані команди
Основні переваги мікрофронтендів - організаційні [8, p.237], оскільки цей
підхід змінює культуру й соціальну природу команд. Команди не лише
функціональні й незалежні одна від одної, вони володіють усіма
необхідними знаннями й засобами для наскрізною розробки та
спеціалізацією в певній доменній секції продукту та швидкого прийняття
рішень. Ці команди мають краще продуктове розуміння своєї частини
системи, згуртованіші та володіють більшою часткою релевантної
інформації, ніж групи розробників сформованих довкола горизонтальних,
технічних кордонів: бекенд, фронтенд, стилювання, форми, валідація
тощо [20].
 19

Мікрофронтенди також мають кілька явних і значних недоліків, тому не є

універсальним рішенням для кожного продукту. Важливо виокремити наступні:
● Неоднорідність
Перш за все, варто розуміти, що гнучкість технологічного стеку повинна
бути обгрунтованою. Чим більше пакунків використовує проект, тим
більше доводиться спостерігати за їхніми версіями і проводити міграції,
аби уникнути можливих хиб, пов’язаних із ломними змінами [8, p.18].
Окрім того, підтримувати кілька різнопрофільних команд може виявитись
додатковою складністю для управління людськими ресурсами, оскільки
зазвичай веб-розробники пріоретизують один фреймворк, і для кожного
великого фреймворку є свій ринок праці та внутрішній резерв.
● Неконсистентність даних
Хоча за своєю суттю вони передбачаються як незалежні програми,
скомпоновані разом мікрофронтенди часто мають необхідність
обмінюватись даними між собою. В той час як моноліт зазвичай надає
прямолінійний доступ до даних в будь-якій частині застосунку,
синхронізація між мікрофронтендами вимагає додаткових операцій.
Якщо це не лише програмний стан, але й міжсесійні дані, це означає
додаткові запити між клієнтом і сервером та записи до СУБД. Залежно
від можливої мережевої затримки дані підзастосунків можуть різнитися
протягом сотень мілісекунд або навіть кількох секунд [8, p.18].
● Надмірність та повторення коду
Команди, що працюють без залежності на спільну кодову базу, неминуче
створюють багато повтореного коду. Базові CSS стилі за спільним
стайлгайдом, утиліти й бойлерплейт - найочевидніші елементи для
повторення. Крім того, кожна з команд змушена самостійно наладнати
процеси збірки та розгортання. У випадку хиби в популярній бібліотеці
або спільній логіці, виправлення доведеться імплементувати у всіх
застосунках окремо, як і будь-які інші зміни [8. p.17-18]. Якщо команди
опираються на спільні пакунки, в деяких випадках це означає
 20

необхідність додаткової оптимізації пакувальника, в інших - повторні

залежності неминучі і така архітектура тягне за собою більші розміри
остаточних збірок та час завантаження сторінки .
Таким чином, мікрофронтенди не є універсальним рішенням і можуть не
пасувати певним проектам. Перш за все, це спосіб масштабування, тому для
невеликих проектів, що мають одну команду або кілька команд з добре
налагодженою комунікацією, таке рішення може бути надмірним. Окрім того,
чіткі вертикальні зрізи вимагають хорошого розуміння домену розробки, аби
уникнути конфліктів відповідальностей між командами. Оскільки браузер -
єдине середовище для виконання усіх підзастосунків, ломні зміни або хиби
однієї з команд можуть призвести до поломки всього проекту, тому важливою є
наявність кількох тестувальних та розробницьких середовищ для контролю та
поступової інтеграції змін. Врешті-решт, організаційна складність завжди
виникає, коли кілька суб’єктів працюють над одним процесом, і з
мікрофронтендами це особливо так.

1.3. Специфіка імплементації.

1.3.1. Інтеграція та композиція підзастосунків.

Головним кроком в створенні застосунку, що складається з кількох

частин, є їхнє сполучення й композиція в одну програму. Мікрофронтенди
мають численні методи інтеграції завдяки гнучкості веб-технологій загалом.
Оскільки багато з них специфічні до особливостей архітектури або ж є різними
імплементаціями однієї стратегії, нижче наведено список найпопулярніших або
визначних підходів:
● Серверна інтеграція
У випадку використання технологій серверного рендерингу,
застосовується низка методів: завантаження ресурсів через запити до
серверів-підзастосунків, маршрутизація на спільному сервері-шлюзі,
використання Server-Side Includes. Оскільки серверний рендеринг не
 21

використовується широко в сучасній розробці, ця робота не

зосереджуватиметься на таких методах.
● Інтеграція на етапі збірки
Кожен окремий підзастосунок публікується як пакунок, який контейнер
включає в список власних залежностей та під час збірки інтегрує код в
єдиний пакет. Проблема такого підходу в необхідності збірки усього
проекту при зміні будь-якої частини, що суперечить прагненню
ізольованого й незалежного оновлення та розгортання.
● Інтеграція на етапі виконання через iframe
<iframe> - HTML тег, що використовується для вставки одних веб-
документів у інші. Документи при цьому не зливаються в один, а радше є
ізольованими контекстами веб-переглядача, що пасує до прагнення
незалежності підзастосунків. Недоліки цьому підходу в тому, що він
ізолює мікрофронтенди, можливо, занадто сильно: спільна браузерна
історія, респонсивність сторінки та комунікація між застосунками
особливо складна при викорстанні iframe.
● Інтеграція на етапі виконання через Javascript
Кожен мікрофронтенд вставляється на сторінку за допомогою тегу
<script> і при завантаженні викриває свою точку входу як глобальну
функцію. Програма-контейнер визначає, який підзастосунок повинен
бути змонтований в DOM, і викликає відповідну функцію, надаючи будь-
який релевантний контекст через її параметри.
● Інтеграція у Web Components
Web Components - набір сучасних браузерних веб-технологій, що
дозволяють створювати й вільно використовувати користувацькі HTML
елементи, інкапсулювати їх в Тіньовому DOM та створювати шаблонний
HTML на клієнтській стороні застосунку. Це дуже потужні рішення, що
дозволяють надійно ізолювати підзастосунки, залишивши батьківському
застосунку-контейнеру контроль над ними, але його використання пасує
до системи зі значною кількістю невеликих підзастосунків, котрі
 22

імплементують обмежену логіку й не обов’язково є самостійними

програмами.

1.3.2. Комунікація між підзастосунками.

Як було зазначено вище, незважаючи на те що одним з основних

прагнень мікрофронтендів є ізольованість, необхідність обміну даними все ще
виникає в розробці єдиного продукту. Методів комунікації існує досить багато,
особливо якщо підзастосунки виконуються у спільному браузерному або
серверному контексті. Між програмою-контейнером та підзастосунком
зазвичай є прямий канал “parent-child” комунікації та навіть “child-parent”
завдяки функціям зворотного виклику. Деталі кожного підходу не є
релевантними для роботи, тому нижче описано три узагальнені групи
найпопулярніших стратегій:
● Публікація-підписка
Pub/Sub паттерн є доволі розповсюдженим способом комунікації в
програмному забезпеченні. У веб-застосунку, що складається з
мікрофронтендів, його можна реалізувати з допомогою сторонніх
бібліотек, таких як PubSubJS, браузерного API Трансляційного Каналу
(Broadcast Channel) або користувацьких браузерних подій. Перевага цього
методу в зручності, та гнучкості, оскільки Трансляційний канал та інші
реалізації патерну можна використовувати навіть між різними
браузерними контекстами, наприклад, для підзастосунку, інтегрованому
через <iframe>. Тим не менш, патерн підписки за своєю суттю означає
асинхронність програмного процесу, що може ускладнити забезпечення
консистентності даних.
● Спільний зовнішній контекст
Мікрофронтенди можуть не спілкуватися між собою чи з батьківською
програмою самостійно, а опиратися на спільно доступні сховища даних.
Такими можуть виступати: спільний бекенд, веб воркер (Web Worker,
браузерний API, що дозволяє виконувати скрипти у фоновому режимі),
 23

локальне та сесійне сховище (Local Storage і Session Storage), URL

сторінки й навіть глобальні змінні (за умови спільного браузерного
контексту). Такі методи дозволяють зробити мікрофронтенди
ізольованими й самостійними, але вимагають імплементації push-системи
для отримувача інформації, наприклад, через патерн опитування або
WebSocket. Простіші інтерфейси, такі як локальне сховище або URL,
також обмежені характером інформації, що можуть зберігати, оскільки
доступні користувачеві.
● Спільний програмний контекст
Якщо програма-контейнер має налагоджений зв’язок з
мікрофронтендами, які вона компонує на сторінці, це означає, що стан
усіх елементів системи може бути пов’язаний між собою. Інструменти
для управління програмним станом, такі як бібліотека Redux, дозволяють
налаштувати спільний програмний контекст для всіх підзастосунків, що
знаходяться в одному браузерному контексті, синхронно та
контрольовано. Такий підхід, тим не менш, дуже тісно сполучає
мікрофронтенди один з одним, передбачає дуже низьку самостійність та
ізоляцію, залежність на спільні інструменти управління станом - а отже,
суперечить основним прагненням архітектури.
Усі ці методи мають свої переваги та недоліки, і, завдяки свободі й
гнучкості мікрофронтендів, кожен проект може імплементувати комунікацію
доречним та ефективним способом або ж навіть змішувати підходи до обміну
даними. Тим не менш, важливо розуміти, що ізоляція кодових баз та
програмної логіки - одна з визначних рис архітектури, від якої залежить багато
переваг, що вона здатна надати, тому будь-яке сполучення між окремими
частинами варто скрупулезно оцінювати перед реалізацією.

1.4. Висновки до розділу 1.

Для конкурентоспроможності на ринку сучасній ІСПМ необхідна

технологічна гнучкість процесу розробки, якої дозволяє досягти архітектура
 24

мікрофронтендів завдяки можливості розробки секцій продукту окремими

командами, роз’єднаним кодовим базам із незалежними технологічним стеком
та процесу часткового розгортання.
 25

2. ПРОЕКТУВАННЯ ВЛАСНОГО РІШЕННЯ В АРХІТЕКТУРІ

МІКРОФРОНТЕНДІВ.
Дизайн Agitile формується навколо ідеї ІСПМ для розробників
програмного забезпечення. Актуальність такий продукт матиме для малих та
середніх розробок, де немає необхідності в менеджерському управлінні ІСПМ,
для команд, для яких важлива ізоляція певної інформації інформації, навіть для
проектів в архітектурі мікрофронтендів, де кожна команда може вести власну
систему управління завданнями в їхній секції продукту, демонструючи
менеджерському складу, що спільний для всіх команд, лише ключові показники
прогресу й продуктивності.
Ізольованість підзастосунків дозволяє з легкістю імплементувати
розподіл прихованих та відкритих для різних груп даних. Немає необхідності в
налаштуванні системи доступів чи генерації звітів - кожну частину програми
можна продемонструвати як окремий, самостійний застосунок просто
поділившись посиланням.
Визначення цільової аудиторії як розробників також дозволяє чітко
описати й визначити фундаментальні сутності системи. Оскільки розробка ПО
відбувається переважно з використанням системи контролю версій Git [16], для
Agitile кожен проект вважатимемо визначеним певним Git-репозиторієм. Для
обмеження обсягу роботи до реалістичного, застосунок опрацьовує лише
репозиторії сервісу Github, який є найбільшим провайдером Git рішень на
ринку.

2.1. Цілі рішення.

Найважливіша перевага мікрофронтендів - це розподілені й незалежні

команди, що вдасться лише умовно продемонструвати в даній роботі, оскільки
проект реалізовано одним розробником. Дослідження впливу спеціалізації
окремої команди у певній секції продукту та власності над ізольованою
кодовою базою на продуктивність залишиться поза межами роботи.
 26

Цілями реалізації рішення в даній архітектурі є: демонстрація гнучкості

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

2.2. Вимоги до можливостей користувача.

Система управління IT-проектами перш за все повинна забезпечувати

відстеження виконання завдань у проекті. Зазвичай, в ІСПМ таких як JIRA
завдання описується квитком - набором необхідної для виконання та
відстежування інформації. В межах розробленої системи користувач повинен
мати можливість наступних операцій із завданнями:
● створення квитка на виконання завдання;
● редагування квитка;
● визначення типу завдання та виконавця;
● визначення складності завдання у Story Points;
● зміна статусу виконання квитка.
Квитки повинні мати читабельними для людини унікальні ідентифікатори
в межах одного проекту. Тип завдання визначає природу завдання та має три
можливих значення: “Story”, “Task” і “Bugfix”. Серед них “Task” і “Bugfix”
мають лише контекстуальне значення, в той час як “Story” дозволяє
користувачеві створювати “підзавдання” - складові частини роботи, яку
належить виконати, що не обов’язково означають реалізований функціонал
після виконання й не мають власних квитків, але можуть бути імплементовані в
 27

окремій гілці репозиторію, і тому мають власний проектний ідентифікатор

(детальніше про зв’язок між ідентифікаторами та репозиторієм у підрозділі
2.4.). Виконавець повинен бути користувачем, що існує в системі Github.
Квиток може набувати різних статусів виконання, з яких “Done” є фінальним
завдання і редагування або зміна статусу після набуття статусу “Done”
неможливі. Лише квитки одного проекту, повинні відображатися на сторінці
водночас.
Багато з цих та описаних нижче вимог можуть не відповідати
специфічним потребам певних проектів та бути недостатньо універсальними
для користувача. Це допустимо, оскільки системна конфігурація не є об’єктом
дослідження даної роботи. Архітектура мікрофронтендів, тим не менш, надає
можливість легкого розширення прототипу в майбутньому.
Ітеративна природа Agile передбачає розробку в межах визначених
часових періодів - ітерацій. У Scrum та інших системах ці ітерації називаються
спринтами, і в межах системи Agitile є набором завдань, що заплановано до
виконання в період між датами, вказаними користувачем. Зазвичай, спринти
мають визначену тривалість, але в межах реалізованої програми вона може
бути довільною. Користувач повинен мати можливість наступних операцій зі
спринтами:
● створення спринта, із визначенням дати початку й кінця, набору квитків
до виконання в його межах;
● редагування спринта зі змогою додати квитки;
● керування початком та закінченням спринта, незалежно від того, чи
збігаються дати.
Після створення спринт знаходиться у статусі “Planned”, початок
переводить його в статус “In progress”, а закінчення - у статус “Finished”. Після
початку спринта, набір квитків у ньому неможливо змінити. Після закінчення -
неможливо редагувати дати. Лише один спринт може знаходитися в процесі
виконання водночас - він також називається “активним”. Квитки не обов’язково
повинні належати лише одному спринту, оскільки передбачено, що їх
 28

виконання може не закінчитися в певному спринті і бути перенесеним у

наступний. Лише спринти одного проекту, повинні відображатися на сторінці
водночас.
Як зазначено в Розділі 2 передбачено, що цільовою аудиторією системи є
розробники ПЗ, тому сутність проекту є визначеною одним репозиторием
Github. Користувач повинен мати можливість обрати репозиторій, проект якого
бажає переглядати. Якщо проект, визначений цим репозиторієм, не існує в
системі на цей момент, користувач повинен мати можливість створити його.
Передбачена аутентифікація з допомогою Github.
Дані квитків, спринтів та проектів повинні зберігатися між
користувальницькими сесіями та бути доступними іншим користувачам.
Інтеграція системи контролю версій Git - одна з визначних особливостей
продукту. На відміну від інтеграцій в Trello та JIRA, Git є одним з
інформаційних джерел системи, а не лише синхронізує дані із нею. На сторінці
застосунку користувач повинен бачити історію комітів та гілок в репозиторії у
формі графіку. Система повинна автоматично оновлювати дані через певний
інтервал методом полінгу (регулярного опитування) даних.
Автоматизація відстежування виконання завдань є важливою частиною
багатьох систем управління IT-проектами. Можливість налаштування цієї
автоматизації виходить поза межі роботи, оскільки є надмірним для
демонстрації можливостей архітектури мікрофронтендів та інтеграції Git.
Присутня функція автоматизації є наступною: коли у репозиторії відбувається
зливання гілки із назвою, що містить ідентифікатор існуючого в системі квитка
на завдання, в головну гілку, відповідний квиток набуває статусу “Testing”. Цей
статус обрано, оскільки автоматизація не повинна здійснювати невідворотних
змін, і будь-який функціонал передбачає верифікацію перш ніж бути
затвердженим у статусі “Done”.
Важливим елементом Agile є постійний аналіз власної продуктивності.
Одним з найпоширеніших артефактів для цього є графік згорання задач,
“burndown chart”. Це лінійна діаграма, що відображає очікувану та дійсну
 29

динаміку залишку завдань у спринті. На сторінці застосунку користувач

повинен бачити графік згорання задач для спринта, що знаходиться в статусі
“In Progress” або “Finished”. Важливою є також можливість відобразити графік
окремо від решти застосунку, оскільки зацікавлені у продуктивності команди
суб’єкти можуть бути не лише розробниками, що мають ексклюзивний доступ
до інформації проекту. Це стосується менеджерів, власників продукту,
замовників тощо.

2.3. Огляд складових частин програми.

Agitile складається із п’яти складових частин, що описані нижче.

Мікрофронтенд системи відстежування завдань, що також умовно
називається застосунком “Канбан”, імплементує відстежування завдань та
спринтів певного проекту. Він, в свою чергу, складається з наступних
функціональних компонентів:
● список завдань, що може бути форматі таблиці або дошки Канбан у
випадку переглядання спринта зі статусом “In Progress”;
● контрольної панелі, що дозволяє обрати для відображення та редагувати
спринт, обрати активний спринт або відобразити всі задачі, що існують в
проекті - беклог;
● форм створення та редагування квитка та спринта.
Мікрофронтенд інтеграції системи контролю версій, що також умовно
називається застосунком “Git графік”, відображає графік комітів та гілок в
репозиторії проекту та імплементує періодичний полінг даних.
Мікрофронтенд із графіком згоряння задач, що також умовно називається
застосунком “Продуктивість”, відображає burndown chart для обраного спринта
та інформацію про загальну кількість та складність завдань у спринті, часові
межі спринта.
Програма-контейнер інтегрує описані мікрофронтенди в одну веб-
сторінку, адаптивно розташовує їх, опрацьовує можливі помилки завантаження,
 30

надає можливість аутентифікації через Github та вибір проекту з прив’язкою до

існуючого репозиторію.
Програма-сервер імплементує створення, редагування та отримання
даних про квитки завдань, спринти, продуктивність спринту і проекти та
збереження цих даних в СУБД.

2.4. Моделі даних.

Для реалізації сховища даних проекту обрано нереляційну базу даних

MongoDB, про що буде зазначено детальніше у підрозділі 3.1.. Це означає, що
дані знаходитимуться у колекціях документів, створених за моделлю із певною
схемою полів, між якими відсутні реляційні зв’язки, але можливе використання
вбудованих документів або посилань через поля-ключі.
Модель Проект (Project), документ якої створюється при ініціалізації
користувачем проекту певного репозиторію, зберігає дані, що
використовуються для генерації проектних ідентифікаторів: поля prefix та seq.
prefix - заданий користувачем проектний префікс, seq - приховане ціле значення
значення що автоматично інкрементують при генерації нового ідентифікатора.
Поля owner та repo використовуються для визначення пов’язаного репозиторію.
Модель даних Спринт (Sprint) містить наступні поля: name - назва
спринта, котру бачить користувач; status - перелік можливих статусів, серед
яких “Planned”, “In progress” та “Finished”; startDate і endDate - дати початку й
закінчення відповідно, що набувають значення поточної дати за
замовчуванням; tickets - масив системних ідентифікаторів Квитків, що належать
Спринту; owner і repo - поля для визначення репозиторію, проекту якого
належить Спринт.
Модель даних Квиток (Ticket), що імплементує дані, пов’язані із
завданням, містить наступні не порожні поля: status - перелік можливих
статусів, серед яких “To Do”, “In Progress”, “Testing” та “Done”; type - перелік
можливих типів завдань - “Task”, “Bugfix” та “Story”; ім’я - назва завдання,
котру бачить користувач; displayId - унікальний в межах проекту ідентифікатор,
 31

який бачить користувач; storyPoints - кількість Story Points, що визначають

складність завдання; owner і repo - поля для визначення репозиторію, проекту
якого належить Квиток. Окрім того є наступні опціональні поля: completedAt -
порожнє до того, як Квиток набуває статусу “Done”, після чого набуває
значення поточної дати; assignee - логін Github користувача, відповідального за
виконання; description: опис завдання; tickets - у випадку, якщо тип Квитка -
“Story”, масив вбудованих документів Підзавдання.
Документи квитків та спринтів знаходяться у єдиних колекціях, спільних
для всіх проектів. Для запитів даних, що належать до певного проекту,
використовуються поля owner та repo, що ідентифікують його.
Підзавдання (Subtask) не є моделлю, оскільки такий документ не може
бути самостійним і завжди є вбудованим до моделі Квиток, але схема, що його
визначає, містить наступні поля: name - відображена назва підзавдання;
displayId - відображений унікальний проектний ідентифікатор; isCompleted -
булеве значення, що позначає, чи виконане підзавдання.
Документи усіх моделей (окрім Підзавдання, яке є вбудованим
документом) також мають системний ідентифікатор _id.
Діаграма типу “сутність-зв'язок”, що наочно демонструє ці моделі та
зв’язок між ними, знаходиться в Додатку А.1.

2.5. Головні потоки даних та активності.

Особливою складністю реалізації застосунку в архітектурі

мікрофронтендів є комунікація між підзастосунками. Оскільки одна з головних
цілей, як було зазначено в розділі 1.3.2, - це максимальна незалежність та
роз’єднаність кодових баз та контексту виконання окремих застосунків, будь-
які зв’язки між ними бажано звести до мінімуму та реалізовувати стандартними
інструментами Web.
Найважливіший спільний контекст між підзастосунками Agile - це
проект, що користувач переглядає в певний моменти. Оскільки проект
визначений репозиторієм, параметри, що дозволяють його ідентифікувати - це
 32

власник (owner), користувач Github, та назва репозиторію (repo). Ці параметри

застосовуватимуться усіма елементами системи для отримання релевантної
інформації, як зазначено у попередньому підрозділі 2.4., тому важливо, аби
вони були доступні будь-де. Оптимальним інструментом для цього слугуватиме
адреса URL веб-сторінки, оскільки вона не лише доступна з будь-якої точки
програми, але й дозволить користувачам з легкістю обмінюватись посиланнями
на проекти та може виконувати роль керування станом програми (детальніше у
розділі 3.4.1.).
Вибір проекту було імплементовано в межах програми контейнеру,
оскільки ця логіка не повинна належати жодному з мікрофронтендів. Після
вибору або створення бажаного проекту, програма перенаправляє користувача
на URL шлях, що має схему [host]/:owner/:repo (двокрапкою позначені змінні, в
квадратних дужках - константа). Ці параметри використовуються застосунком
“Канбан” для запиту на отримання або створення документів, що належать для
обраного проекту, застосунком “Git графік” для запитів інформації про
репозиторій з Github API та застосунком “Продуктивність” для запитів
продуктивності спринтів обраного проекту. Детальніше про потік даних через
URL сторінки у Додатку А.2.
Важливим кроком є верифікація існування репозиторію, яким визначений
проект. Якщо користувач вибирає проект через програму-контейнер, котра
отримує інформацію про репозиторії з Github API, можливісті помилки немає,
але URL адреса відкрита для редагування користувачем, тому параметри в ній
можуть не визначати жодного репозиторію, а отже, валідного проекту.
Оскільки програма-контейнер не використовує проектні параметри URL і
лише встановлює їх, верифікація не є її відповідальністю. Було прийнято
рішення верифікувати репозиторій запитом до Github API в межах застосунку
“Канбан”, оскільки він виконує основні функції проекту. Якщо за URL
параметрами проекту не знайдено жодного репозиторію в Github API,
користувача перенаправлено на базовий шлях ([host]/), де він може обрати
існуючий проект. Якщо запит успішний, застосунок “Канбан” відправляє
 33

користувацьку браузерну подію, котрої дослухаються інші застосунки.

Детальніше про цей процес, відображений діаграмою активностей, у Додатку
А.3.

2.6. Висновки до розділу 2.

В межах цієї кваліфікаційної роботи розроблено прототип системи

управління IT-проектами, що демонструє переваги й специфіку підходу
мікрофронтендів у даному домені - застосунок Agitile. Він складається із трьох
незалежних підзастосунків, що цілковито самостійні й мають мінімальні
взаємні залежності та зв’язки. Їх завантажує та компонує на сторінці програма-
контейнер, що також імплементує частину інтеграції із сервісом контролю
версій Github - аутентифікацію користувача. Серверна частина, оскільки не
потребує розділення й не є предметом дослідження роботи, розроблена як
моноліт.
Кожен мікрофронтенд виконано у різній комбінації мови програмування
та використання фреймворків і бібліотек, аби продемонструвати гнучкість
технологічного стеку.
Цільовою аудиторію розробленого прототипу обрано розробників ПЗ.
Окремі мікрофронтенди, наприклад, підзастосунок із графіком продуктивності
команди, можна відтворювати незалежно від інших, що дозволяє приховувати й
ізольовувати інформацію від різних груп користувачів. Такий підхід
демонструє притаманну архітектурі модульність.
Для необхідної комунікації між мікрофронтендами використано лише
вбудовані браузерні інструменти, як-от: URL адреса сторінки та користувацькі
браузерні події. Таке рішення демонстру специфіку мінімізації спільних
залежностей між підзастосунками, якої вимагає архітектура.
 34

3. РЕАЛІЗАЦІЯ ПРОГРАМИ.

3.1. Вибір допоміжних програмних засобів.

Як зазначено у підрозділі 1.2, однією з визначних переваг

мікрофронтендів є повна незалежність технологічного стеку кожної команди,
що реалізує окремий підзастосунок. Єдиним обмеженням є здатність браузера
відобразити програму на веб-сторінці. Таким чином, доступна реалізація з
будь-яким стандартом JavaScript, TypeScript, будь-яким фреймворком (для
рендеру, CSS, стейт-менеджменту тощо), різними технологіями на зразок
серверного рендерингу - і кожен окремий підзастосунок може застосовувати
бажану й доречну їхню комбінацію.
Задля демонстрації цієї можливості та дослідження інтеграції
мікрофронтендів за різних умов, в межах роботи кожен застосунок було
виконано в іншій комбінації фундаментальних частин стеку: система
менеджменту - React і TypeScript, графік системи контролю версій - Javascript,
графік продуктивності команди - TypeScript, контейнер - React і JavaScript.
Кожна кодова база, таким чином, відрізняється в процесі збірки та компіляції.
Вибір був змотивований наступними чинниками: система менеджменту й
програма-контейнер мають багато логіки рендеру й маршрутизації, з чим дуже
допомагає React. Система менеджменту також опрацьовує дані різних форм і
проводить числені запити, тому статична типізація TypeScript скорочує час
розробки та можливість помилки. Обидвом програмам необхідно було мати
консистентні елементи користувальницького інтерфейсу, тому вони обидві
використовують спільну бібліотеку компонентів Chakra.js.
Графік контролю версій - проста програма з одним компонентом для
рендеру, і бібліотека Gitgraph.js, яку було використано для візуалізації графіку,
має не складний і вдало розподілений інтерфейс, як і пакунок роботи з Github
API octokit/rest, що було використано для отримання даних про репозиторій.
 35

Отже, статична типізація Typescript або фреймворк не були б ефективними в

межах цього застосунку. Його виконано на звичайному JavaScript.
Графік продуктивності команди використовує бібліотеку для візуалізації
Chart.js, що передбачає трансформування даних, отриманих із сервера, від
об’єктів до масивів, тому, аби уникнути помилок, TypeScript було застосовано
навіть за незначного обсягу функціоналу.
Сервер реалізовано на Node.js із сучасним фреймворком Koa. Цей засіб
менший та більш модульний за свого основного конкурента, Express.js, що
дозволило оптимізувати розмір пакунку й придшити час збірки при розробці.
Оскільки моделі даних не числені й не мають складних відношень між
собою, оптимальною базою даних для проекту стала MongoDB. Збірні індекси
цієї СУБД також дозволили реалізувати швидкісні запити наборів даних за
параметрами власника репозиторію та репозиторію, уникнувши додаткової
обробки даних. Для взаємодії із базою даних використовується об’єктно-
документний маппер (ODM) Mongoose.
Під час розробки та експлуатації використовується система ізольованих
контейнерів Docker та композитор контейнерів docker-compose.

3.2. Серверна частина.

Оскільки мікрофронтенди є ідейним продовженням мікросервісів,

поширеною практикою є написання відокремлених сервісів для потреб кожного
застосунку з ізольованими кодовими базами та базами даних.
Але через те що Agitile як проект носить демонстраційно-дослідницький
характер, опрацьовує лише тісно пов’язані моделі даних, на які опираються
кілька підзастосунків водночас, та не має значних об’ємів бекендної логіки,
розподілення не є необхідним, і в рамках роботи було реалізовано єдину
програму-сервер.
 36

3.2.1. Застосунок-сервер.

Сервер імплементує обмежений CRUD (create, read, update, delete)

інтерфейс для проектів, спринтів та квитків. Кожна з моделей має простий GET
та POST ендпоінти, що отримують та створюють документи відповідно. Квитки
та спринти також мають PUT ендпоінт для оновлень, який не є необхідним для
проектів, оскільки єдине відкрите поле даної моделі - це prefix, зміна якого
малоймовірна, тому не імплементована.
Кожен ендпоінт реалізований як функція-обробник. У випадку
зазначених вище ендпоінтів, вона приймає дані, котрі відповідають схемі
моделі, що опрацьовується, та взаємодіє з інтерфейсом ODM, аби здійснити
необхідні операції з базою даних. Для квитків та підзавдань генеруються
проектні ідентифікатори шляхом складання значень prefix та seq проекту.
Валідація даних відбувається вбудованими інструментами ODM, після чого
можлива помилка відправляється на подальше опрацювання проміжними
обробниками.
Окрім того, імплементовано ендпоінт для отримання продуктивності
спринта, котрий трансформує необхідні дані в зручну для обробки застосунком
“Продуктивність” форму та ендпоінт для одного з кроків аутентифікації Github,
про яку йтиметься детальніше в пункті 3.4.2.

3.2.2. База даних.

Моделі даних, документи яких зберігаються в MongoDB, описані в

розділі 2.4. та Додатку А.1.
Важливим елементом моделей є присутні в Спринті, Квитку та Проекті
поля owner та repo. Оскільки проекти ідентифікуються за цими полями, а
запити спринтів і квитків фільтруються за ними, важливо зробити звернення до
бази даних за owner і repo оптимізованими. Пошук з умовою для звичайного
поля в документі MongoDB називається “сканом таблиці” і вважається
неефектим [17, p.81]. Є особливий тип полів, індекс. Ці поля слугують
покажчиками в умовному “змісті” колекції, що складається за ініціалізації БД.
 37

Індекси дозволяють значно скоротити час запитів до колекції в обмін на

незначну втрату швидкості операцій запису.
Індекси також бувають “складеними”: коли кілька полів документу
формують єдиний індекс. Для кожної з моделей в базі Agitile сформовано
складений індекс із полів owner та repo, з умовою унікальності для Проекту.

3.3. Мікрофронтенди.

3.3.1. Система управління завданнями.

Маючи найбільшу кодову базу зі всіх елементів програми, застосунок

“Канбан” імплементує усю взаємодію з проектом, котрий вже було обрано:
відображення завдань у формі списку та Канбан дошки, перемикання спринтів,
створення та оновлення даних у формах, зміна статусів завдань і спринтів.
Для менеджменту стану застосунку застосовується React Context. Цей
інструмент дозволяє передавати дані у глибоко вкладені компоненти по всьому
застосунку, без необхідності передавати їх через батьківські. TicketContext,
SprintContext та ProjectContext імплементують запити відповідних даних до
серверу, формують запити на оновлення даних, зберігають іншу релевантну
інформацію. ProjectContext також верифікує проектний репозиторій, що
описано в розділі 2.5., шляхом запиту учасників репозиторію у Github API за
параметрами проекту, owner і repo. У разі успішної відповіді, дані
використовуються як масив можливих виконавців для завдань. ControlContext,
SprintFormContext та TicketFormContext контролюють стан інтерфейсу
контрольної панелі і відповідних форм та надають UI компонентам необхідні
функції, інкапсулюючи та приховуючи логіку.
Компонент контрольної панелі дозволяє обрати спринт до відображення
або відкрити його для редагування. Присутня також можливість вибрати
активний спринт - той, що наразі знаходиться в статусі “In Progress”. Оскільки
значення активного спринта виводиться з масиву наявних даних, воно не
зберігається на сервері, але для уникнення додаткових опрацювань масиву
 38

спринтів, записується в локальне браузерне сховище та оновлюється за потреби

(оновлення статусу спринта, відсутність даних тощо).
Оскільки можливість поділитися посиланням на конкретний спринт є
важливим для користувача, значення спринта, що переглядається, фіксується в
URL сторінки, понад параметрами проекту, наступним чином:
[host]/:owner/:repo/sprint/:id
Маршрутизатор, імплементований з допомогою бібліотеки react-router-
dom, опрацьовує URL параметри, та відображає необхідні компоненти. Він
також забезпечує логіку перенаправлення за невалідних параметрів проекту:
після верифікації репозиторію проекту, якщо його не вдалося завантажити,
користувача буде перенаправлено на сторінку з можливістю обрати інший
проект.
У випадку, якщо URL параметри є валідними та збігаються з
верифікованим проектом, відображається основне тіло користувальницького
інтерфейсу. Окрім контрольної панелі, це список завдань певного спринта або
усіх завдань в проекті, беклогу. Якщо відображено завдання активного спринта,
спосіб відображення можна перемкнути зі списку на Канбан дошку. Дошка
містить чотири стовпці, що відповідають можливим статусам квитка, та картки
квитків у відповідних стовпцях. Користувач може перетягувати картки
відповідних колонок, змінюючи статус квитка. В режимі відображення списком
користувач має можливість додати до проекту або конкретного спринта новий
квиток.
Форми квитків та завдань, створені з допомогою бібліотеки react-final-
form, відображаються у модальному вікні, що центрується у в’юпорті.
Інтеграція мікрофронтенду через JavaScript, про що йдеться в розділі 3.4.1.,
дозволяє уникнути проблем з контекстами в’юпорту, оскільки застосунок
виконуються в єдиному веб-документі.
Форма квитка, окрім інших полів, містить поле виконавця з можливістю
обрати одного із завантажених учасників репозиторію Github та радіо-групу
стандартного набору значень для Story Point’ів - 1, 2, 3, 5, 8, 13, 20, 40, 100 - зі
 39

значенням “1” за замовчуванням, що унеможливлює створення квитка без

зазначення складності.
Збірка виконуваного коду реалізована через стандартні інструменти
create-react-app, що застосовується для створення проектів на React. Вона надає
мінімізований та компільований код, придатний для розгортання локально або
на експлуатаційному середовищі.

3.3.2. Графік системи контролю версій Git.

Розбираючи URL, застосунок “Git графік” отримує параметри проекту,

що визначають репозиторій для відображення. Інтерфейс Github API
імплементований програмно в бібліотеці octokit/rest. За owner та repo він
отримує інформацію про активність в репозиторії, що є переліком таких подій
як: створення комітів, гілок, зливання гілок тощо. Перетворюючи ці дані на
масив комітів із зазначенням мета-інформації, програма відображає їх
почергово на сторінці з допомогою бібліотеки Gitgraph.js, враховуючи гілки та
зливання.
Періодично, за зазначеним інтервалом, застосунок опитує Github API
повторно, аби отримати інформацію про можливі оновлення та відобразити їх
на сторінці. Це не оптимальне рішення, але ці оновлення не є терміновою
інформацією, тому встановлений інтервал може бути ощадливо довгим.
Збірка проекту відбувається з допомогою пакувальника Parcel, котрий
транспілює код із новітніх версій JavaScript у версії, що підтримуються
більшістю браузерів, завантажує пакунки залежностей та мінімізує вихідний
дистрибутив.

3.3.3. Графік продуктивності команди.

Застосунок “Продуктивність” відображає інформацію лише за умови, що

URL параметри містять інформацію про проект та спринт. В цьому випадку,
програмі не потрібно знати про те, чи проектний репозиторій верифіковано,
оскільки за стандартного виконання обраний спринт означає, що застосунок
“Канбан” успішно провів верифікацію.
 40

Із запиту ендпоінту продуктивності спринта на сервер, застосунок

отримує об’єкт-словник із ключами, що є датами усіх днів спринта, та
значеннями, що відповідають сумі Story Point завдань, виконаних до даної дати
включно. Із цих значень, з допомогою бібліотеки візуалізації даних Chart.js,
будується графік реального прогресу команди в спринті.
У відповідь на запит продуктивності спринта, сервер також надає
застосунку загальну кількість Story Points та дати початку й закінчення спринта,
з яких екстраполюється ідеальне значення виконаної за день роботи та
будується графік ідеального прогресу.
Окрім контрастуючих графіків, даний мікрофронтенд відображає загальні
відомості про поточний спринт, отримані з серверу.
Збірка вихідного коду відбувається за тим же алгоритмом, що й
мікрофронтенді “Git графік” із доданим кроком компіляції з TypeScript у
JavaScript.

3.4. Інтеграція та композиція підзастосунків.

3.4.1. Програма-контейнер, завантаження ресурсів підзастосунків.

В ході розробки проекту було випробувано різні способи інтеграції

підзастосунків, зазначені у пункті 1.3.1., проте оптимальною виявилась
інтеграція під час виконання через JavaScript. Інтеграція на етапі збірки
суперечить вимозі незалежного розгортання, оскільки при оновленні одного з
модулів необхідна повторна збірка й, відповідно, розгортання програми-
контейнеру. В той же час, тег <iframe> створює окремий контекст переглядача
із окремими глобальними об’єктами, включно з window, що значно ускладнює
комунікацію між підзастосунками.
Для інтеграції на етапі виконання через JavaScript необхідно перш за все
відкрити доступ до скриптів мікрофронтендів. Зазвичай веб-застосунки та
вебсайти надають index.html або інший .html файл як точку входу, який
самостійно завантажує необхідні JavaScript скрипти. Для інтеграції
мікрофронтендів, потрібно зробити головний JavaScript файл точкою входу.
 41

Для застосунків “Git графік” та “Продуктивність” це означає

налаштування їхнього сервера (в режимі розробки цю роль виконує Parcel). Для
застосунку “Продуктивність”, початковий код якого написаний на TypeScript
також необхідна попередня компіляція у JavaScript.
Застосунок “Канбан”, що пакується із закритими налаштуваннями create-
react-app, одразу надає доступ до файлів скриптів через asset-manifest.json,
доступний в мережі, котрий описує ресурси застосунку і шлях до них.
Для того, аби виконання мікрофронтендів було контрольованим, їхній
функціональний код обгортається у функції, що присвоюються методам
глобального об’єкту window. Коли скрипт виконується, відбувається перевірка
на наявність у DOM елемента з очікуваним id. Якщо він присутній, це означає,
що програму було завантажено як мікрофронтенд, і попередньо було створено
елемент-контейнер. Якщо ні, скрипт створює його самостійно й викликає метод
window зі своєю функціональною частиною, забезпечивши відтворення у
самостійному режимі.
Для застосунку “Канбан” метод, що він присвоює об’єкту window, - це
стандартний ReactDOM.render(), котрий монтує будь-який React застосунок у
бразерний DOM.
Програма-контейнер імплементує компонент Mircrofrontend, який
завантажує необхідні скрипти. Він отримує ім’я та хост мікрофронтенду зовні,
та тип, що має очікуванні значення “js” або “react”. За умови, що існують
мікрофронтенди, реалізовані іншими фреймворками, ці параметри можуть бути
розширеними, аби включити інші стратегії завантаження. При монтуванні в
DOM компонент створює елемент-контейнер для мікрофронтенду, та додає до
тегу <head> сторінки скрипт, вказавши розташування необхідного ресурсу. На
подію “onload” цього скрита створюється слухач, котрий викликає метод
глобального об’єкту window, котрий очікувано встановив скрипт.
Для того, аби завантаження й ініціалізація відбулися коректно, необхідні
спільні між програмою-контейнером та мікрофронтендом правила
найменування для методу, що виконує підзастосунок, та id елементів-
 42

контейнерів. Для Agitile це метод “render-” + назва підзастосунку та id - назва

підзастосунку + “container”. Ці правила дійсні для всіх мікрофронтендів, аби
стандартизувати алгоритм завантаження.
Реалізація у коді відображена на рисунку нижче. Окрім описаного вище
алгоритму, реалізована також перевірка на наявність очікуваного тегу <script> у
дом, на випадок якщо компонент буде демонтований з DOM і пізніше
змонтований знову. Присутня також ізоляція й обробка можливої помилки
виконання, аби хиба одного з мікрофронтендів не призвела до неактивності
всієї програми. Кодова реалізація у рис. 3.1.:
 43

Рисунок 3.1. Код компоненту завантаження мікрофронтенду.

3.4.2. Комунікація між мікрофронтендами.

Основний контекст, що необхідний усім підзастосункам - параметри

проекту - імплементовано як параметри шляху URL сторінки, як описано вище,
у формі [host]/:owner/:repo. Кожен застосунок самостійно розбирає URL та
застосовує отримані параметри для запитів. Такий підхід означає відсутність
зв’язку та залежності між кодовими базами мікрофрондендів, оскільки вони
 44

спираються на зовнішнє джерело - браузер. Окрім того, URL виконує роль

єдиного необхідного вводу для кожного застосунку, і таким чином уможливлює
їхнє незалежне виконання.
Спілкування між застосунками “Канбан” та “Git графік”, що забезпечує
автоматизацію відстежування статусу завдань через інтеграцію системи
контролю версій, відбувається через користувацькі браузерні події. Відправник
створює об’єкт події з допомогою браузерного інтерфейсу CustomEvent,
вказуючи домовлене ім’я та можливі деталі. Інший застосунок за необхідності
створює слухач подій з домовленим іменем для глобального об’єкту window,
надаючи обробник, що отримує деталі як один з аргументів.
В ході розробки комунікації між мікрофронтендами було випробувано
також інші підходи. Зокрема, одна з версій передбачала завантаження
застосунку “Git графік” через <iframe>. В цьому випадку, спілкування було
налагоджено через метод window.postMessage(), що дозволяє надсилати й
отримувати інформацію між різними об’єктами window в межах браузер, якими
вважаються веб-сторінка та <iframe>. Цей метод серіалізує дані, що вимагає
додаткового кроку десеріалізації, та вимагає виклику на цільовому об’єкті
window, який можна отримати з <iframe> лише в застосунку, який його
змонтував - контейнері - або за ідентифікатором елементу, що вимагає
додаткового узгодження найменувань. Такий підхід виявився не оптимальним
та йшов у розріз з цілями архітектури мікрофронтендів, тому було прийнято
рішення завантажувати підзастосунки лише через <script> тег.
Оскільки програма-контейнер викликає функціональні методи
мікрофронтендів, додатковою можливістю спілкування є також аргументи цих
методів. Їх можна використати, наприклад, аби передати об’єкт window
підзастосунку, завантаженого як <iframe> іншому, завантаженому як <script>.
Але такий підхід означає додаткову залежність мікрофронтендів від програми-
контейнера, і оскільки це суперечить цілі самостійного виконання, не був
імплементований.
 45

3.4.3. Аутентифікація.

Певні методи Github API вимагають аутентифікації користувача. Для

цього Agitile було зареєстровано як Github App. Github Apps - сервіс, що надає
можливість застосункам виконувати операції від імені користувача через Github
API, надавши auth_token, отриманий OAuth інтерфейсом Github.
При реєстрації, вказується адреса застосунку та адреса перенаправлення
після аутентифікації. Github Apps надає ідентифікатор та секрет для
формування токенів.
У заголовку застосунку-контейнера користувач має можливість перейти
на сторінку аутентифікації. Програма формує посилання, вказавши в
параметрах запиту ідентифікатор застосунку в Github Apps, та очікувану адресу
для перенаправлення, а також додаткової опції. Для створення стрічки
параметрів запиту використано бібліотеку querystring. Процес
продемонстровано у рис. 3.2.:

Рисунок 3.2. Фрагмент коду, що створює запит на Github API.

За цим посиланням користувач потрапляє на сторінку аутентифікації
Github в новій вкладці браузеру. За успішної аутентифікації, його
перенаправлено за вказаною адресою назад до Agitile. В параметрах запиту
URL перенаправлення знаходиться код. Окремим запитом до Github API цей
код перетворюється на аутентифікаційний токен. Оскільки для запиту токену
використовується секрет, наданий Github Apps, з метою інформаційної безпеки
його потрібно здійснювати за межами браузеру, де тіло запиту доступне
користувачеві. Для цього застосунок-сервер використано як посередника: за
певним ендпоінтом він отримує код, здійснює із ним запит на Github API та
повертає у відповіді створений токен. Програма контейнер після цього записує
 46

аутентифікаційний токен у локальне сховище та використовує його для

подальших запитів. У локальному сховищі токен доступний для підзастосунків.

3.5. Налагодження незалежного розгортання.

Як зазначено у підрозділі 1.2., однією з визначних переваг архітектури є

можливість незалежного розгортання підзастосунків. Для розгортання Agitile
використовується менеджер контейнерів Docker та хостинг-сервіс Heroku.
Збіркою кожного застосунку задано незалежний образ Docker, який описано у
відповідністю з використаними технологіями в особистому dockerfile. Серверна
частина контейнеризує програму й базу даних разом із допомогою композитора
docker-compose, директиви цього процесу можна оглянути в Додатку Б.1.
Кожен образ після цього отримує свою адресу на піддомені Agitile хостингу
Heroku.
Важливим кроком процесу є налаштування змінних середовища.
Оскільки за локальної розробки програма-контейнер знаходить підзастосунки
на різних портах localhost, а в експлуатаційному середовищі - на відповідних
піддоменах, ці змінні визначені конфігураційним файлом. Такі ж файли
необхідні для кожного підзастосунку, аби правильно визначити адресу
програми-бекенду. Цей файл знаходиться в каталозі програми-контейнера у
двох варіантах - розробницький, що застосовується локально, та
експлуатаційний, що потрапляє в Docker образ.
Під час процесу розгортання мікрофронтенду програма-контейнер не
може його завантажити, тому опрацьовує помилку й відображає елемент-
затичку з відповідним повідомленням на період відсутності.

3.6. Висновки до розділу 3.

У цьому розділі описана технічна реалізація розробленого прототипу:

специфіка окремих підзастосунків, рішення щодо оптимізації роботи з базою
даних, процеси аутентифікації та спілкування між серверною і клієнтською
частинами програми.
 47

Найважливішим є опис імплементації завантаження й комунікації між

мікрофронтендами у підрозділі 3.4. Розроблений підхід є стандартизованим, з
можливістю розширення. Програма-контейнер адаптується до хиб під час
завантаження підзастосунків та динамічно розміщує їх на сторінці.
Описана імплементація комунікації між підзастосунками зосереджується
на незалежності й динамічності, аби їх можна було відтворювати окремо один
від одного.
Загалом, розроблений прототип задовільняє поставлені у розділі 2 умови
й виконує цілі демонстрації специфіки підходу мікрофронтендів. Він
придатний до потенційного масштабування до комерційного рішення.
 48

4. ЕКОНОМІЧНА ЧАСТИНА

4.1 Економічна характеристика проектного рішення (програмного

продукту)
Метою даної бакалаврської кваліфікаційної роботи є розроблення
прототипу системи управління IT-проектами в архітектурі мікрофронтендів для
дослідження переваг такого підходу в даній сфері. Актуальність проекту
визначається безпосередньо перевагами цієї архітектури: організаційної й
технологічної гнучкості при розробці окремих секцій умовного продукту
різними командами; можливістю незалежного розгортання частин продукту, що
зумовлює більш безпечні та інкрементальні оновлення; менші кодові бази, які
легше підтримувати та вивчати новим розробникам. В даному розділі
наведений аналіз того, як ці особливості мікрофронтендів зумовлюють
економічні переваги, оцінку рентабельності розроблення інформаційної
системи проектного менеджменту (ІСПМ) із застосуванням такого підходу,
порівняння з існуючими рішеннями на ринку інформаційних технологій, вибір
стратегії розвитку розробленого рішення на ринку.
4.2 Інформаційне забезпечення та формування гіпотези щодо потреби
розроблення товару
Через об’єм інформації, розмір команд та важливість ефективної
комунікації між їхніми членами в сучасних IT-проектах, ІСПМ вважаються
необхідним інструментом проектного менеджменту для їх ефективної
розробки. Програмних рішень такого типу існує багато, ринок насичений та має
кількох чітко виражених фаворитів седер користувачів, як-от: Trello, Asana й
Atlassian JIRA, що детальніше аналізуються в Вступі до цієї роботи.
Найуспішніші продукти є онлайн платформами, тому розглядаються саме веб-
застосунки та їхня специфіка. Серед цих рішень однією з найважливіших
характеристик для комерційного успіху є гнучкість та можливість динамічно
підлаштовуватись до вимог користувачів в процесі неперервної розробки й
експлуатації.
 49

Архітектура мікрофронтендів, як описано в Розділі 1, дозволяє втілити ці

характеристики. Цей підхід також має значні організаційні переваги. Розробка
окремих секцій продукту паралельними й незалежникими командами означає
можливість більш ефективного масштабування, ніж за розробки моноліту,
оскільки команди мають менше спільних залежностей, а отже витрачають
менше часу на комунікацію й більше - на розробку. Можливість розробляти
різні частини програмного забезпечення у різних технологічних стеках
відкриває доступ до ширшого ринку праці, оскільки серед веб-розробників
існує схильність спеціалізуватися на певному фреймворку, а проект в
архітектурі мікрофронтендів не обмежений лише одним. З технічної боку, крім
гнучкості, цей підхід дозволяє проводити частіші й безпечніші розгортання
програмного забезпечення, що скорочує потенційний неактивний час
експлуатаційного середовища, а отже - потенційні збитки.
Незважаючи на насиченість ринку, ІСПМ, реалізована як
мікрофронтенди, є актуальною, оскільки цей підхід дає можливість втілити
необхідні вимоги для успіху нового рішення, властива йому гнучкість спрощує
пошук незайнятої ніші, а простота масштабування програмного забезпечення в
даній архітектурі гарантує ефективне управління ризиками.
Монетизація систем управління IT-проектами зазвичай відбувається
через систему місячної або річної підписки за умови використання в масштабі
більшому, ніж індивідуальний, але для нового продукту на ринку такий підхід
може є ризикованим. Натомість, модульність мікрофронтендів дозволяє із
легкістю імплементувати обмеження платного доступу до певних частин
функціоналу. Для ІСПМ такими платними секціями можуть бути
мікрофронтенди інтеграцій сторонніх сервісів. Наприклад, основна
функціональність програми може бути безкоштовною, але інтеграція
корпоративного месенджеру Slack або інформаційної бази Confluence будуть
доступні за разову оплату. Таким чином, користувач із проектом будь-якого
масштабу може без ризиків випробувати рішення, що підвищить схильність
користувачів розглядати його як альтернативу існуючим.
 50

4.3 Оцінювання та аналізування факторів зовнішнього та

внутрішнього середовищ
Даний підрозділ містить оцінювання та аналіз факторів зовнішнього та
внутрішнього середовищ групою експертів.
Фактори зовнішні оцінюються за шкалою [-5;5], при цьому межі шкали
відображають максимальний негативний та позитивний вплив факторів на
організацію, 0 демонструє, що фактор впливає на організацію нейтрально.
Фактори внутрішні оцінюються за шкалою [0;5], при цьому 0 демонструє
нерозвинутість, відсутність чи катастрофічний стан фактору внутрішнього
середовища, оцінка 5 демонструє високий рівень розвитку даного фактору.
Сума вагомостей усіх факторів становить одиницю, тобто рівень
вагомості для кожного фактору визначається за допомогою коефіцієнтів.
Зважений рівень впливу факторів розраховується як добуток впливу фактору у
балах та рівня вагомості. Результати експертних оцінок впливу факторів
зовнішнього середовища на організацію наведено у табл. 4.1.

Таблиця 4.1
Результати експертного оцінювання впливу факторів зовнішнього та
внутрішнього середовищ
Фактори Середня Середня Зважений
експертна вагомість рівень
оцінка, бали факторів впливу, бали
1 2 3 4
Фактори зовнішнього середовища
Споживачі 5 0,11 0,55
Постачальники 0 0,1 0
Конкуренти 4 0,1 0,4
Державні органи влади 0 0,05 0
Інфраструктура 0 0,06 0
Законодавчі акти 0 0,1 0
Профспілки, партії та інші громадські 0 0
0,05
організації
Науково-технічний прогрес 4 0,07 0,21
Система економічних відносин в 1 0,06
0,06
державі
Організації-сусіди 0 0,01 0
Міжнародні події 2 0,01 0,02
Міжнародне оточення 2 0,03 0,06
 51

Політичні обставини 1 0,06 0,06

Соціально-культурні обставини 3 0,05 0,15
Рівень техніки та технологій 4 0,04 0,16
Особливості міжнародних економічних 1 0,02
0,02
відносин
Стан економіки 1 0,08 0,16
Загальна сума 28 1 1.85
Фактори внутрішнього середовища
Цілі 4 0,11 0,44
Структура 5 0,16 0,7
Завдання 3 0,07 0,21
Технологія 5 0,2 1
Працівники 4 0,21 0,84
Ресурси 3 0,25 0,75
Загальна сума 22 1 3,94

Отже, як ми бачимо з таблиці 4.1, серед факторів зовнішнього

середовища найвпливовішими є: споживачі, науково технічний прогрес та
конкуренти. Серед факторів внутрішнього середовища найвпливовішими є:
технологія, працівники, ресурси та структура. Загалом, фактори внутрішнього
середовища значно вагоміші, аніж фактори зовнішнього.
Таким чином, запропонований підхід мікрофронтендів, що пріоретизує
саме технологічний стек та структурну організацію працівників - найвагоміші
фактори для даного типу рішень, завдяки цьому має можливість вийти на
ринок.
4.4 Формування стратегічних альтернатив
Перша група стратегічних альтернатив. Критеріями поділу
альтернативних стратегій розвитку є існуючий продукт (програмне
забезпечення) та новий, а також супутні послуги (рис. 4.1).
 52

Рис. 4.1 Стратегічні альтернативи

Стратегія розроблення нового продукту (проектного рішення)
характеризується створенням абсолютно нового програмного забезпечення, яке
дає змогу вирішити новоутворені потреби людини, суспільства, економіки
тощо.
Стратегія розвитку існуючого продукту (проектного рішення) означає
модифікацію програмного забезпечення, його якісних характеристик.
Стратегія розвитку існуючого продукту (проектного рішення) з супутніми
послугами означає пропонування на ринку модифікованого програмного
забезпечення із додатковими послугами (встановлення, супроводження,
коригування, адаптування до специфіки конкретного підприємства тощо).
Стратегія нового продукту (проектного рішення) з супутніми послугами
означає розроблення нового програмного забезпечення та пропонування при
його експлуатації додаткових послуг.
Друга група стратегічних альтернатив. Критеріями поділу
альтернативних стратегій розвитку є існуючий ринок та продукт, новий ринок
та продукт (рис. 4.2).
 53

Рис. 4.2 Стратегічні альтернативи

Глибше проникнення на ринок полягає в використанні існуючого
продукту (проектного рішення) для збільшення частки на існуючому ринку.
Якщо фірма володіє достатніми ресурсами та потужностями для виготовлення
існуючого продукту, то ця стратегія є найменш ризикованою. Однак, активно
зростання на існуючому ринку призведе до зростання конкуренції. Стратегія
буде успішною за умови обмежень у ресурсах та потужностях конкурентів або
стрімкому розвитку самого ринку. Слід зазначити, що кожен ринок за обсягом
має свій ліміт і якщо підприємство прагнутиме розвиватись, то воно повинно
використовувати інші запропоновані стратегії.
Стратегія розвитку ринку полягає в використанні існуючого продукту
(програмного забезпечення) або незначній його модифікації для виходу на
новий сегмент ринку, весь ринок або іноземний ринок. Ця стратегія є з вищим
рівнем ризику, оскільки необхідно виходити на новий ринок, де можуть бути
інші правила гри, вимоги та смаки споживачів тощо.
Стратегія розвитку продукту полягає у створенні нового продукту
(програмного забезпечення) для існуючого сегменту ринку. Ця стратегія є
досить ризиковою, оскільки вимагає створення нового продукту (програмного
 54

забезпечення) для існуючого сегменту споживачів. Однак, якщо ринок починає

зменшувати обсяги та існуючий продукт є на етапі зрілості та падіння, тоді
доцільно застосовувати стратегію розвитку продукту.
Стратегія диверсифікації реалізується шляхом виходу на нові сфери
бізнесу. Тобто розширення номенклатури товарів, послуг тощо.
Отже, за першою групою альтернативних стратегій для даного
програмного продукту найбільше підходить стратегія розроблення нового
продукту, через те що серед існуючих подібних програм немає жодного, яке
працювало б на україномовних ресурсах.
За другою групою альтернативних стратегій розвитку було обрано
стратегію розвитку продукту, яка полягає у створенні нового продукту
(програмного забезпечення).
4.5 Бюджетування
Бюджетування є комплексно обгрунтованою системою розрахунку
витрат, пов’язаних з виготовленням та реалізацією продукту, яка дає
можливість здійснити аналіз витрат та розробити заходи щодо підвищення
рентабельності виробництва. На даному етапі необхідно визначити собівартість
продукту, який розробляється та економічно обґрунтувати доцільність вибору
однієї із стратегій.
Для розробки в архітектурі мікрофронтендів потрібно щонайменше дві
команди. Максимальна кількість людей в команді за Scrum - 9, з яких
розробників - 7, тому мінімальна кількість команд, аби їх необхідно було
розділяти - 4, себто 8 розробників.
Для розробки Web найпопулярнішими є ноутбуки від компанії Apple -
Macbook. Щонайменша обсяг оперативної пам’яті для запуску кількох
мікрофронтендів водночас - 16 ГБ. Вартість такого пристрою з умовою, що
решта характеристик мінімальні - 45 000 грн. Час ефективного використання - 5
років. Місячна амортизація, таким чином, складає:
45 000 / 5 / 12 = 750 грн/місяць.
 55

Таблиця 4.2
Бюджет витрат матеріалів та комплектуючих виробів
Назва Марка, тип, Фактична Ціна за Амортизація Разом, грн.
матеріалів модель кількість, одиницю, одиниці за
та шт. грн. міс., грн
комплектую
чих
APPLE MacBook
Ноутбук Pro 13" Space 8 45 000 750 360 000
Gray (MYD82)
Разом: 360 000

Загальні витрати матеріалів та комплектуючих виробів - 360 000 грн.

Середній рівень розробника для роботи з цією складною архітектурою
повинен бути Middle. Згідно статистики jobs.dou.ua, медіана зарплатні
розробника такого рівня, що спеціалізується на Javascript - 55 000 грн в місяць.
Час програмного рішення на основі розробки описаного в даній кваліфікаційні
роботі прототипу від проектування до експлуатації - щонайменше 3 місяці або
60 робочих днів.
Місячний оклад розробника – 55 000 грн.
Денна заробітна плата розробника – 2 750 грн.

Таблиця 4.3
Бюджет витрат на оплату праці
Час Денна заробітна Сума витрат
Посада, Кількість
роботи, плата на оплату
спеціальність працівників, осіб
дні працівників, грн. праці, грн.
Основна заробітна плата
Розробник 8 60 2 750 1 320 000
Разом: 1 320 000

Загальні витрати на оплату праці - 1 320 000 грн.

Із заробітної плати кожного працівника необхідно сплатити податок з
доходів фізичних осіб у розмірі 18%, а також військовий збір у розмірі 1,5%.
Для восьми розробників на термін трьох місяців ці суми становитимуть 237 600
грн. та 19 800 грн. Відповідно.
 56

Таблиця 4.4
Бюджет обов’язкових відрахувань та податків
Сума нарахувань
Сума Сума Разом
єдиного внеску на
Посада, основної додаткової витрат на
соціальне
спеціальність заробітної заробітної оплату
страхування (22%),
плати плати праці
грн.
Розробник 165 000 - 165 000 36 300
Розробник 165 000 - 165 000 36 300
Розробник 165 000 - 165 000 36 300
Розробник 165 000 - 165 000 36 300
Розробник 165 000 - 165 000 36 300
Розробник 165 000 - 165 000 36 300
Розробник 165 000 - 165 000 36 300
Розробник 165 000 - 165 000 36 300
Разом: 1 320 00 - 1 320 00 290 400

Сучасна розробка програмного забезпечення не потребує повноцінного

офісу, оскільки розробники можуть працювати віддалено. Тим не менш,
підтримка серверних, складських та технічних приміщень вимагає оренди та
обслуговуючого персоналу. Середня оренда достатнього за площею
приміщення складає 11 000 грн. на місяць.

Таблиця 4.5
Бюджет загальновиробничих витрат
Статті витрат Сума, грн.
Змінні загальновиробничі витрати, у т.ч.:
- заробітна плата допоміжного персоналу; 34 500
- витрати на МШП; 300
- витрати на електроенергію та технологічні цілі; 1 150
- витрати на ремонт; -
- інші змінні витрати; -
Разом змінних витрат: 35 650
Постійні загальновиробничі витрати, у т.ч.:
- заробітна плата допоміжного персоналу; -
- комунальні послуги; 3 450
- витрати на оренду; 33 000
- витрати на ремонт; -
- інші постійні витрати; -
Разом постійних витрат: 36 450
Разом загальновиробничих витрат: 72 100
 57

Таблиця 4.6
Бюджет адміністративних витрат та витрат на збут
Статті витрат Сума, грн.
1 2
Адміністративні витрати, у т.ч.:
- заробітна плата адміністративного персоналу; -
- витрати на МШП; -
- витрати на відрядження; -
- витрати на ремонт; -
- витрати на паливно-мастильні матеріали; -
- витрати на сплату податків і зборів (бухгалтеру) -
- знос адміністративного обладнання; -
Разом адміністративних витрат: 0
Витрати на збут, у т.ч.:
- заробітна плата менеджерів зі збуту; -
- витрати на гарантійний ремонт; -
- витрати на відрядження; -
- витрати на гарантійне обслуговування; -
- витрати на налагодження і експлуатацію; -
- витрати на паливо-мастильні матеріали; -
- витрати на рекламу; -
- заробітна плата менеджерів зі збуту; -
Разом постійних витрат: -
Разом витрат на збут: 0

Таблиця 4.7
Зведений кошторис витрат на розробку проектного рішення (продукту)
Фактична Ціна
Одиниці Разом,
Статті витрат кількість, одиниці,
виміру грн.
шт. грн.
Сировина і матеріали грн 8 45 000 360 000
Паливо та електроенергія на кВт*год - - -
технологічні цілі
Основна заробітна плата грн 8 165 000 1 320 000
Відрахування на соціальне грн 8 36 300 290 400
страхування
Загальновиробничі витрати, у т.ч.:
- змінні; грн 1 - 35 650
- постійні; грн 1 - 36 450
Разом виробничих витрат: грн 1 - 72 100
Адміністративні витрати грн 1 - 0
Витрати на збут грн 1 - 0
Разом виробничих і операційних 2 114 600
витрат:

Визначаємо вартість продукту, що розробляється за формулою:

 58

Ц=СБ × Р+СБ (4.1)

де Ц – ціна одиниці продукту, грн.;
СБ – собівартість продукту, грн.
Р– рентабельність виробництва, %;
СБ = 1 921 880 грн.;
Р = задана рентабельність 33%;
Ц=2114600 ×0,33+2114600=2812418
Оскільки, ПДВ для програмних продуктів 20%, кінцева ціна:
Ц зПДВ=2812418(1+0,2)=3374901.6

Таблиця 4.8
Бюджет фінансових результатів
Показники Сума, грн.
Дохід від реалізації продукції (1 шт.) 3374901.6
Податок на додану вартість (20%) 562483.6
Чистий дохід від реалізації продукції 2812418
Собівартість реалізованої продукції 2114600
Валовий прибуток 697818
Операційні витрати:
- адміністративні витрати: 0
- витрати на збут; 0
Фінансовий результат від операційної діяльності 697818
Податок на прибуток (18%) 125607.24
Чистий прибуток (збиток) 572210.76

4.6 Остаточний вибір стратегії

Таким чином, виходячи з розрахунків вище, можна узагальнити отримані
результати. Як було досліджено, ринок є перспективним для створення
продукту: внутрішнє і зовнішнє середовища є сприятливими, впливові фактори
резонують із перевагами рішення. На основі отриманих даних визначено
стратегію для успішного розвитку проектного продукту на ринку.
Оптимальною буде стратегія, яку було запропоновано як гіпотезу –
розроблення нового продукту.
 59

ВИСНОВКИ
Під час виконання роботи було розроблено прототип системи управління
IT-проектами із застосуванням підходу мікрофронтендів Agitile. Програма
складається з трьох підзастосунків, програми-контейнера, що інтегрує їх на веб-
сторінці, серверу й бази даних. Кожен підзастосунок є самостійною програмою,
здатною виконуватись окремо від батьківської. Алгоритм їхньої інтеграції
стандартизовано та інкапсульовано в межах додатку-контейнера з можливістю
розширення для налагодження інших підходів завантаження. Комунікація між
мікрофронтендами мінімізована, без взаємних залежностей, спільний контекст
реалізовано через стандартні браузерні інструменти.
Кодові бази складових частин програми повністю розподілені. Фронтенд
частина імплементована в чотирьох різних комбінаціях мови програмування та
фреймворку, з використанням різних пакувальників та методів компіляції чи
транспіляції. Налаштовано незалежне розгортання підзастосунків.
Імплементована інтеграція системи контролю версій Git у вигляді
окремого мікрофронтенду та засобу аутентифікації.
Таким чином, архітектура мікрофронтендів дозволяє досягти важливих
для сучасних ІСПМ особливостей програмного забезпечення та процесу його
розробки: гнучкий та довільний в межах підзастосунку технологічний стек, що
дозволяє обрати оптимальні засоби для імплементації певної частини продукту;
ізольовані вертикальні секції, котрі можуть розробляти окремі команди без
технічних або інформаційних залежностей; інкрементальні, гранулярні й
безпечні оновлення завдяки незалежному розгортанню.
З іншої сторони, розподілення користувальницького інтерфейсу програми
на мікрофронтенди вводить у проект нові складнощі та недосконалості:
інтеграція й композиція підзастосунків та комунікація між ними вимагає
додаткової імплементації нетипових рішень; консистентність даних між
підзастосунками страждає без ресурсомістких алгоритмів комунікації;
неминуче повторення коду та зовнішніх залежностей тягне за собою
 60

збільшення сумарного розміру збірок виконуваного коду та часу завантаження

ресурсів на сторінку.
Інтеграція системи контролю версій Git слугує прикладом реалізації
алгоритму інтеграції сторонніх сервісів у програму. Враховуючи особливості
програмних інтерфейсів таких сервісів, можливість налагодження взаємодії з
ними в ізольованому середовищі мікрофронтенду є корисною, оскільки
підвищує стійкість застосунку та чистоту програмного коду.
Дослідження продемонструвало, що розробка ІСПМ в архітектурі
мікрофронтендів має значні організаційні переваги, технологічну гнучкість та
адаптивність, зміщує зосередження архітектурної складності програми, але
вимагає чіткої вертикальної декомпозиції продукту та витрат додаткових
ресурсів на етап проектування, а також має неминучі технічні недоліки. Такий
підхід варто використовувати для великого й довготривалого проекту, для
якого є необхідною оптимізація міжкомандних відносин та котрий можна чітко
розділити на автономні частини. Реалізований прототип системи управління
проектами для розробників програмного забезпечення готовий до
масштабування, подальший розвиток може включати в себе: використання
серверного рендерингу для окремих підзастосунків, аби пришвидшити їх
завантаження; подальша інтеграція Git (наприклад, процесу перегляду коду,
Code Review) та інших засобів розробки; імплементація системної конфігурації
через спільний програмний контекст.
Віртуальне навчальне середовище Національного університету
“Львівська політехніка” має багато спільного з ІСПМ: стандартизовані сховища
даних, користувацьку взаємодію, календарне планування тощо. Дослідницька
частина роботи може бути використаною як джерело знань для оптимізації
клієнтської частини ВНС.
 61

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. Project Management Institute. A guide to the project management body of
knowledge (PMBOK guide) / Project Management Institute. – [S. l. : s. n.], 2017. –
756 p.

2. Keup, Megan. 2019. “A Complete Guide to PMIS - ProjectManager.Com.”

Projectmanager.Com. September 4, 2019. https://www.projectmanager.com/blog/a-
complete-guide-to-pmis.

3. Project Management Institute Pulse of the Profession: 9th Global Project

Management Survey / Project Management Institute, 2017. – 32 p.

4. TechnologyAdvice, Accessed May 26, 2021. technologyadvice.com

5. Li, Patrick. 2019. Jira 8 Essentials - Fifth Edition. Birmingham, England: Packt
Publishing. -- 420 p.

6. Rubin K. S. Essential Scrum: A practical guide to the most popular agile process /
Kenneth S. Rubin. – Upper Saddle River, NJ : Addison-Wesley, 2012.

7. Kaminsky, Alex. 2020. “The Great Migration: An Angular to React Migration

Two Years in the Making.” Building VTS. November 9, 2020.
https://buildingvts.com/the-great-migration-an-angular-to-react-migration-two-years-
in-the-making-753eeea81831.

8. Geers M. Micro Frontends in Action / Michael Geers. – [S. l.] : Manning

Publications, 2020. – 296 p.

9. Український правопис. – Київ : Наук. думка, 2019. – 282 с.

10. Geers, Michael. 2017. “Micro Frontends.” Neuland - Büro Für Informatik.
August 28, 2017. https://micro-frontends.org/.

11. Stenberg, Jan. 2018. “Experiences Using Micro Frontends at IKEA.” InfoQ.
August 7, 2018. https://www.infoq.com/news/2018/08/experiences-micro-frontends/.
 62

12. Colin, Jeremy. 2018. “Front-End Micro Services.” Zalando.Com (blog).

December 6, 2018. https://engineering.zalando.com/posts/2018/12/front-end-micro-
services.html.

13. Gruber, Markus. 2019. “Another One Bites the Dust - Wie ein Monolith
kontrolliert gesprengt wird... Teil I.” Thalia.de. February 4, 2019.
https://tech.thalia.de/another-one-bites-the-dust-wie-ein-monolith-kontrolliert-
gesprengt-wird-teil-i/.

14. Mezzalira, Luca. 2019. “Micro-Frontends, the Future of Frontend Architectures.”

DAZN Engineering. April 1, 2019. https://medium.com/dazn-tech/micro-frontends-
the-future-of-frontend-architectures-5867ceded39a.

15.“Single-Spa.” n.d. Single-Spa.Js.Org. Accessed May 26, 2021. https://single-

spa.js.org/users/.

16. “Stack Overflow Developer Survey 2018.” n.d. Stackoverflow.Com. Accessed

May 26, 2021. https://insights.stackoverflow.com/survey/2018#work-_-version-
control.

17. Kristina Chodorow MongoDB: The Definitive Guide, 2nd Edition. / Kristina
Chodorow – [S. l.] : O'Reilly Media, 2013. – 432 p.

18. “Microservices to Micro-Frontends – Simple Explanation – Agile Champs.” n.d.

Agilechamps.Com. Accessed May 27, 2021.
https://www.agilechamps.com/microservices-to-micro-frontends/

19. Biomee, Mostafa. 2020. “Micro Fronends — Spotify Approach Iframes (Part 2).”
Medium. August 14, 2020. https://medium.com/@m.biomee/micro-fronends-spotify-
approach-iframes-part-2-bb15c14449bf.

20. Jackson, Cam. n.d. “Micro Frontends.” Martinfowler.Com. Accessed May 27,
2021. https://martinfowler.com/articles/micro-frontends.html.

21. Lent, Monica. 2019. Independent Deployment of the Frontend with Docker and
Kubernetes. Coding Tech. https://www.youtube.com/watch?v=Td7w0_nD5_4.
 63

ДОДАТОК А

А.1. Модель “сутність-зв’язок” реалізованої бази даних.

 64

А.2. Діаграма потоку даних проектних параметрів.

 65

А.3. Діаграма активності верифікації проектного репозиторію.

66
 67

Додаток Б

Б.1. Директиви композиції серверу й бази даних для docker-compose.

 68

version: '3.7'

services:
app:
build:
context: .
dockerfile: Dockerfile
target: base
restart: unless-stopped
volumes:
- .:/usr/app
container_name: agitile-server
expose:
- '4000'
ports:
- '4000:4000'
command: npm run dev

mongo:
container_name: mongo
restart: unless-stopped
volumes:
- mongo-data:/data/db
image: mongo
ports:
- '27017:27017'

volumes:
mongo-data:
 69

Б.2. Маршрутизатор підзастосунку “Канбан”

export const MainRouter: React.FC<Props> = ({ history }) => {
const {
getProjectRelativePath,
project,
projectMatchParams,
loading,
} = useContext(ProjectContext);

const isRelevantProjectLoaded = () => {

if (project && projectMatchParams) {
return (
project.owner === projectMatchParams.owner &&
project.repo === projectMatchParams.repo
);
}
};

if (!projectMatchParams) {
return <Heading>No project selected.</Heading>;
}

if (loading) {
return <Spinner />;
}

return isRelevantProjectLoaded() ? (
<Switch>
<Route path={`${PROJECT_PARAMS_PATH}/sprint/:id`}>
<ControlPanel />
<Backlog />
</Route>
<Route path={`${PROJECT_PARAMS_PATH}/backlog`}>
<ControlPanel />
<Backlog />
</Route>
<Redirect to={getProjectRelativePath('/backlog')} />
</Switch>
):(
<Switch>
<Route path={PROJECT_PARAMS_PATH}>
<ProjectForm />
</Route>
</Switch>
);
};