Чи плануєте впровадження ПЗ Atlassian (Jira, Confluence)? Не хочете припуститися жорстоких помилок у проектуванні, які потім доведеться вирішувати в останній момент?
Тоді вам сюди - розглядаємо використання Atlassian Jira + Confluence в корпорації з урахуванням різних технічних аспектів.
Здрастуйте, я є Власником продукту в РСХБ і відповідаю за розвиток Системи управління життєвим циклом (СУЖЦ), побудованої на програмних продуктах компанії Atlassian Jira та Confluence.
У статті опишу технічні аспекти побудови СУЖЦ. Стаття буде корисною всім, хто планує до впровадження або займається розвитком Atlassian Jira та Confluence у корпоративному оточенні. Стаття не вимагає спеціальних знань та розрахована на початковий рівень знайомства з продуктами компанії Atlassian. Стаття буде корисна адміністраторам, власникам продукту, керівникам проектів, архітекторам, усім, хто планує впровадження систем на основі ПЗ Atlassian.
Запровадження
У статті будуть розглянуті технічні питання запровадження Системи управління життєвим циклом (СУЖЦ) у корпоративному оточенні. Давайте спочатку визначимо, що це означає.
А що означає корпоративне рішення?
Це означає рішення:
- Масштабується. У разі зростання навантаження існує технічна можливість наростити потужність системи. Розділяють горизонтальне та вертикальне масштабування - при вертикальному масштабуванні нарощується потужність серверів, при горизонтальному масштабуванні збільшується кількість серверів для роботи системи.
- Відмовостійке. Система залишиться доступною при виході з експлуатації одного елемента. Загалом для корпоративних систем не потрібно стійкості до відмов, але ми розглядатимемо саме таке рішення. У нас в системі планується кілька сотень конкурентних користувачів і простої будуть дуже критичними.
- Підтримуване. Рішення має бути на підтримці у вендора. ПЗ без підтримки повинно заміщатися власними розробками або іншим програмним забезпеченням з підтримкою.
- Встановлення Самокерований (On-premise). Self-managed - це можливість встановлювати програмне забезпечення не в хмарі, а на власних серверах. Якщо бути точніше, то все це варіанти установки не SaaS. У цій статті ми будемо розглядати варіанти встановлення лише Self-managed.
- Можливість незалежної розробки та тестування. Для організації передбачуваних змін у системі, потрібні окремі системи для розробки (змін у самій системі), система тестування (Staging) та продуктивна система для роботи користувачів.
- Інше. Підтримує різні сценарії аутентифікації, підтримує аудит логи, має рольову модель, що настроюється, і т.д.
Це основні елементи корпоративних рішень і, на жаль, часто про них забувають під час проектування системи.
А що таке Система управління життєвим циклом (СУЖЦ)?
Якщо коротко, то в нашому випадку це Atlassian Jira та Atlassian Confluence – система, що надає інструментарій для організації колективної роботи. Система не «нав'язує» правила організації роботи, а надає різноманітний інструментарій для роботи, це і Scrum, і Kanban-дошки, і водоспадна модель, і Scrum, що масштабується, і т.д.
Назва СУЖЦ не є галузевим терміном чи загальновживаним поняттям, це просто назва системи у нашому Банку. СУЖЦ для нас не є системою баг-трекінгу, не є системою Управління інцидентами та системою Управління змінами.
Що включає впровадження?
Впровадження рішення складається з безлічі технічних та організаційних питань:
- Виділення технічних потужностей.
- Закупівля ПЗ.
- Створення команди щодо впровадження рішення.
- Встановлення та конфігурація рішення.
- Розробка архітектури рішення. Рольової моделі.
- Розробка експлуатаційної документації, включаючи інструкції, регламенти, технічний проект, положення та ін.
- Зміна процесів компанії.
- Створення команди підтримки. Розробка SLA.
- Навчання користувачів.
- Інше.
У цій статті ми розглянемо технічні аспекти впровадження, без деталей щодо організаційної складової.
Особливості Atlassian
Компанія Atlassian є лідером у багатьох сегментах:
(Лідерство обумовлено вдалим придбанням AgileCraft зі своїм хмарним рішенням)
Продукти компанії Atlassian мають всі необхідні корпоративні функції. Я відзначу такі особливості:
- Рішення Atlassian базуються на веб-сервері Java Tomcat. ПЗ Apache Tomcat йде у складі ПЗ Atlassian, як частина інсталяції, змінити версію Apache Tomcat, встановленого у складі ПЗ Atlassian, не можна, навіть якщо версія застаріла та містить уразливості. Єдина можливість, це чекати на оновлення від Atlassian, з більш новою версією Apache Tomcat. Зараз, наприклад, в актуальних версіях Jira йде Apache Tomcat 8.5.42, а Confluence йде Apache Tomcat 9.0.33.
- Зручний інтерфейс, реалізовані найкращі практики, доступні на ринку для даного класу ПЗ.
- Повністю настроюване рішення. З доопрацюваннями можна реалізувати будь-яку зміну базового функціоналу для користувача.
- Розвинена екосистема. Є кілька сотень партнерів: , зокрема 16 партнерів у Росії. Саме через партнерів у Росії можна купити ПЗ Atlassian, плагіни, пройти навчання. Саме партнери розробляють та підтримують більшість плагінів.
- Магазин додатків (плагіни): . Плагіни значно розширюють функціонал Atlassian. Базовий функціонал програмного забезпечення Atlassian досить скромний, практично для будь-яких завдань виникає необхідність встановлення додаткових плагінів безкоштовно або за додаткові гроші. Тому витрати на ПЗ можуть виявитися значно вищими, ніж це оцінювалося спочатку.
На даний момент у магазині опубліковано кілька тисяч плагінів, майже тисячу з них протестовано та валідовано за програмою Data Center approved apps. Такі плагіни можуть вважатися стабільними та відповідними для використання в навантажених системах.
Раджу ретельно підійти до питання планування плагінів, це сильно впливає на вартість рішення, багато плагінів можуть призвести до нестабільності системи і виробник плагіну не надавати підтримки для вирішення проблеми. - Навчання та сертифікації:
- Підтримуються механізми SSO, SAML 2.0.
- Підтримка масштабованості та стійкості до відмови є тільки в редакціях Data Center. Така редакція вперше з'явилася у 2014 році (Jira 6.3). Функціональність редакцій Data Center постійно розширюється та доопрацьовується (наприклад, можливість single node installation з'явилася лише у 2020 році). Підхід до плагінів для редакцій Data Center сильно змінився в 2018 з введенням Data Center approved apps.
- Вартість підтримки. Вартість підтримки від вендора практично дорівнює повній вартості ліцензій ПЗ. Приклад розрахунку вартості ліцензій наведено нижче.
- Відсутність Long Term релізів. Є так звані Але вони, як і всі інші версії, підтримуються 2 роки. З тією відмінністю, що для Enterprise версій випускаються лише виправлення без додавання нового функціоналу.
- Розширені варіанти підтримки (додаткові гроші).
- Підтримується кілька варіантів СУБД. ПЗ Atlassian поставляється з безкоштовною СУБД H2, дана СУБД не рекомендується для продуктивного використання. Для продуктивного використання підтримуються такі бази даних: Amazon Aurora (Data Center only) PostgreSQL, Azure SQL, MySQL, Oracle DB, PostgreSQL, MS SQL Server. Є обмеження за підтримуваними версіями і часто підтримуються тільки старі версії, але для кожної СУБД є версія з підтримкою вендора:
,
.
Технічна архітектура
Пояснення до схеми:
- На схемі наведено реалізацію в нашому Банку, дана конфігурація наводиться, як приклад і не є рекомендованою.
- Nginx надає функціонал reverse-proxy і для Jira, і для Confluence.
- Відмовостійкість СУБД реалізується засобами СУБД.
- Перенесення змін між середовищами здійснюється за допомогою плагіна Configuration Manager for Jira.
- AppSrv на схемі - це власний сервер додатків для звітності, не використовує Atlassian.
- БД EasyBI створена для побудови кубів та звітності з використанням плагіну eazyBI Reports and Charts for Jira.
- Сервіс Confluence Synchrony (компонента, що дозволяє проводити одночасне редагування документів) не виділено в окрему інсталяцію і запускається спільно з Confluence, на тому самому сервері.
Ліцензування
Питання ліцензування Atlassian заслуговують на окрему статтю, тут згадаю тільки загальні принципи.
Головні питання, з якими ми зустрілися, — це питання ліцензування редакцій Data Center. Особливості ліцензування для редакцій Server та Data Center:
- Ліцензія для редакції Server є безстроковою і покупець може використовувати ПЗ навіть після закінчення ліцензії. Але після закінчення ліцензії покупець позбавляється права отримувати підтримку продукту і оновлювати ПЗ на актуальні версії.
- Ліцензування здійснюється за кількістю користувачів у системі 'JIRA Users' global permission. При цьому не важливо, чи користуються вони системою чи ні — навіть якщо користувачі не заходили в систему жодного разу, всі користувачі будуть враховані для ліцензії. У разі перевищення кількості ліцензованих користувачів рішенням буде видалити повноваження 'JIRA Users' у частини користувачів.
- Ліцензія на Data Center фактично є передплатою. Потрібна щорічна оплата ліцензії. При закінченні терміну роботу з системою буде заблоковано.
- Вартість ліцензій може змінюватися з часом. Як показує практика, у велику сторону і, можливо, суттєво. Тому якщо у вас цього року ліцензії коштують одну суму, то наступного року вартість ліцензій може зрости.
- Ліцензування здійснюється за користувачами з tier (наприклад, рівень 1001-2000 користувачів). Є можливість перейти на вищий tier, з доплатою.
- При перевищенні кількості користувачів, що ліцензуються, нові користувачі будуть створюватися без права входити в систему ('JIRA Users' global permission).
- Плагіни можна ліцензувати тільки на ту саму кількість користувачів, що й основне програмне забезпечення.
- Ліцензувати потрібно лише продуктивні інсталяції, для решти можна отримати Developer license: .
- Для покупки супроводу, потрібна покупка Renew Software maintenance - вартість дорівнює приблизно 50% вартості початкового ПЗ. Така можливість не доступна для Data Center і не поширюється на плагіни — для їхньої підтримки доведеться платити повну вартість щорічно.
Таким чином, річна підтримка ПЗ коштує понад 50% від повної вартості ПЗ у разі редакції Server і 100% у разі редакції Data Center – це значно більше, ніж у більшості інших вендорів. На мій погляд, це значна мінус бізнес-моделі Atlassian.
Особливості переходу з редакції Server на Data Center:
- Перехід із редакції Server на Data Center платний. Вартість можна знайти тут .
- У разі переходу з редакції Server на Data Center платити за зміну редакції у плагінів не потрібно — плагіни для редакції Server функціонуватимуть. Але продовжувати ліцензії для плагінів потрібно буде обов'язково для редакції Data Center.
- Ви можете використовувати плагіни, для яких немає версії для використання із редакціями Data Center. При цьому, звичайно, такі плагіни можуть працювати некоректно і краще передбачити альтернативу таким плагінам.
- Перехід до редакції Data Center здійснюється встановленням нової ліцензії. При цьому ліцензія для редакції Server, як і раніше, залишається доступною.
- Немає функціональних відмінностей між редакціями Data Center та Server для користувачів, всі відмінності лише у функціях для адміністрування та технічних можливостях інсталяції.
- Вартість ПЗ та плагінів відрізняється для редакцій Server та Data Center. Різниця у вартості часто становить менше 5% (не важливо). Приклад розрахунку вартості наведено нижче.
Функціональний обсяг впровадження
Базове постачання ПЗ Atlassian включає величезну кількість можливостей, але найчастіше можливостей, що надаються системою, сильно не вистачає. Іноді навіть найпростіші функції недоступні в базовій поставці, тому без плагінів не обійтися практично за будь-якого впровадження. Для системи Jira ми використовуємо такі плагіни (картинка клікабельна):
Для системи Confluence ми використовуємо такі плагіни (картинка клікабельна):
Коментарі до таблиць з плагінами:
- Всі ціни наведено з розрахунку 2000 користувачів;
- Наведено ціни на основі вказаних цін реальна вартість (зі знижками) виходить нижче;
- Як бачимо, підсумкова сума практично не відрізняється для редакцій Data Center та Server;
- Для використання відібрано плагіни лише за допомогою редакції Data Center. Інші плагіни ми виключили з планів для стабільності системи.
Функціонал коротко описаний у стовпці Коментар. Додаткові плагіни розширили функціонал системи:
- Додано кілька візуальних інструментів;
- Поліпшено інтеграційні механізми;
- Доданий інструментарій для проектів за водопадною моделлю;
- Доданий інструментарій для масштабованого Scrum, для роботи великих проектних команд;
- Додано функціонал для ведення обліку часу;
- Доданий інструментарій для автоматизації операцій та конфігурування рішення;
- Додано функціонал для спрощення та автоматизації адміністрування рішення.
Додатково ми використовуємо . Ця програма дозволяє редагувати файли у зовнішніх програмах (MS Office) і повертати їх назад у Confluence (check-in).
Додаток для робочих місць користувачів (товстий клієнт) ALM Works Jira Client вирішили не використовувати через погану підтримку вендором та негативні відгуки.
Для інтеграції з MS Project у нас використовується самописна програма, яка дозволяє оновлювати статуси Issue в MS Project з Jira і навпаки. У майбутньому, для тих же цілей, плануємо використовувати платний плагін , який встановлюється як надбудова на MS Project.
Інтеграція із зовнішніми додатками реалізується через Application Links. При цьому, для додатків Atlassian інтеграції налаштовані і працюють відразу після налаштування, наприклад, можна вивести на сторінку Confluence інформацію про Issues в Jira.
Для доступу до серверів Jira та Confluence використовується REST API: .
SOAP і XML-RPC API є deprecated і недоступні в нових версіях для використання.
Висновок
Отже, ми розглянули технічні особливості впровадження системи на основі Atlassian продуктів. Запропоноване рішення є одним з можливих рішень і добре підходить для корпоративного оточення
Запропоноване рішення — масштабоване, стійке до відмови, стримає три середовища для організації розробки та тестування, містить усі необхідні елементи для спільної роботи в системі та надає широкий спектр інструментів для управління проектами.
З радістю відповім на запитання у коментарях.
Джерело: habr.com