Як укараніць Atlassian Jira + Confluence у карпарацыі. Тэхнічныя пытанні

Ці плануеце ўкараненне ПЗ Atlassian (Jira, Confluence)? Не хочаце дапусціць жорсткіх памылак у праектаванні, якія потым давядзецца вырашаць у апошні момант?

Як укараніць Atlassian Jira + Confluence у карпарацыі. Тэхнічныя пытанні
Тады вам сюды – разглядаем укараненне Atlassian Jira + Confluence у карпарацыі з улікам розных тэхнічных аспектаў.
Добры дзень, я з'яўляюся Уладальнікам прадукта ў РСХБ і адказваю за развіццё Сістэмы кіравання жыццёвым цыклам (СУЖЦ) пабудаванай на праграмных прадуктах кампаніі Atlassian Jira і Confluence.

У гэтым артыкуле апішу тэхнічныя аспекты пабудовы СУЖЦ. Артыкул будзе карысны ўсім, хто плануе да ўкаранення або займаецца развіццём Atlassian Jira і Confluence у карпаратыўным асяроддзі. Артыкул не патрабуе спецыяльных ведаў і разлічана на пачатковы ўзровень знаёмства з прадуктамі кампаніі Atlassian. Артыкул будзе карысны адміністратарам, уладальнікам прадукта, кіраўнікам праектаў, архітэктарам, усім хто плануе ўкараненне сістэм на аснове ПА Atlassian.

Увядзенне

У артыкуле будуць разгледжаны тэхнічныя пытанні ўкаранення Сістэмы кіравання жыццёвым цыклам (СУЖЦ) у карпаратыўным асяроддзі. Давайце спачатку вызначым, што ж гэта значыць.

А што значыць карпаратыўнае рашэнне?

Гэта значыць рашэнне:

  1. Маштабаванае. У выпадку росту нагрузкі, існуе тэхнічная магчымасць нарасціць магутнасць сістэмы. Падзяляюць гарызантальнае і вертыкальнае маштабаванне - пры вертыкальным маштабаванні нарошчваецца магутнасць сервераў, пры гарызантальным маштабаванні павялічваецца колькасць сервераў для працы сістэмы.
  2. Адмоўаўстойлівае. Сістэма застанецца даступнай пры выхадзе са строю аднаго элемента. У агульным выпадку для карпаратыўных сістэм не патрабуецца адмоваўстойлівасці, але мы будзем разглядаць менавіта такое рашэнне. У нас у сістэме плануецца некалькі сотняў канкурэнтных карыстальнікаў і прастоі будуць вельмі крытычныя.
  3. Падтрымоўванае. Рашэнне павінна знаходзіцца на падтрымцы ў вендара. ПЗ без падтрымкі павінна замяшчацца ўласнымі распрацоўкамі ці іншым ПЗ з падтрымкай.
  4. Ўстаноўка Самастойна кіраваў (On-premise). Self-managed – гэта магчымасць усталёўваць ПА не ў воблаку, а на ўласных серверах. Калі быць дакладней, тое гэта ўсё варыянты ўсталёўкі не SaaS. У гэтым артыкуле мы будзем разглядаць варыянты ўстаноўкі толькі Self-managed.
  5. Магчымасць незалежнай распрацоўкі і тэсціравання. Для арганізацыі прадказальных змен у сістэме, патрабуюцца асобныя сістэма для распрацоўкі (змен у самой сістэме), сістэма тэставання (Staging) і прадуктыўная сістэма для працы карыстачоў.
  6. Іншае. Падтрымлівае розныя сцэнары аўтэнтыфікацыі, падтрымлівае аўдыт логі, мае ролевую мадэль, якая наладжваецца, і г.д.

Гэта асноўныя элементы карпаратыўных рашэнняў і, нажаль, часта пра іх забываюць пры праектаванні сістэмы.

А што такое Сістэма кіраванне жыццёвым цыклам (СУЖЦ)?

Калі сцісла, то ў нашым выпадку гэта Atlassian Jira і Atlassian Confluence - сістэма якая прадстаўляе інструментар для арганізацыі калектыўнай працы. Сістэма не "навязвае" правілы арганізацыі працы, а падае разнастайны інструментар для працы, гэта і Scrum, і Kanban-дошкі, і вадаспадная мадэль, і які маштабуецца Scrum і т.д.
Назва СУЖЦ не з'яўляецца галіновым тэрмінам або агульнаўжывальным паняццем, гэта проста назва сістэмы ў нашым Банку. СУЖЦ для нас не з'яўляецца сістэмай баг-трэкінга, не з'яўляецца сістэмай Упраўлення інцыдэнтамі і сістэмай Упраўлення зменамі.

Што ўключае ў сябе ўкараненне?

Укараненне рашэння складаецца з мноства тэхнічных і арганізацыйных пытанняў:

  • Вылучэнне тэхнічных магутнасцей.
  • Закупка ПЗ.
  • Стварэнне каманды па ўкараненні рашэння.
  • Ўстаноўка і канфігурацыя рашэння.
  • Распрацоўка архітэктуры рашэння. Ролевай мадэлі.
  • Распрацоўка эксплуатацыйнай дакументацыі, у тым ліку інструкцыі, рэгламенты, тэхнічны праект, палажэнні і г.д.
  • Змяненне працэсаў кампаніі.
  • Стварэнне каманды падтрымкі. Распрацоўка SLA.
  • Навучанне карыстальнікаў.
  • Іншае.

У дадзеным артыкуле мы разгледзім тэхнічныя аспекты ўкаранення, без дэталяў па арганізацыйным складніку.

Асаблівасці Atlassian

Кампанія Atlassian з'яўляецца лідэрам у шматлікіх сегментах:

Прадукты кампаніі Atlassian валодаюць усімі неабходнымі карпаратыўнымі функцыямі. Я адзначу наступныя асаблівасці:

  1. Рашэнні Atlassian засноўваюцца на вэб-серверы Java Tomcat. ПЗ Apache Tomcat ідзе ў складзе ПЗ Atlassian, як частка ўсталёўкі, змяніць версію Apache Tomcat, усталяванага ў складзе ПЗ Atlassian, нельга, нават калі версія састарэлая і ўтрымоўвае ўразлівасці. Адзіная магчымасць, гэта чакаць абнаўленні ад Atlassian, з навейшай версіяй Apache Tomcat. Цяпер, напрыклад, у актуальных версіях Jira ідзе Apache Tomcat 8.5.42, а ў Confluence ідзе Apache Tomcat 9.0.33.
  2. Зручны інтэрфейс, рэалізаваны лепшыя практыкі даступныя на рынку для дадзенага класа ПЗ.
  3. Цалкам наладжвальнае рашэнне. З дапрацоўкамі можна рэалізаваць любую змену базавага функцыяналу для карыстача.
  4. Развітая экасістэма. Ёсць некалькі сотняў партнёраў: https://partnerdirectory.atlassian.com, у тым ліку 16 партнёраў у Расіі. Менавіта праз партнёраў у Расіі можна купіць ПЗ Atlassian, убудовы, прайсці навучанне. Менавіта партнёры распрацоўваюць і падтрымліваюць большасць плагінаў.
  5. Крама прыкладанняў (убудовы): https://marketplace.atlassian.com. Убудовы значна пашыраюць функцыянал ПЗ Atlassian. Базавы функцыянал ПЗ Atlassian досыць сціплы, практычна для любых задач узнікае неабходнасць усталёўкі дадатковых убудоў бясплатна або за дадатковыя грошы. Таму выдаткі на ПЗ могуць апынуцца значна вышэй, чым гэта ацэньвалася першапачаткова.
    На бягучы момант у краме апублікавана некалькі тысяч плагінаў, амаль тысяча з іх пратэставаная і валідаваная па праграме Data Center approved apps. Такія плагіны могуць лічыцца стабільнымі і прыдатнымі для выкарыстання ў нагружаных сістэмах.
    Раю педантычна падысці да пытання планавання плагінаў, гэта моцна ўплывае на кошт рашэння, многія з плагінаў могуць прывесці да нестабільнасці сістэмы і вытворца плагіна не аказваць падтрымкі для вырашэння праблемы.
  6. Навучанне і сертыфікацыі: https://www.atlassian.com/university
  7. Падтрымліваюцца механізмы SSO, SAML 2.0.
  8. Падтрымка маштабаванасці і адмоваўстойлівасці ёсць толькі ў рэдакцыях Data Center. Такая рэдакцыя ўпершыню з'явілася ў 2014 годзе (Jira 6.3). Функцыянальнасць рэдакцый Data Center увесь час пашыраецца і дапрацоўваецца (напрыклад, магчымасць single node installation з'явілася толькі ў 2020 году). Падыход да убудоваў для рэдакцый Data Center, моцна змяніўся ў 2018 з увядзеннем Data Center approved apps.
  9. Кошт падтрымкі. Кошт падтрымкі ад вендара, практычна роўная поўнага кошту ліцэнзій ПЗ. Прыклад разліку кошту ліцэнзій прыведзены ніжэй.
  10. Адсутнасць Long Term рэлізаў. Ёсць так званыя Enterprise версіі, але яны, гэтак жа як і ўсе астатнія версіі, падтрымліваюцца 2 гады. З тым адрозненнем, што для Enterprise версій выпускаюцца толькі выпраўленні, без дадання новага функцыяналу.
  11. Пашыраныя варыянты падтрымкі (за дадатковыя грошы). https://www.atlassian.com/enterprise/support-services
  12. Падтрымліваецца некалькі варыянтаў СКБД. ПА Atlassian пастаўляецца з бясплатнай СКБД H2, дадзеная СКБД не рэкамендуецца для прадуктыўнага выкарыстання. Для прадуктыўнага выкарыстання падтрымліваюцца наступныя СКБД: Amazon Aurora (Data Center only) PostgreSQL, Azure SQL, MySQL, Oracle DB, PostgreSQL, MS SQL Server. Ёсць абмежаванні па падтрымоўваных версіях і часта падтрымліваюцца толькі старыя версіі, але для кожнай СКБД ёсць версія, з падтрымкай вендара:
    Jira supported platforms,
    Confluence supported platforms.

Тэхнічная архітэктура

Як укараніць Atlassian Jira + Confluence у карпарацыі. Тэхнічныя пытанні

Тлумачэнні да схемы:

  • На схеме прыведзена рэалізацыя ў нашым Банку, дадзеная канфігурацыя прыводзіцца, як прыклад і не з'яўляецца рэкамендаванай.
  • 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:

  1. Ліцэнзія для рэдакцыі Server бестэрміновая і пакупнік можа выкарыстоўваць ПЗ нават пасля заканчэння ліцэнзіі. Але пасля заканчэння ліцэнзіі пакупнік пазбаўляецца права атрымліваць падтрымку па прадукце і абнаўляць ПА на актуальныя версіі.
  2. Ліцэнзаванне вырабляецца па колькасці карыстачоў у сістэме 'JIRA Users' global permission. Пры гэтым не важна, карыстаюцца яны сістэмай ці не - нават калі карыстальнікі не заходзілі ў сістэму ні разу, усе карыстальнікі будуць улічаныя для ліцэнзіі. У выпадку перавышэння колькасці ліцэнзаваных карыстальнікаў, рашэннем будзе выдаліць паўнамоцтвы 'JIRA Users' у часткі карыстальнікаў.
  3. Ліцэнзія на Data Center фактычна з'яўляецца падпіскай. Патрабуецца штогадовая аплата ліцэнзіі. Пры заканчэнні тэрміну, праца з сістэмай будзе заблакаваная.
  4. Кошт ліцэнзій можа мяняцца з цягам часу. Як паказвае практыка, у большы бок і, магчыма, істотна. Таму калі ў вас сёлета ліцэнзіі каштуюць адну суму, то на наступны год кошт ліцэнзій можа вырасці.
  5. Ліцэнзаванне праводзіцца па карыстальніках па tier (напрыклад, узровень 1001-2000 карыстальнікаў). Ёсць магчымасць перайсці на больш высокі tier, з даплатай.
  6. Пры перавышэнні колькасці якія ліцэнзуюцца карыстачоў, новыя карыстачы будуць стварацца без права ўваходзіць у сістэму ('JIRA Users' global permission).
  7. Убудовы можна ліцэнзаваць толькі на тую ж колькасць карыстачоў, што і асноўнае ПА.
  8. Ліцэнзаваць патрабуецца толькі прадуктыўныя інсталяцыі, для астатніх можна атрымаць Developer license: https://confluence.atlassian.com/jirakb/get-a-developer-license-for-jira-server-744526918.html.
  9. Для куплі суправаджэння, патрабуецца купля Renew Software maintenance – кошт ураўноўваецца прыблізна 50% ад кошту першапачатковага ПЗ. Такая магчымасць не даступная для Data Center і не распаўсюджваецца на плагіны – для іх падтрымкі давядзецца плаціць поўны кошт штогод.
    Такім чынам, гадавая падтрымка ПЗ каштуе больш за 50% ад поўнага кошту ПЗ у выпадку рэдакцыі Server і 100% у выпадку рэдакцыі Data Center – гэта значна больш, чым у большасці іншых вендараў. На мой погляд, гэта значная мінус бізнес-мадэлі Atlassian.

Асаблівасці пераходу з рэдакцыі Server на Data Center:

  1. Пераход з рэдакцыі Server на Data Center платны. Кошт можна знайсці тут https://www.atlassian.com/licensing/data-center.
  2. Пры пераходзе з рэдакцыі Server на Data Center плаціць за змену рэдакцыі ў плагінаў не патрабуецца - убудовы для рэдакцыі Server будуць функцыянаваць. Але падаўжаць ліцэнзіі для плагінаў ужо трэба будзе абавязкова для рэдакцыі Data Center.
  3. Вы можаце выкарыстоўваць убудовы, для якіх няма версіі для выкарыстання з рэдакцыямі Data Center. Пры гэтым, вядома, такія плагіны могуць працаваць некарэктна і лепш загадзя прадугледзець альтэрнатыву такім убудовам.
  4. Пераход на рэдакцыю Data Center ажыццяўляецца ўстаноўкай новай ліцэнзіі. Пры гэтым ліцэнзія для рэдакцыі Server па-ранейшаму застаецца даступнай.
  5. Няма ніякіх функцыянальных адрозненняў паміж рэдакцыямі Data Center і Server для карыстачоў, усе адрозненні толькі ў функцыях для адміністравання і тэхнічных магчымасцях усталёўкі.
  6. Кошт ПЗ і плагінаў адрозніваецца для рэдакцый Server і Data Center. Розніца ў кошце часта складае менш за 5% (не прынцыпова). Прыклад разліку кошту прыведзены ніжэй.

Функцыянальны аб'ём укаранення

Базавая пастаўка ПА Atlassian уключае велізарную колькасць магчымасцяў, але часцяком магчымасцяў, якія прадстаўляюцца сістэмай моцна бракуе. Часам нават найпростыя функцыі недаступныя ў базавай пастаўцы, таму без убудоў не абыйсціся практычна пры любым укараненні. Для сістэмы Jira мы выкарыстоўваем наступныя плагіны (карцінка клікабельная):
Як укараніць Atlassian Jira + Confluence у карпарацыі. Тэхнічныя пытанні

Для сістэмы Confluence мы выкарыстоўваем наступныя плагіны (карцінка клікабельная):
Як укараніць Atlassian Jira + Confluence у карпарацыі. Тэхнічныя пытанні

Каментары да табліц з убудовамі:

  • Усе цэны прыведзены з разліку 2000 карыстальнікаў;
  • Прыведзены цэны на аснове цэн названых https://marketplace.atlassian.com, рэальны кошт (са зніжкамі) атрымліваецца ніжэй;
  • Як бачым, выніковая сума практычна не адрозніваецца для рэдакцый Data Center і Server;
  • Для выкарыстання адабраны плагіны толькі з падтрымкай рэдакцыі Data Center. Астатнія плагіны мы выключылі з планаў, для стабільнасці сістэмы.

Функцыянал коратка апісаны ў слупку Каментарый. Дадатковыя плагіны пашырылі функцыянал сістэмы:

  • Дададзена некалькі візуальных інструментаў;
  • Палепшаны інтэграцыйныя механізмы;
  • Дададзены інструментар для праектаў па вадаспаднай мадэлі;
  • Дададзены інструментар для які маштабуецца Scrum, для арганізацыі працы вялікіх праектных каманд;
  • Дададзены функцыянал для вядзення ўліку часу;
  • Дададзены інструментарый для аўтаматызацыі аперацый і канфігуравання рашэння;
  • Дададзены функцыянал для спрашчэння і аўтаматызацыі адміністравання рашэння.

Дадаткова мы выкарыстоўваем Atlassian Companion app. Дадзенае прыкладанне дазваляе рэдагаваць файлы ў вонкавых прыкладаннях (MS Office) і вяртаць іх зваротна ў Confluence (check-in).
Прыкладанне для працоўных месцаў карыстальнікаў (тоўсты кліент) ALM Works Jira Client https://marketplace.atlassian.com/apps/7070 вырашылі не выкарыстоўваць з-за дрэннай падтрымкі вендарам і адмоўных водгукаў.
Для інтэграцыі з MS Project у нас выкарыстоўваецца самапісны дадатак, якое дазваляе абнаўляць статусы Issue ў MS Project з Jira і наадварот. У будучыні, для тых жа мэт, плануем выкарыстоўваць платную ўбудову. Ceptah Bridge - JIRA MS Project Plugin, Які ўстанаўліваецца, як надбудова на MS Project.
Інтэграцыя з вонкавымі прыкладаннямі рэалізоўваецца праз Application Links. Пры гэтым, для прыкладанняў Atlassian інтэграцыі настроены і працуюць адразу пасля наладкі, напрыклад, можна вывесці на старонку ў Confluence інфармацыю аб Issues ў Jira.
Для доступу да сервераў Jira і Confluence выкарыстоўваецца REST API: https://developer.atlassian.com/server/jira/platform/rest-apis.
SOAP і XML-RPC API былі deprecated і недаступныя ў новых версіях для выкарыстання.

Заключэнне

Дык вось, мы разгледзелі тэхнічныя асаблівасці ўкаранення сістэмы на аснове прадуктаў Atlassian. Прапанаванае рашэнне уяўляе сабой адно з магчымых рашэнняў і добра падыходзіць для карпаратыўнага асяроддзя

Прапанаванае рашэнне — маштабуемае, адмоваўстойлівае, стрымае тры асяроддзі для арганізацыі распрацоўкі і тэсціравання, змяшчае ўсе неабходныя элементы для сумеснай работы ў сістэме і прадастаўляе шырокі спектр інструментаў для кіравання праектамі.

З радасцю адкажу на пытанні ў каментарах.

Крыніца: habr.com